缓存是软件开发中一个非常有用的概念，数据库缓存更是在项目中必然会遇到的场景。而缓存一致性的保证，更是在面试中被反复问到，这里进行一下总结，针对不同的要求，选择恰到好处的一致性方案。
缓存是什么
存储的速度是有区别的。缓存就是把低速存储的结果，临时保存在高速存储的技术。
我们本次的讨论，主要针对数据库缓存场景，将以redis作为mysql的缓存为案例来进行。
为什么需要缓存
存储如mysql通常支持完整的ACID特性，因为可靠性，持久性等因素，性能普遍不高，高并发的查询会给mysql带来压力，造成数据库系统的不稳定。同时也容易产生延迟。根据局部性原理，80%请求会落到20%的热点数据上，在读多写少场景，增加一层缓存非常有助提升系统吞吐量和健壮性。
redis作为mysql缓存
通常的开发模式中，都会使用mysql作为存储，而redis作为缓存，加速和保护mysql。但是，当mysql数据更新之后，redis怎么保持同步呢。
强一致性同步成本太高，如果追求强一致，那么没必要用缓存了，直接用mysql即可。通常考虑的，都是最终一致性。
存在问题
存储的数据随着时间可能会发生变化，而缓存中的数据就会不一致。具体能容忍的不一致时间，需要具体业务具体分析，但是通常的业务，都需要做到最终一致。
解决方案
一、通过key的过期时间，mysql更新时，redis不更新。这种方式实现简单，但不一致的时间会很长。如果读请求非常频繁，且过期时间比较长，则会产生很多长期的脏数据。
优点：
开发成本低，易于实现；
管理成本低，出问题的概率会比较小。
不足
完全依赖过期时间，时间太短容易缓存频繁失效，太长容易有长时间更新延迟（不一致）
二、通过订阅binlog来更新redis，把我们搭建的消费服务，作为mysql的一个slave，订阅binlog，解析出更新内容，再更新到redis。
优点
在mysql压力不大情况下，延迟较低；
和业务完全解耦；
解决了时序性问题。
缺点
要单独搭建一个同步服务，并且引入binlog同步机制，成本较大。
总结
方案选型
首先确认产品上对延迟性的要求，如果要求极高，且数据有可能变化，别用缓存。
通常来说，方案1就够了，笔者咨询过4，5个团队，基本都是用方案1，因为能用缓存方案，通常是读多写少场景，同时业务上对延迟具有一定的包容性。方案1没有开发成本，其实比较实用。
如果想增加更新时的即时性，就选择方案2，不过没必要做重试保证之类的。
结束语：以上就是关于数据库的缓存区别对比的全部内容，更多内容请关注学步园。