Cause analysis: delayed double deletion of redis cache

This article brings you relevant knowledge about Redis. Delayed double deletion means that when adding, deleting or modifying an entity class, the cache of the entity class needs to be cleared. The clearing position Before and after the database operation method, the following mainly introduces why the redis cache requires delayed double deletion. I hope it will be helpful to everyone.

Recommended learning: Redis video tutorial

Why is the cache deleted instead of updated?

If it is an update and there is a distributed transaction problem, the cache may be modified and the database modification may fail. If you just delete the cache, even if the database modification fails, the next query will directly fetch the data from the database, and no dirty data will appear.

What is delayed double deletion?

That is, when adding, deleting or modifying an entity class, the cache of the entity class must be cleared. The clearing position is before and after the database operation method.

Adopt proof by contradiction

Only delete first



##Only delete later

Conclusion

This leads to the conclusion that there are problems with both front deletion and back deletion. Therefore, the strategy of delayed double deletion is adopted

Thinking 2: Why is it delayed

It is still a proof by contradiction. The situation in the figure below shows the situation where the old cache still exists after double deletion. The delay is

to ensure that the change cache operations of other transactions have been completed before modifying the database -> clearing the cache.

Additional: Why should we delay double deletion to ensure cache consistency

Why To delay double deletion to ensure cache consistency

Before modifying the database data, redis needs to be deleted first: this is to ensure that within the interval between the database data modification and the redis data deletion, If there is a hit, it is guaranteed that this data does not exist in redis. Without this deletion, when the database data has been modified, old data can still be read from redis, resulting in data inconsistency.
• The second deletion is after the database data is modified. At this time, the corresponding data in redis needs to be deleted again. This time it is to delete the first redis deletion and the database data modification. If there is a request, Then the old data will be cached again in redis, but the data in the database will be modified next. If it is not deleted this time, the old data in the database will exist in redis.
• So why do you need to delay deleting redis for a certain period of time after the database is modified the second time?
• In order to wait for the previous read of the database, wait for the data to be written to the cache, and finally delete the dirty data, so it is the time it takes for the data to be sent from the database to the server cache for writing

But delayed double deletion, the delay time is very difficult to determine, so delayed double deletion is not recommended

According to comprehensive considerations, even if the database is modified first, After deleting the cache, there will be a certain period of time when old data is read, which is usually tolerated.

As long as the cache is deleted in time, other threads can read the latest value.

At the same time, in order to ensure that the cache will be deleted, mq can be used to ensure that the cache will be deleted.

If the message is not repeatedly consumed in mq, it will be handed over to other consumers for consumption. (Delete the cache)

Recommended learning:

Redis video tutorial

The above is the detailed content of Cause analysis: delayed double deletion of redis cache. For more information, please follow other related articles on the PHP Chinese website!