高频面试题-高并发下如何保证Redis与DB的数据一致性

charlielin6:
一个小建议，文档太小了 只占屏幕的一半…左边目录没必要那么大

【回复】[抱拳]，感谢建议，后续改进.
白干老酒烫一壶啊:
最后钟方案Redis压力非常大，所以对它要求比较高，得集群加哨兵吧。视频非常不错，恬着老脸求份文档[笑哭]

【回复】是的，这类超高并发，使用独立的redis集群跟业务分开，避免影响主业务。另外，redis哨兵写入有性能瓶颈，一般都用cluster集群，私信我，发你文档[抱拳]
【回复】我理解你的意思，redis高可用哨兵方案因为只有主节点能写入，高并发写的场景，它的写入能力会有瓶颈，所以要换成redis cluster高可用方案，具体技术选型可以参考我的另外一个redis高可用方案视频
【回复】回复 @所得税增值税消费税 :现在报表实时方案一般都是canal+kafka+flink+es或者clickhouse
灵恝氐人:
考虑2级缓存，第一级抗压力抗流量，第二级作为第一级的热点数据，后面才是db。 作为增删改而言，直接面相db要看是否需要强事物，就目前4个模型而言都是若事物性，扛流量为先，不适合交易系统，适合浏览性系统，最终一致即可。第三种再面临1e级别以上的数据量的时候是灾难，估计500w可能都难以支持，如果强用这种方式会加大开发难度和设计难度。

【回复】交易系统，考虑actor模型+mq消费，虽然难用
【回复】回复 @灵恝氐人 :actor模式研究过一阵，很灵活，不过没敢线上用。如果actor事件处理异常，怎么做到一致性是个大问题。
【回复】回复 @灵恝氐人 :没明白，能详细说下吗？用目mq在我理解还是最终一致性
葱猫:
第二个方案没懂，他这个删除是说一个方案只能做删除么，新增是怎么搞的

【回复】[笑哭]注意看视频，查询的时候，查不到有写入
711_117:
少量一致性要求高的去掉redis，上分布式数据库，想想没有redis的时候银行就不过了？

【回复】数据库再怎么分库都是走io肯定有瓶颈的
【回复】回复 @bili_51515104671 :好的，mongodb我们以前的项目一般都不放重要的业务数据。
【回复】回复 @tojson :复杂度不会增加很多，除了连接url改一下，业务层面上基本是无感的，试试mongodb 的replicaset模式
我就是大橘:
建议录制的时候放大图片，这样图片看不清楚

【回复】好勒，继续改进，感谢建议[抱拳]
清晨的主人:
可以讲讲跨系统数据库的迁移和增量同步吗？[大哭]

Tokics:
第三种方案，更新DB同时更新Redis，如果更新失败，不就数据不一致了吗？这时定时任务可能还没执行呀？

【回复】是的，正常的情况下更新redis不会失败，这里可以加一个告警。如果更新redis失败，发一个告警，然后开发同学手工在后台再更新一下功能触发一次。
【回复】没有百分百高可用的方案，互联网c端项目都是要有预警和补偿的措施做保障的，还有配套的各种正反情况的预案。只有这样出问题了才能快速恢复，减少系统损失。
悠然谷自在乡:
之前看相关一致性文章说更新数据库后删除redis缓存，后面读策略读不到时再去回写redis缓存，实际业务会删除缓存吗？

【回复】回复 @tojson :好的谢谢前辈
【回复】高并发业务删除的很少，一般都是想办法增加redis命中率，表数据很大，甚至大部分都不会穿透db，如果没命中，会打印告警日志，通知相关开发，进行手动补偿。
rea-lang:
看着基本上sync逻辑跟业务强绑定了，是不是可以尝试直接去掉redis使用程序做本地缓存，还减少了网络消耗，水平扩展时本地数据一致性使用raft，mq等协议去同步

【回复】本地缓存非常宝贵，一般只放不经常变的热数据，对于大数据量的还是要靠redis分布式缓存。高并发类业务通常是结合起来一起用的