让MySQL和Redis数据保持一致的4种策略

1 前言

先分析一下 MySQL 和 Redis 的关系：MySQL 是数据库，用来长期化数据，一定程度上包管数据的可靠性；Redis 是用来当缓存，用来提升数据访问的性能。
关于如何包管 MySQL 和 Redis 中的数据一致（即缓存一致性题目），这是一个非常经典的题目。
使用过缓存的人都应该知道，在现实应用场景中，要想及时候包管缓存和数据库中的数据一样，很难做到。
基本上都是尽大概让他们的数据在绝大部分时间内保持一致，并包管最终是一致的。
1.1 缓存不一致是如何产生的

如果数据不绝没有变更，那么就不会出现缓存不一致的题目。
通常缓存不一致是发生在数据有变更的时间。因为每次数据变更你需要同时操纵数据库和缓存，而他们又属于不同的体系，无法做到同时操纵成功或失败，总会有一个时间差。在并发读写的时间大概就会出现缓存不一致的题目（理论上通太过布式事务可以包管这一点，不过现实上基本上很少有人这么做）。
虽然没办法在数据有变更时，包管缓存和数据库强一致，但对缓存的更新还是有一定设计方法的，遵循这些设计方法，能够让这个不一致的影响时间和影响范围最小化。
1.2 缓存更新的几种设计

缓存更新的设计方法大概有以下四种：

• 先删除缓存，再更新数据库（这种方法在并发下最容易出现长时间的脏数据，不可取）
  
• 先更新数据库，删除缓存（Cache Aside Pattern）
  
• 只更新缓存，由缓存自己同步更新数据库（Read/Write Through Pattern）
  
• 只更新缓存，由缓存自己异步更新数据库（Write Behind Cache Pattern）
  

接下来具体介绍一些这四种设计方法
2 设计方法一：先删除缓存，再更新数据库

这种方法在并发读写的情况下容易出现缓存不一致的题目

如上图所示，其大概的实行流程顺序为：

• 客户端1 触发更新数据A的逻辑
  
• 客户端2 触发查询数据A的逻辑
  
• 客户端1 删除缓存中数据A
  
• 客户端2 查询缓存中数据A，未掷中
  
• 客户端2 从数据库查询数据A，并更新到缓存中
  
• 客户端1 更新数据库中数据A
  

可见，末了缓存中的数据 A 跟数据库中的数据 A 是不一致的，缓存中的数据A是旧的脏数据。
因此一般不建议使用这种方式。
3 设计方法二：先更新数据库，再让缓存失效

这种方法在并发读写的情况下，也大概会出现短暂缓存不一致的题目

如上图所示，其大概实行的流程顺序为：

• 客户端1 触发更新数据A的逻辑
  
• 客户端2 触发查询数据A的逻辑
  
• 客户端3 触发查询数据A的逻辑
  
• 客户端1 更新数据库中数据A
  
• 客户端2 查询缓存中数据A，掷中返回（旧数据）
  
• 客户端1 让缓存中数据A失效
  
• 客户端3 查询缓存中数据A，未掷中
  
• 客户端3 查询数据库中数据A，并更新到缓存中
  

可见，末了缓存中的数据A和数据库中的数据 A 是一致的，理论上大概会出现一小段时间数据不一致，不过这种概率也比力低，大部分的业务也不会有太大的题目。
4 设计方法三：只更新缓存，由缓存自己同步更新数据库（Read/Write Through Pattern）

只更新缓存，由缓存自己同步更新数据库（Read/Write Through Pattern）

如上图所示，其大概实行的流程顺序为：

• 客户端1 触发更新数据 A 的逻辑
  
• 客户端2 触发查询数据 A 的逻辑
  
• 客户端1 更新缓存中数据 A，缓存同步更新数据库中数据 A，再返回效果
  
• 客户端2 查询缓存中数据 A，掷中返回
  

Read Through 和 WriteThrough 的流程雷同，只是在客户端查询数据A时，如果缓存中数据A失效了（逾期或被驱逐淘汰），则缓存会同步去数据库中查询数据A，并缓存起来，再返回给客户端。
这种方式缓存不一致的概率极低，只不过需要对缓存举行专门的改造。
5 只更新缓存，由缓存自己异步更新数据库（Write Behind Cache Pattern）

这种方式性详单于是业务只操纵更新缓存，再由缓存异步去更新数据库，例如：

如上图所示，其大概的实行流程顺序为：

• 客户端1 触发更新数据 A 的逻辑
  
• 客户端2 触发查询数据 A 的逻辑
  
• 客户端1 更新缓存中的数据 A，返回
  
• 客户端2 查询缓存中的数据 A，掷中返回
  
• 缓存异步更新数据 A 到数据库中
  

这种方式的上风是读写的性能都非常好，基本上只要操纵完内存后就返回给客户端了，但是其是非强一致性，存在丢失数据的情况。
如果在缓存异步将数据更新到数据库中时，缓存服务挂了，此时未更新到数据库中的数据就丢失了。
6 小结

上面讲到的几种缓存更新的设计方式，都是前人总结出来的经验，这些方式或多或少都有一些弊端，并不完善，现实上也很难有完善的设计。大家在做体系设计的时间，也不要去追求完善，要有一些弃取，找到一种最适合自己业务场景的方式就行。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。