Someone asked me this question recently. I personally have no practical experience in this field. My personal idea is that it takes some time to access the database and write data into the cache. This may cause some earlier requests to directly read the database. When this part of data is to be written to the cache, it determines whether the cache exists. If this part does not exist, it is written. If yes, it is not written and a result is returned. If ($ cache) {return $ cache;} else {$ datareaddatabase; if (! $ Cache) Recently, someone in writ asked me this question. I personally have no practical experience in this field. My personal idea is that it takes some time to access the database and write data into the cache. This may cause some earlier requests to directly read the database. When this part of data is to be written to the cache, it determines whether the cache exists. If this part does not exist, it is written. If yes, it is not written and a result is returned.
If ($ cache ){
Return $ cache;
} Else {
$ Data = read database;
If (! $ Cache) write $ cache $ data;
Return $ data;
}
However, after thinking about it, it seems that this answer does not correctly answer the question that multiple requests read the database at the same time. Although it can shield later requests from accessing the database directly, however, in the early stage, more links were used to directly access the database. I wonder if you have any better solutions. Ask for advice! Reply content: All answers are in question.
「 If the cache is invalid 」
During the design, you can design the cache as persistent to avoid cache penetration due to invalidation. If you have higher stability requirements, you need to perform disaster recovery on the cache. For example, redis Master/Slave Mode and rdb dump.
If the system or the feature related to the cache is released for the first time, you need to push the cache in advance. There are many methods. You can use either script writing or gated release.
「 A large number of requests will access the database instantly 」
There are two problems: how to handle a large number of requests in an instant, and how to avoid the pressure on the database caused by so many requests.
The specific implementation depends on the business scenario, but the solution is to avoid as many requests as possible in an instant, and avoid putting too much pressure on the database when a large number of requests are generated.
The method of Throttling depends on the business scenario. Not all scenarios are suitable for throttling. Therefore, the maximum number of connections from the backend database to the database is limited. As long as the request database is properly designed, even if there is a very high concurrency, it will not cause any practical problems.
So how to solve this problem from the code level depends on how you design the system. Secondary cache. Put the data in a key with a long expiration time. When the avalanche is applied, the lock ensures that only one php process accesses the database, and the rest will not be accessed if they see the lock, and the data in the cache will be directly returned. The result is that although several people did not see the latest data, it would be a bit more. When the lock is grabbed, the latest data is displayed. The lock can be implemented using mc add. When I had a big waste of resources, this set of things hit the nba Live broadcast, c dozens of k, the database is okay, bandwidth is the problem. facebook once discussed this issue in Scaling Memcache at Facebook:
3.2.1 Leases
We introduce a new mechanic we call leases to addresstwo problems: stale sets and thundering herds.
Among them, "thundering herds" is the database penetration problem mentioned by the landlord. If a hot cache fails, before the first request to access the database gets the result written to the cache, during this period, a large number of requests are routed to the database. Then, "stale set" is a data consistency problem. If one instance updates the data and wants to refresh the cache, another instance tries to read the database by reading miss, at this time, the two cache write orders cannot be guaranteed, which may cause the expired data to be written to the cache.
These two problems are inherent in the look-aside cache. We need to provide a mechanism to coordinate cache writing. The solution provided in this paper is the lease mechanism, restrict one key at a time. Only clients with a unique lease can have the right to write data to the cache:
- If a key is missing, a 64-bit lease of the client is returned;
- Then, if a get request is received before the key is written, a hot miss error is returned. The client determines that it will retry later, instead of reading data from the database;
- If the key receives the delete request, it will invalidate the lease. The set Request holding the invalid lease will still succeed, but the get request will receive a hot miss error and carry a new lease; the hot miss error here carries the final value, but it is considered to be in the stale state and left to the client to determine whether to use it. Database requests can be further reduced in scenarios with less stringent consistency requirements;
This allows the memcache server to coordinate database access to solve these two problems.
However, the lease solution is not perfect, because 1. memcache needs to be modified; 2. the logic is still leaked to the client, requiring the client to follow the lease and hot miss conventions.
In the paper TAO: facebook's Distributed Data Store for the Social Graph, one of the problems that the TAO system tries to solve is mentioned:
Distributed control logic: In a lookaside cache ubunturethe control logic is run on clients that don't communicatewith each other. this increases the number offailure modes, and makes it difficult to avoid thunderingherds. nishtala et al. provide an in-depth discussion ofthe problems and present leases, a general solution [21]. for objects and associations the fixed API allows us tomove the control logic into the cache itself, where theproblem can be solved more efficiently.
That is to say, we are not necessarily not a look aside cache. If we encapsulate the cache modification entry and use the write though cache, we do not need to coordinate all clients in a distributed manner, queuing in one place is enough.
References
- Scaling Memcache at Facebook
- TAO: Facebook's Distributed Data Store for the Social Graph
- Https://www.quora.com/How-does-the-lease-token-solve-the-stale-sets-problem-in-Facebooks-memcached-servers
Select a solution based on the actual scenario. It is safer to use a queue for database access request processing and lock the same request.
This kind of problem is called the avalanche effect, which means that the cluster has no problem during normal load. Once several servers crash, the load of server overload is put on the backend database, this will cause the entire cluster to crash like an avalanche.
For business scenarios with more reads, less writes:
For this problem, the cache is necessary before the database server, that is, one of the solutions to the problem, according to the SQL query conditions in the cache server layer lock processing, the same request is only put on the backend database, and other requests are blocked waiting for data updates.
The second is to block the peak caused by a large number of cache failures, and do not allow direct connection to the database for queries. All requests initiated by the cache server to the database must be processed using a queue, share the peak value to a longer period of time to avoid the impact on the backend database.
In addition, in order to avoid the problem that a large number of cache becomes invalid and the cache is generated again, the cache server's data cache time needs to apply for a token from a time token distribution server, based on the basic cache time, add a token cache time to allocate the peak value to a longer period of time.
Such processing can avoid the database load being overwhelmed by peak requests.
Business scenarios with a larger write ratio:
When frequent data updates and high real-time requirements are required, such as live broadcasting room scenarios and flash sales scenarios, the cache failure time is very short. You need to consider service splitting to route similar services to different servers and separate them. Share the write load to the extent that the single-point cluster can afford. The optional technical strategies are highly relevant to the business. Similar to the live broadcasting room scenario, the business is working on the cache without even going to the database server, the businesses that are persisted to the database are processed in the asynchronous throwing queue. E-commerce flash sales have different businesses that must be verified, but the idea is the same. If the business involved in flash sales is too large, the verification code should be added to the queue. In short, try to delay the order submission time as much as possible, when the instantaneous load is distributed to the system for an acceptable period of time, the database layer still locks and queues. However, a lock is required for queuing, once the length of the queue exceeds a multiple of the total number of items (based on the success rate of the previous order payment as required), the lock will block subsequent requests and no longer enter the queue.
There are also many scenarios where the write business volume is very extreme, similar to the location update of the LBS product, the message push of the SNS product, the general idea is similar, lock and queue, at the database level, try to use nosql with excellent write performance to meet these persistent requirements. Otherwise, minimize the use of indexes, such as using mysql as a key-value database, to minimize the performance consumption for writing. The processing of high concurrency at the DB monitoring or interface level is actually to distinguish between macro and micro. You understand that concurrency is to read the database with multiple requests at the same time, however, requests must not be at the same time for computers, but at the same time on a macro scale. For example, how does a computer handle the problem between 1-10 milliseconds or microseconds? In other words, I/O operations are independent processes for computing operations to allocate processor tasks and memory allocation. For example, when you are reading a database at the same time, there are other I/O operations at the same time, you can also simulate the computer design here.
For example, when you write the cache, push the write operation to an independent process, create a write cache queue, and then perform a check process to organize the processing sequence and failure branch of the queue, for example, if the write cache operation fails, perform the next task in the queue or try again. After all the written cache data is pushed into the cache pool, the queue retains all the tasks that update the cache, and does not block the main process, that is, the main process accessed by the user is not blocked. They only read the data in the cache pool and do not care about the validity period. Reading data will not be affected if the database crashes.
The concept of concurrency can be viewed at a relative time. The computer will handle it on its own, and you don't have to worry too much about it. The Business Code just needs to solve the blocking problem.
Ps: I am a front-end, boring during the Chinese New Year... Fold.
In addition, if the cache becomes invalid, the solution to this problem is the cache Disaster Tolerance solution, such as fast switching between multiple cache pools and Server Load balancer. A large number of requests directly access the database, which can be read by multiple processes on multiple hosts. I think it's not very good at the code level...
Because the solution is to add and allocate requests to multiple hosts, so it is impossible to scale up in real time and support high concurrency and massive requests... If the donkey cannot run to graze, it is necessary to think about how to make the donkey unhealthy...
-------
Professionally, this kind of avalanche will direct the cache penetration to the db layer. Actually, the bandwidth is first mounted, and the db will not be the bottleneck. Then we need to solve the problem of using the maximum number of connections to control the read database, more than two levels of cache are used, and then warnings or dynamic resizing are triggered. (A consulting backend colleague) the solution of throttle is in the book, which is introduced in the small book (the name of the book is forgotten, and there is a bullet car on the cover, then several solutions are proposed .. Three books, operating system, database principle, and distributed system. It's an old problem.
1. Assume that the server is buffered. The lock mechanism is fine, because your problem is reading data, not anything else. Whether it is multi-process or multi-thread, you can lock it.
2. Use the buffer pool to reduce the waiting delay.
3. The above is the content of the operating system.
4. If there is an update operation at the same time, consider the data consistency problem, that is, the pessimistic lock or optimistic lock. 1. The service itself must provide overload protection and circuit breaking mechanisms. In the end, the service is throttling, so you must know how to protect yourself.
2. Lock the cache during reconstruction. cache mutex
