Principles and notes of the spike system

To do any technical solutions need to be combined with the prevailing business scenarios, funding, user volume and other dimensions of comprehensive consideration, there is no best technical solutions, only the most appropriate technical solutions.

Do spike program is also the same, spike activities often lead to high concurrency, system downtime and inventory overselling of the thorny problem, as a developer, how do we ensure the stability of the system at the same time, to prevent business risks?

This post talks about a few principles and notes for a spike program, and the brain map is at the end of the post.

1. Principles

Throughout the multiple spike programs, there are no identical ones, but all of these programs adhere to the same principles. The specific principles are as follows:

1.1 Protection of databases

In a spike scenario, it must be a top priority to protect the database. Once the database is down, then the system is completely paralyzed, which will cause losses to the business and reputation. Protecting the database should pay attention to the following points:

• All unqualified requests need to be blocked at the application layer to avoid the logic reaching the database.
• Evaluate concurrency, QPS, etc., and set a reasonable number of database connection pools for the application to avoid running out of database connections.
• Monitor the database, observe the pressure of CPU, memory, etc. of the database, observe the slow SQL, etc., and respond promptly in case of problems.

1.2. Protection application systems

The application system is also the object to be protected, whether it is a monolith or a microservice, and the system tries not to go down. Protect the system with these points in mind:

• If possible, make the BFF layer of the spike system a separate service, so that even if this service hangs, it doesn't affect other services.
• Evaluate the number of visits to the spike event and appropriately expand the load quantity of some microservices so as to improve the responsiveness of the system.

1.3 Early withdrawal

Once the spike system is open to the public, it will surely attract a lot of wool parties and even malicious attacks. Therefore, when dealing with the logic, you must do a pre-check, and once you find an illegal request, interrupt it directly.

If you are in a position to do so, you should also do some attack-based and stress tests to see if you can block illegal requests and see if the system can withstand the stress.

1.4. Not oversold

Items in the spike scenario are generally lost money, literally selling one order at a loss. The items, prices, and inventory of a general spike are the result of communication and confirmation between the company's operations and management.

In order to keep losses within reasonable limits, it is important to sell strictly according to the established inventory, which must not be oversold.

2, the front end of the main points of attention

There are some notes on the front-end for the spike scenario, as follows:

• Page Static: Whether in PC, H5, applet or APP, the page is static as much as possible, go to the cache if you can, and request the interface as little as possible.
• CDN: Brush the static resources involved, such as js, images, html, etc., into the CDN in advance to speed up access.
• Reading data from the cacheThe interface used in the spike scenario should be differentiated from the regular interface, and the interface in the spike scenario should try to read the data from the Redis cache and then respond to the front-end. The front-end also needs to determine what data can be stored in the front-end cache to avoid repeated calls to the interface to get the next time.
• Front-end interception: The front-end page also has to do some blocking actions to filter illegal requests. It's not very useful, and it only protects against gentlemen, but it needs to be done. All the actions that can intercept the illegal request in advance, should be done.

3. Back-end main points of attention

There are more notes on the back end, roughly as follows:

• Flexible addition of servers: Expand the load appropriately based on your overall deployment. For example, in the case of hybrid cloud deployment, you can temporarily rent a few cloud servers from cloud vendors on demand, and immediately release the cloud servers when the event is over, thus minimizing the cost.
• Restrictions and downgrades: Whether in a spike scenario, or the rest of the scenarios, the means of protecting the system is to limit, downgrade, and fuse. No matter when it is shelved, it is these three axes.
• pre-calibration: Pre-checking can maximize the blocking of illegal requests. For example, checking malicious duplicate IP, checking duplicate orders of users, checking inventory and so on.
• Cache Warmup: For the product information and inventory of the seconds, you need to do cache preheating in advance, such as flushing the data into the Redis cache in advance.
• timed task：
  • Timely release of inventory: In a normal scenario, it may take half an hour to cancel an unpaid order. However, in the spike scenario, the time allowed for an order to remain unpaid should be reduced, for example, 3 minutes, due to limited inventory and to avoid maliciously occupying inventory. In this scenario, you can use a timed task to cancel the order in time, or, use a timed message scheme with a message queue (e.g., RocketMQ's delayed message).
  • Inventory of calibration caches: Placing an order takes up inventory and canceling it releases it. If inventory is warmed up to Redis, there needs to be a timed task to calibrate the amount of inventory in Redis.
• Placement of orders and stock reduction：
  • Optimistic locks reduce inventories: When updating inventory quantities in the database, be sure to use an optimistic locking scheme to avoid overselling, something likeupdate ttt set stock = xxx where product_id = yyy and stock = zzz;。
  • Synchronous or asynchronous: After the pre-logic, it will enter the order and inventory reduction logic, at this time, you can use a synchronous way to call directly, you can also use asynchronous way to drop into the MQ. The specific use of which way, according to the throughput of the system to do assessment.

4. Summary

In this article, we talked about a few principles and front-end and back-end considerations of the spike program. There are thousands of programs, just a few principles. Finally, a brain map is posted for easy memorization.

The end of this article! Welcome to pay attention to, add V (ylxiao) exchange, the whole network can be searched (programmers half a cigarette)

Link to original article:/s/EK_j7EyIEpz_YPJb8w1jsw