update redis

docs/redis/redis.md

@@ -415,25 +415,95 @@ Redis cluster采用**虚拟槽分区**，所有的键根据哈希函数映射到
 
 **内存淘汰策略可以通过配置文件来修改**，相应的配置项是`maxmemory-policy`，默认配置是`noeviction`。
 
-## 如何保证缓存与数据库双写时的数据一致性？
+## MySQL 与 Redis 如何保证数据一致性
 
-**1、先删除缓存再更新数据库**
+**缓存不一致是如何产生的**
 
-进行更新操作时，先删除缓存，然后更新数据库，后续的请求再次读取时，会从数据库读取后再将新数据更新到缓存。
+如果数据一直没有变更，那么就不会出现缓存不一致的问题。
 
-存在的问题：删除缓存数据之后，更新数据库完成之前，这个时间段内如果有新的读请求过来，就会从数据库读取旧数据重新写到缓存中，再次造成不一致，并且后续读的都是旧数据。
+通常缓存不一致是发生在数据有变更的时候。 因为每次数据变更你需要同时操作数据库和缓存，而他们又属于不同的系统，无法做到同时操作成功或失败，总会有一个时间差。在并发读写的时候可能就会出现缓存不一致的问题（理论上通过分布式事务可以保证这一点，不过实际上基本上很少有人这么做）。
 
-**2、先更新数据库再删除缓存**
+虽然没办法在数据有变更时，保证缓存和数据库强一致，但对缓存的更新还是有一定设计方法的，遵循这些设计方法，能够让这个不一致的影响时间和影响范围最小化。
 
-进行更新操作时，先更新MySQL，成功之后，删除缓存，后续读取请求时再将新数据回写缓存。
+缓存更新的设计方法大概有以下四种：
 
-存在的问题：更新MySQL和删除缓存这段时间内，请求读取的还是缓存的旧数据，不过等数据库更新完成，就会恢复一致，影响相对比较小。
+- 先删除缓存，再更新数据库（这种方法在并发下最容易出现长时间的脏数据，不可取）
+- 先更新数据库，删除缓存（Cache Aside Pattern）
+- 只更新缓存，由缓存自己同步更新数据库（Read/Write Through Pattern）
+- 只更新缓存，由缓存自己异步更新数据库（Write Behind Cache Pattern）
 
-**3、异步更新缓存**
+**先删除缓存，再更新数据库**
 
-数据库的更新操作完成后不直接操作缓存，而是把这个操作命令封装成消息扔到消息队列中，然后由Redis自己去消费更新数据，消息队列可以保证数据操作顺序一致性，确保缓存系统的数据正常。
+这种方法在并发读写的情况下容易出现缓存不一致的问题
 
-以上几个方案都不完美，需要根据业务需求，评估哪种方案影响较小，然后选择相应的方案。
+![](http://img.topjavaer.cn/img/202304300910876.png)
+
+如上图所示，其可能的执行流程顺序为：
+
+- 客户端1 触发更新数据A的逻辑
+- 客户端2 触发查询数据A的逻辑
+- 客户端1 删除缓存中数据A
+- 客户端2 查询缓存中数据A，未命中
+- 客户端2 从数据库查询数据A，并更新到缓存中
+- 客户端1 更新数据库中数据A
+
+可见，最后缓存中的数据A跟数据库中的数据A是不一致的，缓存中的数据A是旧的脏数据。
+
+因此一般不建议使用这种方式。
+
+**先更新数据库，再让缓存失效**
+
+这种方法在并发读写的情况下，也可能会出现短暂缓存不一致的问题
+
+![](http://img.topjavaer.cn/img/202304300912362.png)
+
+如上图所示，其可能执行的流程顺序为：
+
+- 客户端1 触发更新数据A的逻辑
+- 客户端2 触发查询数据A的逻辑
+- 客户端3 触发查询数据A的逻辑
+- 客户端1 更新数据库中数据A
+- 客户端2 查询缓存中数据A，命中返回（旧数据）
+- 客户端1 让缓存中数据A失效
+- 客户端3 查询缓存中数据A，未命中
+- 客户端3 查询数据库中数据A，并更新到缓存中
+
+可见，最后缓存中的数据A和数据库中的数据A是一致的，理论上可能会出现一小段时间数据不一致，不过这种概率也比较低，大部分的业务也不会有太大的问题。
+
+**只更新缓存，由缓存自己同步更新数据库（Read/Write Through Pattern）**
+
+这种方法相当于是业务只更新缓存，再由缓存去同步更新数据库。 一个Write Through的 例子如下：
+
+![](http://img.topjavaer.cn/img/202304300913692.png)
+
+如上图所示，其可能执行的流程顺序为：
+
+- 客户端1 触发更新数据A的逻辑
+- 客户端2 触发查询数据A的逻辑
+- 客户端1 更新缓存中数据A，缓存同步更新数据库中数据A，再返回结果
+- 客户端2 查询缓存中数据A，命中返回
+
+Read Through 和 WriteThrough 的流程类似，只是在客户端查询数据A时，如果缓存中数据A失效了（过期或被驱逐淘汰），则缓存会同步去数据库中查询数据A，并缓存起来，再返回给客户端
+
+这种方式缓存不一致的概率极低，只不过需要对缓存进行专门的改造。
+
+**只更新缓存，由缓存自己异步更新数据库（Write Behind Cache Pattern）**
+
+这种方式性详单于是业务只操作更新缓存，再由缓存异步去更新数据库，例如：
+
+![](http://img.topjavaer.cn/img/202304300913082.png)
+
+如上图所示，其可能的执行流程顺序为：
+
+- 客户端1 触发更新数据A的逻辑
+- 客户端2 触发查询数据A的逻辑
+- 客户端1 更新缓存中的数据A，返回
+- 客户端2 查询缓存中的数据A，命中返回
+- 缓存异步更新数据A到数据库中
+
+这种方式的优势是读写的性能都非常好，基本上只要操作完内存后就返回给客户端了，但是其是非强一致性，存在丢失数据的情况。
+
+如果在缓存异步将数据更新到数据库中时，缓存服务挂了，此时未更新到数据库中的数据就丢失了。
 
 ## 缓存常见问题