Redis（高阶篇）03章——缓存双写一致性之更新策略探讨

一、反馈回来的面试题

1. 一图
2. 你只要用缓存，就可能会涉及到redis缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性的问题
3. 双写一致性，你先动缓存redis还是数据库mysql哪一个？why？
4. 延时删除你做过吗？会有哪些问题？
5. 有这么一种情况，微服务查询redis无 MySQL有，为保证数据双写一致性回写redis你需要注意什么？双检加锁策略你了解过吗？如何尽量避免缓存击穿？
6. redis和MySQL双写100%会出纰漏，做不到强一致性，你如何保证最终一致性？

二、缓存双写一致性，谈谈你的理解

（1）如果redis中有数据

需要和数据库中的值相同

（2）如果redis中无数据

数据库中的值要是最新值，且准备回写redis

（3）缓存按照操作来分，细分两种

2.3.1只读缓存

2.3.2读写缓存

（1）同步直写策略

1. 写数据库之后也同步写redis缓存，缓存和数据库中的数据一致；
2. 对于读写缓存来说，要想保证缓存和数据库中的数据一致，就要采用同步直写策略

（2）异步缓写策略

1. 正常业务中，MySQL数据变了，但是可以在业务上容许出现一定时间后才作用于redis，比如仓库、物流系统
2. 异常情况出现了， 不得不将失败的动作重新修补，有可能需要借助kafka或者RabbitMQ等消息中间件，实现重试重写

（4）一图代码你如何写

2.4.1问题？

2.4.2采用双检加锁策略

1. 什么是双检加锁策略？
2. 代码：

2.4.3Code

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

（1）目的：总之，我们要达到最终一致性

（2）可以停机的情况

1. 挂牌报错，凌晨升级，温馨提示，服务降级
2. 单线程，这样重量级的数据操作最好不要多线程

（3）我们讨论四种更新策略

3.3.1先更新数据库再更新缓存

1. 异常问题1：
2. 异常问题2：

3.3.2先更新缓存再更新数据库

1. 不太推荐：业务上一般把MySQL作为底单数据库 ，保证最后解释
2. 异常问题2：

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

（1）异常问题

1. 分析步骤1，先删除缓存，再更新数据库
2. 分析步骤2，先删除缓存，再更新数据库
3. 分析步骤3，先删除缓存，再更新数据库
4. 上面3步骤串讲梳理

（2）解决方案

1. 采用延时双删策略：
2. 双删方案面试题：
   1. 这个删除该休眠多久呢？
   2. 这种同步淘汰策略，吞吐量降低怎么办？
   3. 后续看门狗WatchDog源码分析
   4. 延时双删导致吞吐量降低的原因：

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

（1）异常问题

（2）业务指导思想

1. 微软云：Cache-Aside pattern - Azure Architecture Center | Microsoft Learn
2. 我们后面的阿里巴巴canal也是类似的思想：订阅binlog程序在MySQL中有现成的中间件叫canal，可以完成订阅binlog日志的功能

（3）解决方案

（4）类似经典的分布式事务问题，只有一个权威答案

1. 流量充值，先下发短信实际充值可能滞后5分钟，可以接受
2. 电商发货，短信下发但是物流明天见

（4）小总结

3.4.1如何选择方案，利弊如何？

3.4.2一图总结