Cache and database consistency

Reference article https://blog.csdn.net/simba_1986/article/details/77823309

Cache and database consistency

Caching is suitable for scenarios with more reads and fewer writes, and can greatly improve performance and efficiency; however, it is a challenge to keep cached data consistent with the database

maintain a consistent strategy

  1. When the data is updated, first update the cache, if the cache update is successful, then update the database
    • The applicable scenarios are limited and the implementation is more complicated (if the database operation fails, compensation measures should be taken to restore the cached data)
  2. When the data is updated, delete the cache first, if the cache deletion is successful, then update the database
    • Applicable to all scenarios and simple to implement, it is the most commonly used

existing problems

Regardless of strategy 1, the following will delve into strategy 2

In the case of high concurrency, it is assumed that request 1 (update operation) deletes the cache first, and then updates the database. If request 2 (read operation) reads data between cache deletion and database update, the old data will be read into Cache, after the database is updated, the old data cache is inconsistent with the database at this time

The core of the problem is that the operation of request 1 cannot be interrupted by other requests, and the order between request 1 and other requests is maintained (serial execution). In this case, you can use a queue to solve it (in order to ensure serial execution, there can only be one worker thread), when an update request occurs, it is directly thrown into the queue and waits for asynchronous execution; when a read request occurs If the cache does not exist, then determine whether the queue header is an update request for the same record. If so, in order not to interrupt its operation, the read request is also thrown into the queue, and then synchronized Wait for the cache update to complete; if not, it means that the update request has already been completed, just read the database and cache it directly, do not enter the queue.

optimization

  1. Multiple queues can be created, and the Hash method is used to hash requests for different records to different queues, which can load balance, execute in parallel, and avoid congestion.
  2. In distributed scenarios, queues are best shared
  3. The read request entering the queue can wait for a timeout. Once it times out, read the database directly and return to avoid long-term non-response.

Finally, it is emphasized: only use the cache in scenarios where there are more reads and fewer writes! ! ! Read more and write less, read more and write less, do not use in other situations

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325344565&siteId=291194637