The spike system is what I asked a lot in interviews. If program = algorithm + data structure, then system = service + data storage. Therefore, in system design, we focus more on services and data storage.
To give a simple example: In a certain year on Double 11, a merchant puts an iPhone on the shelves at a price of 4499, which is 1,000 employees cheaper than the official website price. The total inventory is 10 units. The operation setting 11/11 00:00 is effective, and one person can only purchase 1 unit. , While the products are sold out.
First sort out the flow chart of the user terminal:
According to the nine chapter algorithm ** system design 4S analysis method **, **the first step Scenario scenario. **Need to determine which functions to design and how much traffic it will bear?
Here we need to know the common concept of the spike system QPS (Queries Per Second), that is, the number of requests that can be processed in one second.
If the RT (Response time) of a service is 20ms, the QPS is 50 (the calculation here is the single-machine single-threaded QPS, if you want to calculate the cluster, you need to consider the number of clusters and the number of threads).
QPS = 100, it is enough to use your laptop as a web server.
QPS = 1k, it is almost the same with a better Web server.
QPS = 1m, you need to build a cluster of 1000 Web servers.
The relationship between QPS and server/database:
A server can withstand a QPS of about 1k (considering the logic processing time and the bottleneck of database queries),
a SQL Database can withstand a QPS of about 1k (if JOIN and INDEX queries are more, this value will be smaller) and
a NoSQL Database (Casscandra) can support a QPS of about 10k
A NoSQL Database (Memcached) can support a QPS of about 1M
The second step is Service .
Services can be thought of as the integration of logical processing. The logical processing of the same type of problem is merged into one service, and the entire system can be subdivided into several small services.
The service design of the spike system here is roughly as follows:
The third step is Storage , how data is stored and accessed. Choose the appropriate storage structure for each service, and then refine the data table structure. In this example, the spike system database design is as follows
So we can get the relationship between the databases in the spike activity as shown in the figure
Well, the next step is the point. We first deduct inventory based on the database Mysql
update stock set count = count - 1 where product_id = xxxx and count > 0
So the problem is coming. The spike system must have concurrent problems. What should I do?
There are generally two solutions: optimistic lock (Optimistic Lock) and pessimistic lock (Pessimistic Lock).
The process of pessimistic lock is as follows:
In scenarios that require very high data consistency, pessimistic locks are generally used.
The optimistic locking process is as follows:
It can be seen that the problem of pessimistic locking is that it will take up a lot of thread resources and may lead to exhaustion of mysql threads. Optimistic locking is not applicable when the version changes frequently, so the spike system is not suitable for optimistic locking because the version (inventory) changes too quickly.
In addition, you can look at the database design of the spike system under Redis.
Several common questions about Redis in the spike system:
When is the inventory written to Redis?
Write to Redis when the spike activity is created/maintained.
How to ensure that the activity database and inventory data are consistent?
You can use distributed transactions or message queues.
** Distributed transaction: ** Ensure that multiple database operations succeed or fail at the same time. Business scenarios that require strong consistency can consider using distributed transactions, such as bank transfers
**Message Queue: **Components based on the producer/consumer model, and generally introduce message queues when implementing asynchronous tasks (non-real-time processing). The advantage of the message queue is that the task can be processed slowly, and there is no need to synchronize the processing and wait for the response result. The current mainstream message queues include RocketMQ, Kafka, etc. In addition to asynchronous tasks, usage scenarios are generally used to retry processing in the case of failure, and repeat consumption until consumption is successful.
Order to reduce inventory/payment to reduce inventory?
Place an order to lock the inventory, and pay to reduce the inventory.
How to prevent products from being oversold?
Put the inventory data into the cache and use the atomic characteristics of the cache to ensure that only one thread operates the inventory at the same time.
When is the inventory written back to the database?
Use timed tasks to synchronize Redis data and write back to the database.
Finally, the fourth step of 4S analysis is Scale expansion . For the spike system, it is how to optimize the system in high concurrency scenarios.
In addition, various questions about 4S analysis and system design interviews are also mentioned in the " System Design 2020 Edition ". In the new version of the course, we invited 3 first-line IT interviewers to explain the current domestic Popular system design issues, **The first two sessions are free and open **, students who are interested can come and have a look.
The first free trial lesson can be listened to at any time, and the second free trial lesson will start tomorrow morning from 9:30-11:30, and you can sign up for free trial by poke me
The free trial content is as follows:
