针对读写缓存时:同步直写,更新数据库 更新缓存
针对只读缓存时:更新数据库 删除缓存
较为通用的一致性策略拟定:
在并发场景下,使用“更新数据库 更新缓存”需要用分布式锁保证缓存和数据一致性,且可能存在“缓存资源浪费”和“机器性能浪费”的情况;一般推荐使用“更新数据库 删除缓存”的方案。如果根据需要,热点数据较多,可以使用“更新数据库 更新缓存”策略。
在“更新数据库 删除缓存”的方案中,推荐使用推荐用“先更新数据库,再删除缓存”策略,因为先删除缓存可能会导致大量请求落到数据库,而且延迟双删的时间很难评估。
在“先更新数据库,再删除缓存”策略中,可以使用“消息队列 重试机制”的方案保证缓存的删除。并通过“订阅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智慧零售研发中心后台开发工程师,硕士研究生,毕业于中南大学。目前负责腾讯智慧零售业务的后端研发工作。
技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。
高可用架构
改变互联网的构建方式