in the implementation of panic buying second kill function under high concurrency, I have a question, that is, the problem of data storage, when to store it.
idea:
1. Judging that he snapped up successfully, he immediately wrote the generated order data into the mysql order table, while the inventory table field was reduced by 1;
2. After judging the success of the rush purchase, store the user"s user_id in redis"s list list (for example: order, a list with the value of user_id). Then use crontab to insert one by one into the mysql order table, while the inventory table field is reduced by 1.
imagine the result:
the first way of thinking is easy to understand. The simple code implementation is as follows:
$num=10; //
for($i=0;$i<$num;$iPP)
\Redis::lpush("goods_store",1);//goods_store,
push 1011
before snapping up, the above code can be executed to put the goods in the queue.
it"s time to rush to buy: (a large number of users request the following code to perform an action)
/* ,redis */
$count=\Redis::lpop("goods_store");//lpop
if(!$count)
return "";
/* mysql */
1. //order_num
$data["order_num"] = *****************;
$data["user_id"] = ***;
$data["goods_id"] = **;
.......
$res = DB::table("order")->insert($data);
2. //num
if($res)
DB::table("goods")->decrement("num", 1);
in the above code, when the user buys successfully, the relevant order data is immediately inserted into the mysql order table, while the inventory is reduced. Now my question comes, if we use this way of thinking, under large concurrency, if multiple users enter the process of inserting data into the order list and reducing the inventory of goods at the same time, will it also cause the concurrent operation to cause excessive pressure on the server , and to cause incorrect data storage , for example, if the repository is reduced by one (or the atomicity of changing and querying according to the addition, deletion, deletion and deletion of mysql? Will not cause such a mistake)?
in view of the problem of excessive pressure on the database server caused by the reduction of inventory and the insertion of relevant order data into the mysql order table immediately after the above rush purchase.
then there is a second way to store the user"s user_id in the redis list (for example: order, the list with the value of user_id), extract the user_id from the list one by one through the timer crontab, generate relevant data and insert it into the mysql order table, while the inventory table field is reduced by 1.
the code implementation is similar to the above,
/* ,redis */
$count=\Redis::lpop("goods_store");//lpop
if(!$count)
return "";
/* user_id */
\Redis::lpush("order",user_id);
crontab
$user_id = \Redis::rpop("order",user_id);
1. //order_num
$data["order_num"] = *****************;
$data["user_id"] = $user_id;
$data["goods_id"] = **;
.......
$res = DB::table("order")->insert($data);
2. //num
if($res)
DB::table("goods")->decrement("num", 1);
the second way of thinking, my question is, if the panic purchase is successful, first put the user_id in the queue, then use the timer to get the data from the queue at regular intervals, and then generate the relevant data to be inserted into the mysql order table, while reducing inventory. This can relieve the pressure on the database server. but my rush purchase process is designed like this. After a successful rush purchase, the user will pop up / / go to the payment button / / enter the order list page (the order list page data is read from mysql). Because the timer is used to generate the order data and then insert it into the mysql database, this process will certainly be delayed. If the user passes the / / go payment button / / to enter the order list page at this time Isn"t it sad to find that the order list has not yet generated order data?
[is it reasonable to design the rush purchase process in this way? do you not have to enter the order list and click to pay? after the payment is successful, the order data will be generated and inserted into the database]
these are my doubts about the two ideas, which I hope can be explained by professionals or discussed together.