How to ensure cache consistency in Java

Option 1: Update cache, update database

This method can be easily eliminated, because if the cache is updated successfully first, but the database update fails, it will definitely cause data inconsistency.

Option 2: Update the database and update the cache

This cache update strategy is commonly known as double-write. The problem is: in the scenario of concurrent database updates, dirty data will be flushed to the cache

updateDB();
updateRedis();

Example: If the database and cache are modified by subsequent requests between two operations, updating the cache at this time will already be expired data.

Option 3: Delete the cache and update the database

There is a problem:Before updating the database, if there is a query request, the dirty Data is flushed to the cache

deleteRedis();
updateDB();

Example:If a data query occurs between two operations, old data will be put into the cache.

This solution will lead to inconsistent request data

If there is one request A for an update operation and another request B for a query operation. Then the following situation will occur:

• Request A to perform a write operation and delete the cache

• Request B to query and find that the cache does not exist

• Request B to query the database to get the old value

• Request B to write the old value into the cache

• Request A to write the old value into the cache Writing new values ​​into the database

The above situation will lead to inconsistencies. Moreover, if you do not set an expiration time strategy for the cache, the data will always be dirty data.

Option 4: Update the database and delete the cache

There is a problem:There is a query request before updating the database, and the cache is invalid, the database will be queried, and then the cache will be updated. If a database update operation is performed between querying the database and updating the cache, then the dirty data will be flushed to the cache

updateDB();
deleteRedis();

Example: If there is a query between the database and the cache If data is updated and the cache is deleted during an operation, old data will be put into the cache.

Assume there are two requests, one requesting A to perform a query operation, and the other requesting B to perform an update operation, then the following situation will occur

• The cache just expired

• Request A to query the database and get an old value

• Request B to write the new value into the database

• Request B to delete the cache

• Request A to write the old value found into the cache

If this happens In the above situation, dirty data will indeed occur. However, there is a congenital condition for the above situation to occur, that is, writing a database operation takes less time than reading a database operation

However, the speed of a database read operation is much faster than a write operation

So this situation is difficult to occur.

Comparison of Schemes

Common shortcomings of Scheme 1 and Scheme 2:

In the concurrent database update scenario, dirty data will be flushed to the cache, but Generally, the probability of concurrent writing scenarios is relatively small;

From a thread safety perspective, dirty data will be generated, for example:

• Thread A updated the database

• Thread B updated the database

• Thread B updated the cache

• Thread A updated the cache

Common shortcomings of options 3 and 4:

No matter which order is adopted, there are some problems with both methods:

• Master-slave delay problem: Regardless of whether it is deleted first or last, the database master-slave delay may lead to the generation of dirty data.

• Cache deletion failure: If the cache deletion fails, dirty data will be generated.

Problem solving ideas: delay double deletion and add a retry mechanism, which is introduced below!

Update cache or delete cache?

• 1. Updating the cache cache requires a certain maintenance cost, and there will be problems with concurrent updates

• 2. Write too much In the case of few reads, the read request has not yet come, and the cache has been updated many times, which does not play the role of cache

• 3. The value placed in the cache may have been calculated complexly. , if the value written to the cache is calculated every time it is updated, it will waste performance

Deleting the cache Advantages:Simple, low cost, easy to develop; Disadvantages: Causing a cache miss

If the cost of updating the cache is small and there are more reads and fewer writes, and there is basically no write concurrency, you can update the cache. Otherwise, the general approach is to delete the cache.

总结

方案	问题	问题出现概率	推荐程度
更新缓存 -> 更新数据库	为了保证数据准确性，数据必须以数据库更新结果为准，所以该方案绝不可行	大	不推荐
更新数据库 -> 更新缓存	并发更新数据库场景下，会将脏数据刷到缓存	并发写场景，概率一般	写请求较多时会出现不一致问题，不推荐使用。
删除缓存 -> 更新数据库	更新数据库之前，若有查询请求，会将脏数据刷到缓存	并发读场景，概率较大	读请求较多时会出现不一致问题，不推荐使用
更新数据库 -> 删除缓存	在更新数据库之前有查询请求，并且缓存失效了，会查询数据库，然后更新缓存。如果在查询数据库和更新缓存之间进行了数据库更新的操作，那么就会把脏数据刷到缓存	并发读场景&读操作慢于写操作，概率最小	读操作比写操作更慢的情况较少，相比于其他方式出错的概率小一些。勉强推荐。

推荐方案

延迟双删

采用更新前后双删除缓存策略

public void write(String key,Object data){
  redis.del(key);
     db.update(data);
     Thread.sleep(1000);
     redis.del(key);
 }

• 先淘汰缓存

• 再写数据库

• 休眠1秒，再次淘汰缓存

大家应该评估自己的项目的读数据业务逻辑的耗时。然后写数据的休眠时间则在读数据业务逻辑的耗时基础上即可。

这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。

问题及解法：

1、同步删除，吞吐量降低如何处理

将第二次删除作为异步的，提交一个延迟的执行任务

2、解决删除失败的方式：

添加重试机制，例如：将删除失败的key，写入消息队列；但对业务耦合有些严重；

延时工具可以选择：

最普通的阻塞Thread.currentThread().sleep(1000);

Jdk调度线程池，quartz定时任务，利用jdk自带的delayQueue，netty的HashWheelTimer，Rabbitmq的延时队列，等等

实际场景

我们有个商品中心的场景，是读多写少的服务，并且写数据会发送MQ通知下游拿数据，这样就需要严格保证缓存和数据库的一致性，需要提供高可靠的系统服务能力。

写缓存策略

• 缓存key设置失效时间

• 先DB操作，再缓存失效

• 写操作都标记key（美团中间件）强制走主库

• 接入美团中间件监听binlog（美团中间件）变化的数据在进行兜底，再删除缓存

读缓存策略

• 先判断是否走主库

• 如果走主库，则使用标记（美团中间件）查主库

• 如果不是，则查看缓存中是否有数据

• 缓存中有数据，则使用缓存数据作为结果

• 如果没有，则查DB数据，再写数据到缓存

注意

关于缓存过期时间的问题

如果缓存设置了过期时间，那么上述的所有不一致情况都只是暂时的。

但是如果没有设置过期时间，那么不一致问题就只能等到下次更新数据时解决。

所以一定要设置缓存过期时间。

The above is the detailed content of How to ensure cache consistency in Java. For more information, please follow other related articles on the PHP Chinese website!