First, buy business analysis
1. The characteristics of the business of buying
(1) low price
(2) substantial promotion
(3) instantly sold out
(4) the timing of shelves, the timing of the end
High (5) concurrency
2. The technical challenges
(1) the impact of existing services
(2) a highly concurrent environment, the burden of database
(3) Fluctuation in the network of high concurrency
Process (4) of the front end of the data
Processing (5) the timing of product shelves
(6) inventory of "oversold" phenomenon
(7) spike device response
Second, buy business structure principle
1. try to request interceptor in the system upstream of the
Reduce backend data layer, the reading of the pressure data, the server easily hang preventing
2. read how much writing, multi-use caching
Reduce the number of database reads
Third, buy business architecture
1. The overall architecture
Front and rear end of the separation mode, only the rear end providing operational data, not responsible for the front page. Using RESTful API provides data to the front end, or modify data. Using SPA technology development distal react single page application, separating the front and rear ends, decoupling system, improve the stability and robustness of the system. Using nginx as a transit point for the transfer of the front also back end, achieve proxy and load balancing, reduce the requests for static resources background and improve the overall stability of the system.
2. The front-end tier architecture
(1) using nginx reverse proxy and CDN done quickly respond to requests from across the country to solve network bandwidth bottleneck.
(2) countdown problems due to inconsistencies in the customer service end time and server time, will lead to failure or buy in advance buy. So the use of regular intervals, before and after the end of the clock synchronization.
(3) When time is not yet reached, intercepts the front end of the request, a request throttling way as to prohibit the front end when not transmitting valid start.
3. The back-end architecture
(1) in the requisitions API interface, a queue panic buying, on the "jump the queue" behavior.
(2) for storing data mysql using redis data cache, at the beginning of buying, reading data from a mysql database, read the product information stored in the cache redis, each execution when buying when reading from redis commodity information, and modify the corresponding stock, reduce frequently read and write mysql database.
(3) After buying success, if the user is within 20 minutes of the payment, buying goods re-enter the queue be snapped up.
Fourth, the business logic
- Flowchart Step1: go through Nginx load balancing and split
- Enter jseckill procedures. Google guava RateLimiter limiting. Concurrent large amount of time, directly discard the request of some users
- Redis determine whether the spike too. Avoid duplication spike. If there is no spike through the
user name (herein, mobile phone number) and seckillId encapsulated into a message to RabbitMQ, is serialized by the request becomes
immediately return status "queue" to the client back to the display "on the client queue in..." - After listening background in RabbitMQ message, each taking a message, and parses the request made Redis Stock decremented (DECR command)
and ACK queues manually if successful Save stock, the inventory record of success in the user's phone number userPhone in Redis. - Flowchart Step2: After the client queue is successful, the timing of the request a background check whether the spike is successful, will go back to query whether Redis spike successful
if buying success or failure will stop buying regular query, if a queue, continue regular query.
Five, ER diagram
Six, use case diagrams
Adding to buy up the process:
Front-end buying process
Back-end processing of data flow
Seven Chart
