通过key的过期时间，mysql更新时，redis不更新。这种方式实现简单，但不一致的时间会很长。如果读请求十分频繁，且过期时间比较长，则会产生很多长期的脏数据。优点：开发成本低，易于实现；管理成本低，出难题的概率会比较小。不足完全依赖过期时间，时间太短容易内存频繁失效，太长容易有长时间更新延迟（不一致）

计划二

在计划一的基础上扩展，通过key的过期时间兜底，并且，在更新mysql时，同时更新redis。

同时更新redis优点相对计划一，更新延迟更小。不足如果更新mysql成功，更新redis却失败，就退化到了计划一；在高并发情景，业务server须要和mysql,redis同时展开连接。这样是损耗双倍的连接资源，容易造成连接数过多的难题。

计划三

特别针对计划二的同步写redis展开优化，增加消息队列，将redis更新操作交给kafka，由消息队列确保可靠性，再搭建两个消费服务，来异步更新redis。

优点

消息队列能用两个句柄，很多消息队列客户端还支持本地内存发送，有效解决了计划二连接数过多的难题；

使用消息队列，实现了逻辑上的解耦；

消息队列本身具有可靠性，通过手动提交等手段，能至少一次消费到redis。

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

计划四

通过订阅binlog来更新redis，把他们搭建的消费服务，做为mysql的两个slave，订阅binlog，解析出更新内容，再更新到redis。 4 种数据库缓存最终一致性的优缺点对比？最终选择方案四！

优点

在mysql压力不大情况下，延迟较低；和业务完全解耦；解决了时序性难题。缺点要单独搭建两个同步服务，并且引入binlog同步机制，成本较大。

归纳

计划选型

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