使用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高效性的优点
看到的小伙伴如有疑问和建议可以及时讨论。
标签：缓存,redis,延时,mysql,一致性,数据 来源： https://www.cnblogs.com/liyanbofly/p/16545725.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。