【九月打卡】第14天 缓存数据双写一致

课程名称：Spring Cloud 进阶 Alibaba 微服务体系自媒体实战
课程章节： 第3章 开发通行证有关服务
主讲老师： 风间影月

课程内容

用户更新数据前，先把缓存数据删除，然后更新到数据库，再同步到redis中，哪怕redis存入不成功，那么后续用户发起请求还是可以先查库后存缓存，达到一致性。

// 双写一致，先删除redis，在更新，再设置redis

redis.del(REDIS_USER_INFO + ":" + userId);

缓存双删，用户把新数据保存到数据库后，sleep1秒或半秒后再次删除。

// 缓存双删策略
try {
    Thread.sleep(200);
redis.del(REDIS_USER_INFO + ":" + userId);
    redis.set(REDIS_USER_INFO + ":" + userId, JsonUtils.objectToJson(user), 7);
} catch (InterruptedException e) {
    e.printStackTrace();
}

• 从业务角度分析：并发请求绝大多数在首页和新闻详情页，用户的查询是很多的。如果出现了1-2秒的脏数据缓存，那么首页展示的用户昵称或者用户头像可能是老数据，但是对于整个系统来讲无所谓，没有太大的影响，而且用户的注意力是在新闻上，而不是新闻发布者，所以有几秒的不一致是无所谓的，因为热点数据的并发读是很大的，一旦删除，那么这个时候由于缓存击穿，数据库可能会瞬间被炸了，直接宕机。所以务必以系统可用性为优先考虑。

课程收获

一般来说，如果允许缓存可以稍微的跟数据库偶尔有不一致的情况，也就是说如果你的系统不是严格要求 “缓存+数据库” 必须保持一致性的话，最好不要做这个方案，即：读请求和写请求串行化，串到一个内存队列里去。

串行化可以保证一定不会出现不一致的情况，但是它也会导致系统的吞吐量大幅度降低，用比正常情况下多几倍的机器去支撑线上请求。

为什么上亿流量高并发场景下，缓存会出现这个问题？
只有在对一个数据在并发的进行读写的时候，才可能会出现这种问题。其实如果说你的并发量很低的话，特别是读并发很低，每天访问量就 1 万次，那么很少的情况下，会出现刚才描述的那种不一致的场景。但是问题是，如果每天的是上亿的流量，每秒并发读是几万，每秒只要有数据更新的请求，就可能会出现上述的数据库+缓存不一致的情况。

解决方案如下：
更新数据的时候，根据数据的唯一标识，将操作路由之后，发送到一个 jvm 内部队列中。读取数据的时候，如果发现数据不在缓存中，那么将重新读取数据+更新缓存的操作，根据唯一标识路由之后，也发送同一个 jvm 内部队列中。

一个队列对应一个工作线程，每个工作线程串行拿到对应的操作，然后一条一条的执行。这样的话，一个数据变更的操作，先删除缓存，然后再去更新数据库，但是还没完成更新。此时如果一个读请求过来，读到了空的缓存，那么可以先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成。

这里有一个优化点，一个队列中，其实多个更新缓存请求串在一起是没意义的，因此可以做过滤，如果发现队列中已经有一个更新缓存的请求了，那么就不用再放个更新请求操作进去了，直接等待前面的更新操作请求完成即可。

待那个队列对应的工作线程完成了上一个操作的数据库的修改之后，才会去执行下一个操作，也就是缓存更新的操作，此时会从数据库中读取最新的值，然后写入缓存中。
如果请求还在等待时间范围内，不断轮询发现可以取到值了，那么就直接返回；如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取当前的旧值。

课程截图