共计 1515 个字符，预计需要花费 4 分钟才能阅读完成。
这篇文章将为大家详细讲解有关数据库缓存最终一致性的四种方案分别是什么，文章内容质量较高，因此丸趣 TV 小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
背景
缓存是软件开发中一个非常有用的概念，数据库缓存更是在项目中必然会遇到的场景。而缓存一致性的保证，更是在面试中被反复问到，这里进行一下总结，针对不同的要求，选择恰到好处的一致性方案。
缓存是什么
存储的速度是有区别的。缓存就是把低速存储的结果，临时保存在高速存储的技术。
如图所示，金字塔更上面的存储，可以作为下面存储的缓存。我们本次的讨论，主要针对数据库缓存场景，将以 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 同步机制，成本较大。
关于数据库缓存最终一致性的四种方案分别是什么就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
