Technical difficulties of secsha

 First, I will use Huawei's official website   To illustrate the second kill   Overall process , Click on the commodity information in a second kill session on Huawei's official website 

We will jump to the product details page , Specific technical difficulties here My last article also said , And then click Rush to buy

 Click to buy   Go to the product confirmation page ---> Then click to place an order   payment 

 That is to say, the business process here is ( Select... Under an activity   A certain session  , Select a specific commodity in a certain session , such as  618 Activity selection 12  Point to 2 The number of points ,  stay 12 Point to 2 Select... Under the field number of points   Huawei Pro20) 
（ Activities ---> Sessions ----> Specific products ）   Click on the product ----> Product details page ---->（ Rush to buy ） Product confirmation page ---------->{ Confirm the order }
 This is the business process of secsha 

 The business feature of secsha is 

 What about that   What technical problems should we pay attention to in the second kill ?

 The product details page is   I said before   use nignx+lua+ Local cache  +redis  Implement the L3 cache policy 
  . Limit the frequency of users    Do not allow users to access frequently  

seckill 1. High concurrency solves the oversold problem First of all, we need to understand how the oversold problem arises

--- table Info   Our table structure 
 CREATE TABLE `tb_product_stock` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT ' Self increasing ID',
  `product_id` bigint(32) NOT NULL COMMENT ' goods ID',
  `number` INT(8) NOT NULL DEFAULT 0 COMMENT ' Inventory quantity ',
  `create_time` DATETIME NOT NULL COMMENT ' Creation time ',
  `modify_time` DATETIME NOT NULL COMMENT ' Update time ',
  PRIMARY KEY (`id`),
  UNIQUE KEY `index_pid` (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=' List of goods in stock ';
	
	//  ProductStock  pojo 

class ProductStock {
    private Long productId; // goods id
    private Integer number; // Inventory 

    public Long getProductId() {
        return productId;
    }

    public void setProductId(Long productId) {
        this.productId = productId;
    }

    public Integer getNumber() {
        return number;
    }

    public void setNumber(Integer number) {
        this.number = number;
    }
}

-------------<<<<  When concurrency is not considered   We (select ) Check inventory --->(update)  Change inventory --->(insert )  New order   
  Multiple threads in parallel , There is a possibility of oversold .
 /**
     *  Update stock ( Don't think about concurrency )
     * @param productId
     * @return
     */
    public boolean updateStockRaw(Long productId){
 	//   Check inventory 
        ProductStock product = query("SELECT * FROM tb_product_stock WHERE product_id=#{productId}", productId);
        if (product.getNumber() > 0) {
    //  change 
            int updateCnt = update("UPDATE tb_product_stock SET number=number-1 WHERE product_id=#{productId}", productId);
            if(updateCnt > 0){    // Inventory update succeeded 
                return true;
            }
        }
        return false;
    }

 Look at the picture above   Assuming that thread 1  And thread 2  At the same time, we found   The inventory at this time is 100 individual  
 Threads 1  Inquire about  100 stock    Conduct update  Change inventory ( Deducting the inventory )   Updated to 99
 If the thread 1  At this time, the network is blocked ,  here 
 Threads 2  Inquire about  100 stock    Conduct update  Change inventory （ Deducting the inventory ）  Updated to 99,
 Because in thread 1  There is no time when the update is over   Threads 2 Started the query   This leads to oversold  ,
 I sold it. 2 Commodity   But the inventory is only deducted once 

 We can use mysql Pessimistic lock to solve 　　select ... for update 

 Use mysql  Of select ...for update  Pessimistic lock to solve the oversold problem    Pessimistic locks are exclusive 
 My current transaction has not been committed or rolled back ,  Other threads cannot operate on this data 
/**
     *  Update stock ( Use pessimistic lock )
     * @param productId
     * @return
     */
    public boolean updateStock(Long productId){
        // Lock the commodity inventory record first 
        ProductStock product = query("SELECT * FROM tb_product_stock WHERE product_id=#{productId} FOR UPDATE", productId);
        if (product.getNumber() > 0) {
            int updateCnt = update("UPDATE tb_product_stock SET number=number-1 WHERE product_id=#{productId}", productId);
            if(updateCnt > 0){    // Inventory update succeeded 
                return true;
            }
        }
        return false;
    }

    /**
     *  Order less stock ----------------> Optimism lock    We can also use Mysql  Optimistic lock of    ci
     * @param productId
     * @return
     */
    public boolean updateStock(Long productId){
        int updateCnt = 0;
        while (updateCnt == 0) {
            ProductStock product = query("SELECT * FROM tb_product_stock WHERE product_id=#{productId}", productId);
            if (product.getNumber() > 0) {
            ....................   here   When we change, we add   If the quantity queried before is 100 Transformation of   Just change it  ,   Or add a version number   Or add uuid 
                updateCnt = update("UPDATE tb_product_stock SET number=number-1 WHERE product_id=#{productId} AND number=#{number}", productId, product.getNumber());
                if(updateCnt > 0){    // Inventory update succeeded 
                    return true;
                }
            } else {    //update  fill  Change failed 
                return false;
            }
        }
        return false;
    }

1.   No matter optimistic lock or pessimistic lock   We all have to operate db,  All of them have to be locked   It will affect performance    And we db The performance of is preferred 
 for instance 1w Individuals to rush to buy , The goods are 100 individual ,  There will be 1w Operate by individuals db  , But I just want to 100  Personal operation db, Not allow （1w-100） Personal operation db  
 We can use redis  Preheating 

 We can also use local caching   Sign a true  add redis  Warm up to solve the current performance problem    So our query db  Only a part will be queried   Less db The pressure of the