Practical Chapter-22. Flash Kill Optimization-Asynchronous Flash Kill Ideas_bilibili_bilibili
1. Process review
1.1 Oversold problem
Determine the flash sale time, add optimistic locking (compare marks/versions), and check whether the inventory is greater than 0
1.2 One person, one order question
Check to see if there are any orders placed by this person in the database:
1. Add pessimistic lock sychronized in stand-alone mode, bind the lock monitor to the user thread id string, check before purchasing.
2. Multi-threaded mode has concurrency security issues. Distributed locks must be added to uniquely identify a lock between different JVMs.
Use uuid + thread id to uniquely identify a thread to avoid accidental deletion of other threads;
Ensure atomicity through Lua script (locking and setting expiration/thread id judgment and unlocking)
Dark Horse Comments 06 Distributed Lock 2Redisson-CSDN Blog
Multi-threaded distributed locks can be replaced by Redission, and can solve the retry, reentry, and timeout refresh (watchdog) mechanisms
2. Concurrent simulation test jmeter
Create 1000 tokens (users) and put them in txt files.
By specifying this file as the token source in jmeter, you can simulate 1,000 users.
Because each step before was performed serially, and there were a large number of database operations that would greatly affect efficiency, the qualification judgment and ordering business were separated.
3. Optimized process
4. Add new coupons
callcrud
5. Based on Lua script, determine flash sale inventory, one order per person, and determine whether the user has successfully purchased.
New lua script
6. If the rush purchase is successful, encapsulate the coupon ID and user ID and store them in the blocking queue.
Because the process has changed, a lot of Java business has been transferred to Lua scripts, and the code needs to be modified.
General process
Specific operation
6.1 Blocking queue
When there are no elements, fetching the object will block until new content comes in.
6.2 Enable asynchronous single thread (thread pool)
7. New process
1. Determine the qualifications first. If qualified, create an order object (but do not place an order in the database) and add the order to the blocking queue, otherwise an error will be returned. Here the user has already got the result. In theory, the user knows whether he can place an order.
2. Then execute asynchronous order placement and class initialization to execute the thread pool. The threads in the thread pool continuously retrieve the order information that needs to be placed from the blocking queue, and then perform order database operations.
1) The blocking queue is in the jvm, and the memory is limited. If there are too many orders, it will easily overflow.
2) If the order is added to the blocking queue but the service is down, the order will be lost.
The blocking queue used here is very simple and prone to many problems, so the message queue is introduced later.