1. 面试题

背景

问题，上面业务逻辑你用java代码如何写？

 

2. 缓存双写一致性谈谈你的理解？

 3. 双检加锁策略

多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个 互斥锁来锁住它。

其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后做缓存。

后面的线程进来发现已经有缓存了，就直接走缓存。 

4. 数据库和缓存一致性的几种更新策略

目的

给缓存设置过期时间，定期清理缓存并回写，是保证最终一致性的解决方案。

 

我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存，达到一致性，切记，要以mysql的数据库写入库为准。

4.1 可以停机的情况下

凌晨维护，服务降级

单线程，这种重量级数据操作最好不要多线程 

4.2 不停机情况下四种更新策略

4.2.1 先更新数据库在更新缓存

异常情况1

 1 先更新mysql的某商品的库存，当前商品的库存是100，更新为99个。

 

 2 先更新mysql修改为99成功，然后更新redis。

 

 3 此时假设异常出现，更新redis失败了，这导致mysql里面的库存是99而redis里面的还是100 。

 

 4  上述发生，会让数据库里面和缓存redis里面数据不一致，读到redis脏数据

异常情况2

【先更新数据库，再更新缓存】，A、B两个线程发起调用

【正常逻辑】

1 A update mysql 100

2 A update redis 100

3 B update mysql 80

4 B update redis 80

=============================

【异常逻辑】多线程环境下，A、B两个线程有快有慢，有前有后有并行

1 A update mysql 100

3 B update mysql 80

4 B update redis 80

2 A update redis 100

 =============================

最终结果，mysql和redis数据不一致，o(╥﹏╥)o，

mysql80,redis100

4.2.2 先更新缓存在更新数据库

不推荐该做法，因为业务上一般以mysql数据库作为底单数据库（类似于数据原件），所有数据以MySQL数据库为准，而redis可以理解为副本 （拷贝）

异常情况

【先更新缓存，再更新数据库】，A、B两个线程发起调用

【正常逻辑】

1 A update redis 100

2 A update mysql 100

3 B update redis 80

4 B update mysql 80

====================================

【异常逻辑】多线程环境下，A、B两个线程有快有慢有并行

A update redis  100

B update redis  80

B update mysql 80

A update mysql 100

 

----mysql100,redis80

4.2.3 先删缓存再更新数据库

异常情况

（1）请求A进行写操作，删除redis缓存后，工作正在进行中，更新mysql......A还么有彻底更新完mysql，还没commit

（2）请求B开工查询，查询redis发现缓存不存在(被A从redis中删除了)

（3）请求B继续，去数据库查询得到了mysql中的旧值(A还没有更新完)

（4）请求B将旧值写回redis缓存

（5）请求A将新值写入mysql数据库 

上述情况就会导致不一致的情形出现。 

时间	线程A	线程B	出现的问题
t1	请求A进行写操作，删除缓存成功后，工作正在mysql进行中......
t2		1 缓存中读取不到，立刻读mysql，由于A还没有对mysql更新完，读到的是旧值 2 还把从mysql读取的旧值，写回了redis	1 A还没有更新完mysql，导致B读到了旧值 2 线程B遵守回写机制，把旧值写回redis，导致其它请求读取的还是旧值，A白干了。
t3	A更新完mysql数据库的值，over		redis是被B写回的旧值， mysql是被A更新的新值。 出现了，数据不一致问题。

总结一下：

先删除缓存，再更新数据库

如果数据库更新失败或超时或返回不及时，导致B线程请求访问缓存时发现redis里面没数据，缓存缺失，B再去读取mysql时， 从数据库中读取到旧值，还写回redis，导致A白干了，o(╥﹏╥)o

 异常解决方案：延迟双删

假设有A、B两个线程，A先把缓存进行删除，此时正在写入数据（但未完成），B进行查询操作，发现缓存内没有命令数据就到MySQL数据中进行数据查询，因为线程A还未完成更新数据，故B线程查到的为旧数据并写入到缓存中，当线程B完成以上一系列操作后，A线程完成数据更新就会把缓存的数据再次删除（延迟双删），当下一个线程来查询数据时发现缓存没有就会到数据库中重新查询，此时查询并回写的数据为最新的数据，保证了数据一致性

 延迟双删面试题

1. 这个删除该休眠多久

线程A sleep的时间，就需要大于线程B读取数据再写入缓存的时间。

 

这个时间怎么确定呢？

 第一种方法：

在业务程序运行的时候，统计下线程读数据和写缓存的操作时间，自行评估自己的项目的读数据业务逻辑的耗时，

以此为基础来进行估算。然后写数据的休眠时间则在读数据业务逻辑的耗时基础上加百毫秒即可。

 

 

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

 

 第二种方法：

 

新启动一个后台监控程序，比如后面要讲解的WatchDog监控程序，会加时

2. 这种同步淘汰策略，吞吐量降低怎么解决？

异步删除 

4.2.4 先更数据库在删除缓存 

异常问题

 先更新数据库，再删除缓存

时间	线程A	线程B	出现的问题
t1	更新数据库中的值......
t2		缓存中立刻命中，此时B读取的是缓存旧值。	A还没有来得及删除缓存的值，导致B缓存命中读到旧值。
t3	更新缓存的数据，over

先更新数据库，再删除缓存

假如缓存删除失败或者来不及，导致请求再次访问redis时缓存命中， 读取到的是缓存旧值。

解决方案

1 可以把要删除的缓存值或者是要更新的数据库值暂存到消息队列中（例如使用Kafka/RabbitMQ等）。 2 当程序没有能够成功地删除缓存值或者是更新数据库值时，可以从消息队列中重新读取这些值，然后再次进行删除或更新。 3 如果能够成功地删除或更新，我们就要把这些值从消息队列中去除，以免重复操作，此时，我们也可以保证数据库和缓存的数据一致了，否则还需要再次进行重试 4 如果重试超过的一定次数后还是没有成功，我们就需要向业务层发送报错信息了，通知运维人员。

 

总结

在大多数业务场景下， 

优先使用先更新数据库，再删除缓存的方案(先更库→后删存)。理由如下：

 

1 先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力导致打满mysql。

 

2 如果业务应用中读取数据库和写缓存的时间不好估算，那么，延迟双删中的等待时间就不好设置。

 

 多补充一句：如果使用先更新数据库，再删除缓存的方案

如果业务层要求必须读取一致性的数据，那么我们就需要在更新数据库时，先在Redis缓存客户端暂停并发读请求，等数据库更新完、缓存值删除后，再读取数据，从而保证数据一致性，这是理论可以达到的效果，但 实际，不推荐，因为真实生产环境中，分布式下很难做到实时一致性， 一般都是最终一致性，请大家参考。

策略	高并发多线程条件下	问题	现象	解决方案
先删除redis缓存，再更新mysql	无	缓存删除成功但数据库更新失败	Java程序从数据库中读到旧值	再次更新数据库，重试
	有	缓存删除成功但数据库更新中...... 有并发读请求	并发请求从数据库读到旧值并回写到redis，导致后续都是从redis读取到旧值	延迟双删
先更新mysql，再删除redis缓存	无	数据库更新成功，但缓存删除失败	Java程序从redis中读到旧值	再次删除缓存，重试
	有	数据库更新成功但缓存删除中...... 有并发读请求	并发请求从缓存读到旧值	等待redis删除完成，这段时间有 数据不一致，短暂存在。