- One button second kill boot
No need to fill in/modify the harvest address, discount, invoice and other elements on the settlement page after the setting of one-click second kill boot, which reduces the calculation and call operation of new settlement
- Captcha input
The verification code is a graphic verification code. It is an interactive operation performed by the user after the user clicks “One-click Second Kill”. Because there is no business involved, the verification code is generated by the system itself,
- The single page prevents malicious requests
To prevent malicious requests to obtain the kill order address, make the kill order address dynamic, and the dynamic address is returned to the page at the start of the kill
- Second kill commodity inventory pre-freeze
In order to avoid unexpected failures caused by synchronous calls to the inventory center, the inventory of the goods will be frozen when the creation of the kill activity takes effect, and a freeze type will be added to the inventory center. The order will be generated directly with the inventory, and an order type will be added to the order center
- Inventory release
Because the customer may not pay or cancel the order, there are two options as to whether to release the order without payment:
1. The order center will notify the system to release the inventory of the system and the inventory center for the successful orders that are not paid or canceled, so that customers can buy again (the inventory center will be called by the inventory center to release the inventory)
Second: The program can carry out overflow setting when setting the inventory counter, but it is still possible that the actual number of successful SEC transactions is less than the number of successful SEC orders
- Data interaction full memory operation
In order to improve the execution efficiency, the program will pre-load data into the Redis cache in advance, such as inventory counters, user violation operations (high access frequency within the same IP time, high access frequency within the same user time, blacklist), redis table key Settings will try to comply with the shortest execution/scan path design
- Data objects for memory operations
Inventory counter, request counter received by server node, user participation seconds kill record (for goods, activities, time period), pre-generated order VO, seconds kill product information (start mark, order dynamic URL), access control data.
Except for access control data, all memory data objects are valid in Redis for the second kill activity time.
- The timing of data preloading into memory
Inventory counter – seckill activity created, decrement
The request counter received by the server node — decrement
User participation SEC kill record (for goods) – SEC kill success
User participation SEC kill record (for activity) – SEC kill success
User participation SEC kill record (time period) : SEC kill succeeded
Pre-generated order VO – after the seckill activity is created
User – Verification code – User clicks “One-click second kill”
Instant kill product (activity) information – Instant kill activity creation
Access control data – Request access
- System isolation
Modules to rely on in phase 1:
Activity runtime dependencies: Payment center, inventory center, order Center (Inventory release)
Before the start of the activity depends on: commodity center, member center, business background
Phase 1 relies on the interactive page: the product details page
- Second kill inventory counter
Through redis atomic autoincrement lock implementation, key words: DECR, INCR
- Request four intercepts, in addition to the previous section js also need to do high frequency click limit
First interception (request error flow) : The second kill verification code is input to stagger traffic and reduce concurrency.
Second interception (malicious traffic interception) : Access control blocks malicious or illegal traffic and filters out malicious requests (some of them).
Third interception (service node interception) : each service node allows the flow of an order equal to the inventory number of goods, and other requests indicate that the second kill has been robbed;
Traffic to the split-persistence layer = server nodes * inventory
Fourth interception: the request that reaches the second kill persistence layer is equal to the number of inventory +N(N is the overflow value), other requests indicate that the second kill has been robbed;
- Seckill page independent
Add seconds kill details page, this page only call seconds kill system, reduce the pressure of marketing interface
- The order persistence operation after the kill is successful
Since there are 4 times of request interception, the request that actually reaches the persistence layer is equal to the number of goods in seconds * the number of goods in seconds in inventory. Therefore, the current design is that the whole process from the front-end submission of request to persistence is a one-step operation. If the subsequent persistence is very high, the introduction of message queue will be considered