核心内容摘要
羞羞歪歪漫画：解锁你的秘密花园，点燃无限可能
大家好我是锋哥。
今天分享关于【高频面试题Java项目高并发下如何保证数据的一致性和可靠性?】面试题。
希望对大家有帮助高频面试题Java项目高并发下如何保证数据的一致性和可靠性?下面按常见场景和解决方案强度来系统性回答从弱→强排序建议你按这个结构组织回答既逻辑清晰又有层次感。
最常见的场景缓存 数据库读多写少/写少读多这是面试官最爱问的场景占比70%以上。
方案更新顺序是否推荐一致性强度并发安全度主要问题/风险适用场景兜底/补偿手段先更新缓存再更新DBCache → DB×强烈不推荐弱很差极端情况下永久不一致几乎不用—先更新DB再更新缓存DB → Cache△偶尔用弱-中中等写成功但更新缓存失败一致性要求不高设置过期时间兜底先删缓存再更新DBdel Cache → DB△部分场景弱-中中等读-写并发导致脏数据一般场景延迟双删 过期先更新DB再删缓存主流方案DB → del Cache√强烈推荐最终一致性较高极小概率脏数据窗口绝大多数业务
缓存设过期时间br
延迟双删br
读到空值回源DB并重建先更新DB再删缓存 延迟双删DB → del → sleep(几百ms~2s) → del√高频使用最终一致性高基本杜绝脏数据高并发读写场景 缓存过期兜底先删缓存 异步更新Canal/ binlog订阅del Cache → MQ → 消费更新Cache√最终一致性很高依赖MQ可靠性超高并发写Canal MQ重试读写分离 先删后写 延迟双删del → DB主 → sleep → del√最终一致性高从库延迟导致短暂不一致读写分离严重场景延迟时间要大于主从延迟面试最推荐的回答路径性价比最高“我们项目中绝大部分场景采用『先更新数据库再删除缓存』这个方案结合延迟双删策略缓存设置合理的过期时间作为兜底。
为什么要先更新DB再删缓存而不是反过来 因为如果先删缓存再更新DB存在一个经典的脏数据时间窗口T1请求A 删除缓存 T2请求B 读缓存miss → 查老数据 → 回写旧值到缓存 T3请求A 更新DB成功 → 此时缓存里是旧数据永久脏数据直到过期而先更新DB再删缓存就算有并发读也只是短暂读到旧值最终会过期不会永久脏数据。
为了进一步压缩不一致窗口我们会在更新DB成功后立即删除缓存等待几百毫秒 ~ 2秒大于主从延迟、读修复时间再删除一次延迟双删极端情况下仍然不一致怎么办我们给所有业务key设置合理的过期时间1小时~7天不等作为最终一致性兜底。
写多/并发写冲突严重的场景库存扣减、余额扣款、秒杀这类场景不能接受任何超卖/负值一致性要求更高。
常用组合方案强度递增数据库乐观锁version / 条件更新→ 最常用、最稳分布式锁Redisson / zookeeper→ 锁粒度要细推荐按用户ID/商品ID/订单号等维度锁悲观锁 行锁for update→ 适用于写少、并发冲突集中的热点商品消息队列削峰 最终一致性→ 下单 → 进MQ → 消费者串行扣库存/余额扣减成功后发MQ做下游典型削峰方案TCC / Seata AT / 可靠消息MQ金融级强一致性一句话
总结常用答案“秒杀/库存扣减我们采用Redis 分布式锁Redisson 数据库乐观锁双重防护的组合方案先在Redis里使用Lua脚本做原子扣减setnx decrby扣减成功后再进数据库使用version字段或条件更新做最终落库如果Redis扣减成功但DB失败则补偿回滚Redis或发MQ异步补偿整个过程设置分布式锁防止并发穿透到DB”
分布式事务场景跨库、跨服务一致性要求推荐方案是否高并发友好备注强一致性Seata-AT / XA一般TPS低强一致性2PC / 3PC差基本不用强一致性TCC中等业务侵入大最终一致性可靠消息RocketMQ事务消息 / Kafka高主流互联网方案最终一致性本地消息表 定时任务高可靠但较重最终一致性最大努力通知高对时效不敏感一句话标准回答“我们项目中跨服务的事务一致性主要采用**『基于MQ的可靠消息最终一致性』**方案本地事务执行成功后发送事务消息RocketMQ事务消息 / Kafka 事务表MQ回调确认本地事务状态下游服务消费消息执行业务失败支持本地重试 死信兜底配合定时对账任务做最终数据对齐这种方案在高并发下性能最好也比较成熟。
”
4.