mysql和redis 一致性 讨论分析

使用redis缓存MysqL数据前提一般是读多更新少的业务场景。 

MysqL和redis 一致性看业务场景实际需要，总的来说可以分为非高并发 一致性处理和高并发场景最终一致性处理，很难做到实时强一致性处理，如果追求强数据一致性，使用分布式锁，但会影响使用redis性能。

下面进行各种场景说明

1、普通并发场景下：数据库数据 更新前和更新后删除确保redis与数据库保持一致

2、延时双删 策略是分布式系统中存储和缓存数据保持一致性的常用策略，但它不是强一致。

更新前数据库前删除缓存，更新数据库后延时删除缓存。更新后可以开启新线程删除，一定不会同步等待这样会很消耗吞吐量和并发量

为什么要延时呢？因为 MysqL 和 redis 主从节点数据不是实时同步的，同步数据需要时间。

延时 是指当前请求逻辑处理延时，而不是当前线程或进程睡眠延时。

3、使用阿里的canal将MysqL的binlog日志采集发送到MQ

最终一致性，以MysqL为例 可以使用阿里的canal将binlog日志采集发送到MQ队列里面，然后通过ACK机制确认处理这条更新消息，删除缓存，保证数据缓存一致性

总结

强一致性：分布式锁

一致性：双删

最终一致性：使用阿里的canal将MysqL的binlog日志采集发送到MQ

MysqL 和 redis 数据一致性是一个复杂的课题，通常是多种策略同时使用，例如：延时双删、redis 过期淘汰、通过路由策略串行处理同类型数据、分布式锁等等

binlog也不能保证实时数据一致性，但是提供了一个性能和数据一致性平衡的方案。追求强数据一致性，使用分布式锁就好了

通过分布式锁可以达到数据强一致性但失去了使用redis高效性的优点

看到的小伙伴如有疑问和建议可以及时讨论。