数据库缓存最终一致性的四种方案

背景

缓存是软件开发中一个很是有用的概念，数据库缓存更是在项目中必然会遇到的场景。而缓存一致性的保证，更是在面试中被反复问到，这里进行一下总结，针对不一样的要求，选择恰到好处的一致性方案。

缓存是什么

存储的速度是有区别的。缓存就是把低速存储的结果，临时保存在高速存储的技术。

如图所示，金字塔更上面的存储，能够做为下面存储的缓存。

咱们本次的讨论，主要针对数据库缓存场景，将以redis做为mysql的缓存为案例来进行。

为何须要缓存

存储如mysql一般支持完整的ACID特性，由于可靠性，持久性等因素，性能广泛不高，高并发的查询会给mysql带来压力，形成数据库系统的不稳定。同时也容易产生延迟。根据局部性原理，80%请求会落到20%的热点数据上，在读多写少场景，增长一层缓存很是有助提高系统吞吐量和健壮性。

存在问题

存储的数据随着时间可能会发生变化，而缓存中的数据就会不一致。具体能容忍的不一致时间，须要具体业务具体分析，可是一般的业务，都须要作到最终一致。

redis做为mysql缓存

一般的开发模式中，都会使用mysql做为存储，而redis做为缓存，加速和保护mysql。可是，当mysql数据更新以后，redis怎么保持同步呢。

强一致性同步成本过高，若是追求强一致，那么不必用缓存了，直接用mysql便可。一般考虑的，都是最终一致性。

解决方案

方案一

经过key的过时时间，mysql更新时，redis不更新。 这种方式实现简单，但不一致的时间会很长。若是读请求很是频繁，且过时时间比较长，则会产生不少长期的脏数据。

优势：

• 开发成本低，易于实现；
• 管理成本低，出问题的几率会比较小。

不足

• 彻底依赖过时时间，时间过短容易缓存频繁失效，太长容易有长时间更新延迟（不一致）

方案二

在方案一的基础上扩展，经过key的过时时间兜底，而且，在更新mysql时，同时更新redis。

优势

• 相对方案一，更新延迟更小。

不足

• 若是更新mysql成功，更新redis却失败，就退化到了方案一；
• 在高并发场景，业务server须要和mysql,redis同时进行链接。这样是损耗双倍的链接资源，容易形成链接数过多的问题。

方案三

针对方案二的同步写redis进行优化，增长消息队列，将redis更新操做交给kafka，由消息队列保证可靠性，再搭建一个消费服务，来异步更新redis。

优势

• 消息队列能够用一个句柄，不少消息队列客户端还支持本地缓存发送，有效解决了方案二链接数过多的问题；
• 使用消息队列，实现了逻辑上的解耦；
• 消息队列自己具备可靠性，经过手动提交等手段，能够至少一次消费到redis。

不足

• 依旧解决不了时序性问题，若是多台业务服务器分别处理针对同一行数据的两条请求，举个栗子，a = 1； a = 5;，若是mysql中是第一条先执行，而进入kafka的顺序是第二条先执行，那么数据就会产生不一致。
• 引入了消息队列，同时要增长服务消费消息，成本较高。

方案四

经过订阅binlog来更新redis，把咱们搭建的消费服务，做为mysql的一个slave，订阅binlog，解析出更新内容，再更新到redis。

优势

• 在mysql压力不大状况下，延迟较低；
• 和业务彻底解耦；
• 解决了时序性问题。

缺点

• 要单独搭建一个同步服务，而且引入binlog同步机制，成本较大。

总结

方案选型

1. 首先确认产品上对延迟性的要求，若是要求极高，且数据有可能变化，别用缓存。
2. 一般来讲，方案1就够了，笔者咨询过4，5个团队，基本都是用方案1，由于能用缓存方案，一般是读多写少场景，同时业务上对延迟具备必定的包容性。方案1没有开发成本，其实比较实用。
3. 若是想增长更新时的即时性，就选择方案2，不过不必作重试保证之类的。
4. 方案3，方案4针对于对延时要求比较高业务，一个是推模式，一个是拉模式，而方案4具有更强的可靠性，既然都愿意花功夫作处理消息的逻辑，不如一步到位，用方案4。

结论

通常状况，方案1够用。若延时要求高，直接选择方案4。若是是面试场景，从简单讲到复杂，面试官会一步一步追问，我们就一点点推导，宾主尽欢。