This article was originally Links: https://blog.csdn.net/weixin_38035852/article/details/81384733
Sanno limit spike rush tickets system
highlights: spike optimization in the case of high concurrency, we know that when the number of concurrent reaches a certain amount of time, the database server will bring a lot of pressure, how to alleviate these pressures and improve concurrent QPS is the focus of the entire project. (Continuous improvement QPS).
Highlights 3:
1. Using the cache to reduce the pressure on the database, and read much faster than the cache database (IO network delay +)
2. static pages the user access speed technology to accelerate and improve QPS, single asynchronous enhance the user experience, and memory Redis marked reduction of access.
3. Security optimization: double hidden password md5 checksum, spike interface address of the interface limiting anti-brush, a mathematical formula verification code.
Enhance the overall safety performance of the system,
Under the premise of high concurrency, a server is unable to bear such a large concurrent access. We know that Taobao double 11QPS can reach tens of millions, so the views of at least one of the servers will need tens of thousands, so it is necessary to achieve a high-Cluster Server concurrent services.
Database ease pressure:
1. The project takes advantage of a large number of cache technology, including user information cache (Distributed session), caching product information, merchandise inventory cache, the cache of orders, reduced access to the database server.
User information buffer lead: Distributed session.
2. Distributed session
We know that when the time server cluster, if the user first request on the first server, a second request on other servers, there will be cases of missing session, loss of user information. And in this high concurrency scenarios, many servers must be synchronized to work, so how to solve the problem of distributed session is a priority.
This project uses: redis method utilizes caching, a further arrangement Redis dedicated server for storing user session information. This user session loss does not occur. (Each required session, can be taken from the cache)
Advantages of this approach: a distributed manner relative to the other,
1. The server file synchronization (not recommended, this will cause file duplication, waste of resources)
2.session memory database (not recommended to use, the database will increase the pressure)
3. Use the cookie (not recommended, cookie less secure)
For the number of machines in the cluster and more complex network environment situation have a good treatment effect.
A lot of cache references there have been a problem, how to identify the different cache modules (repeat key value, key is how to identify different modules). Lead: General cache key package
3. General cache key package
Using an abstract class that defines BaseKey (prefix), defines cache String prefix (prefix) and the cache expiration time. So that different modules inherit it.
Cached so that every time a module, we add the cache-specific prefixes, and can be unified for different expiration time.
4. static pages and the front and rear ends separated
Static pages of the main purpose is to speed up the loading speed of the page. Practices: the booking details page to make static HTML, on the CDN (reduce the pressure on the server side) on as a client static data is sent to, and the data information to obtain an asynchronous request is sent through the front ajax. Obtaining dynamic data information portion only, loading speed can reach all rendered twice.
Difficulty:
1. a lot of use of the cache, then there is a cache expiration time and the cache control cache avalanche breakdown and other issues?
Solution: First, different for different cache settings expiration time, such as the session cache, in userKey prefix, the setting is the 30 minutes expired, and added another layer of cache mechanism to increase landing time. In this way each taking session, will be extended by 30 minutes, and relatively speaking, it reduces the chance of cache expiration.
For hot data, such as concert tickets ticket details this information, because the hot commodity is generally considered to rush to grab votes almost finished in 10 minutes, so he set to 10 minutes of cache.
Breakdown for caching of hot data problem, in case the waves rush tickets (tickets) that, in case a large number of concurrent some point in time, I just had this ticket cache time, and to access the database. For this hot data, I will be stored in the cache expiration time together, when taken out, than about the expiration time and the current time, less than one minute, I'll update about the cache to prevent him expired.
2. Use a large amount of cache to cache server, there are also a lot of pressure, sometimes bigger than Redis pressure mysql lot to think about how to reduce the access of Redis?
General rush tickets, ticket number is also small, probably around 1000, but the amount may be complicated by the tens of thousands.
In the pre-cut stock Redis when maintained in a memory as a marker isOvermap, when not in stock, it is set to true. Before each grab a ticket service access Redis, check the map, true explanation is not in stock, return directly No_stock.
3. high concurrency when the business was too late synchronization, Redis pressure, database and sometimes there will be a lot of insert and update operations, even when the request is excessive accumulation, to many connections?
I thought message queue for asynchronous processing request. Over each request, the first request is not processed, but rather into the message queue, then the background is arranged at a listener, the listener are different business message queue, the message came, performing spike operation grab votes. This prevents simultaneous operation of multiple requests, the database connection excessive abnormal.
4. In order to limit the same time on the front end of high concurrency, and I think some of the restrictions on the tip off some users of the practice.
Mathematical formula verification code