针对读写缓存时：同步直写，更新数据库 更新缓存
针对只读缓存时：更新数据库 删除缓存
较为通用的一致性策略拟定：
在并发场景下，使用“更新数据库 更新缓存”需要用分布式锁保证缓存和数据一致性，且可能存在“缓存资源浪费”和“机器性能浪费”的情况；一般推荐使用“更新数据库 删除缓存”的方案。如果根据需要，热点数据较多，可以使用“更新数据库 更新缓存”策略。
在“更新数据库 删除缓存”的方案中，推荐使用推荐用“先更新数据库，再删除缓存”策略，因为先删除缓存可能会导致大量请求落到数据库，而且延迟双删的时间很难评估。
在“先更新数据库，再删除缓存”策略中，可以使用“消息队列 重试机制”的方案保证缓存的删除。并通过“订阅binlog”进行缓存比对，加上一层保障。
此外，需要通过初始化缓存预热、多数据源触发、延迟消息比对等策略进行辅助和补偿。【多种数据更新触发源：定时任务扫描，业务系统MQ、binlog变更MQ，相互之间作为互补来保证数据不会漏更新】
三、数据不一致性需注意其他问题
(一) k-v大小的合理设置
Redis key大小设计：由于网络的一次传输MTU最大为1500字节，所以为了保证高效的性能，建议单个k-v大小不超过1KB，一次网络传输就能完成，避免多次网络交互；k-v是越小性能越好
Redis热key：当业务遇到单个读热key，通过增加副本来提高读能力或是用hashtag把key存多份在多个分片中。
当业务遇到单个写热key，需业务拆分这个key的功能，属于设计不合理-当业务遇到热分片，即多个热key在同一个分片上导致单分片cpu高，可通过hashtag方式打散。
（二）避免其他问题导致缓存服务器崩溃，进而简直导致数据一致性策略失效缓存穿透、缓存击穿、缓存雪崩、机器故障等问题
（三）方案选定的思路
确定缓存类型（读写/只读）
确定一致性级别
确定同步/异步方式
选定缓存流程
补充细节
参考资料：
1.Redis与MySQL双写一致性如何保证
2.干货|携程最终一致和强一致性缓存实践
3.大厂都是怎么做MySQL to Redis同步的
4.缓存与数据库一致性策略
5.缓存与数据库一致性保证
6.如何解决缓存和数据库的数据不一致问题
7.Redis经典问题，缓存(穿透，雪崩，击穿，数据不一致，数据并发竞争，HotKey，BigKey)，分布式锁(watch乐观锁，setnx，Redisson)
8.Redisson分布式锁场景和使用
作者简介
徐鑫
腾讯后台开发工程师
腾讯CSIG智慧零售研发中心后台开发工程师，硕士研究生，毕业于中南大学。目前负责腾讯智慧零售业务的后端研发工作。
技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。
高可用架构
改变互联网的构建方式
