Landcc的博客

在现代分布式系统中，利用缓存（如 Redis）来加速数据访问是一种常见的优化手段。然而，当面对高并发场景时，确保缓存和数据库之间的一致性变得尤为挑战。特别是在缓存和数据库更新失败的情况下，如何实现最终一致性成为了一个重要的议题。本文将探讨几种有效的策略，并结合简单的图示帮助理解。

检测死锁的核心是识别 “环形等待链”单机依赖线程栈分析（如jstack）和代码埋点；数据库依赖内置死锁日志（如分布式依赖追踪工具和全局日志。实际项目中，更倾向于提前预防死锁（如统一资源获取顺序），检测机制主要用于快速定位偶发的死锁问题。

死锁的四个必要条件是互斥、持有并等待、不可剥夺、循环等待，且四个条件必须同时满足才会产生死锁。统一资源获取顺序（如数据库行锁按 ID 升序锁定）；限时等待资源（超时后释放已持有资源）；引入资源剥夺机制（如分布式锁的超时自动释放）。理解这些条件和案例，能帮助在面试中清晰阐述死锁的成因及解决方案。

缓存雪崩是指在某一时刻，大量缓存数据同时过期或 Redis 服务宕机，导致所有请求直接打到数据库，造成数据库瞬间压力激增，甚至崩溃。缓存击穿是指某个被高频访问的热点 Key在过期的瞬间，大量并发请求同时无法命中缓存，全部涌向数据库，造成瞬时压力激增。⚠️ 与雪崩不同：雪崩是“大面积失效”，击穿是“单个热点失效”。缓存穿透是指查询一个数据库中也不存在的数据，导致缓存无法命中，每次请求都必须查询数据库。恶意攻击者可能利用此漏洞，构造大量不存在的 Key，持续请求，压垮数据库。

缓存预热是指在系统正式对外提供服务之前，提前将一些热点数据加载到缓存中（如 Redis），以便后续请求可以直接从缓存读取数据，减少对数据库的直接访问。

通过将锁从“商品级”细化到“SKU级”，我们可以实现请求的并行处理，大幅提升系统吞吐量。

在分布式项目中，使用 Redsync 实现基于 Redis 的分布式锁不仅简化了开发流程，还提供了更高的可靠性和安全性。特别是其内置的看门狗机制，能够有效地避免锁过期带来的各种问题，确保分布式系统的稳定运行。

Redis 集群环境下的分布式锁选择，本质是一致性与性能的权衡方案适用场景优势劣势单节点锁低并发、非核心业务简单、高性能无容错能力，单节点故障即失效主从锁中低并发、允许短暂不一致兼顾可用性和性能主从切换可能导致锁丢失RedLock高并发、数据强一致场景抗故障能力强，互斥性好性能开销大，部署复杂先用主从架构 + 合理的重试机制解决 80% 的场景对核心业务（如订单支付、库存扣减）引入 RedLock 保障一致性。

防止锁被其他协程误删，本质上是解决 "锁的归属权验证" 问题。唯一标识原则：每个锁必须有唯一的 value，作为持有者的身份凭证原子操作原则：释放锁时的 "验证 + 删除" 必须是原子操作，Lua 脚本是最佳选择最小权限原则：只有锁的持有者才能释放锁，任何情况下都不允许越权操作在实际开发中，建议直接使用经过验证的开源库（如 Redisson、go-redsync），它们已经妥善处理了这些安全细节。

过期时间设置原则必须大于业务正常执行时间的 P99 值不宜过长（建议不超过 30 秒），避免异常情况下的锁阻塞根据业务特性动态调整，而非固定值自动续期实现要点采用 "1/3 过期时间" 作为续期间隔续期操作必须使用 Lua 脚本保证原子性续期协程必须能被正常终止，避免资源泄露风险防控措施给业务逻辑设置超时控制限制最大续期次数对超长持有时间的锁进行监控告警生产环境建议优先使用成熟框架（如 Redisson for Java，go-redsync for Go）

Redis 分布式锁的核心是通过SET NX PX命令实现原子性的 "抢锁"，并通过 Lua 脚本保证释放锁的安全性。SETNX（或SET NX）是实现锁的基础，解决了并发抢锁的原子性问题必须给锁设置过期时间，避免死锁释放锁时需通过唯一标识 + Lua 脚本，防止误删其他客户端的锁实际应用中需考虑超时、可重入性、集群一致性等进阶问题掌握这些原理后，再去阅读 Redisson 等框架的源码，就能更清晰地理解其设计思路。

限流：守护系统 “入口”，防止流量洪峰压垮资源。降级：权衡 “功能取舍”，保障核心业务的连续性。熔断：隔离 “故障传播”，快速失败避免雪崩。三者并非孤立，而是协同工作，构建微服务的高可用防护网。在实际项目中，结合 Sentinel、Hystrix、Spring Cloud 等工具，可快速落地这些策略，让系统在高负载、故障下仍能稳定运行。（拓展思考：如何通过监控系统联动三板斧？比如限流触发后，自动调整降级策略；熔断后，通知运维自动扩容。这需要更深入的体系化建设～）

在微服务架构中，分布式 Trace 不是可选功能，而是必备的高可用保障。快速定位问题，减少 “甩锅大战”；优化性能，提升系统稳定性；加速团队协作，让开发、测试、运维高效协同。无论是小团队的初创项目，还是大厂的复杂系统，都值得尽早落地分布式 Trace。毕竟，谁也不想再经历 “一上午 Debug 找不到问题” 的崩溃时刻～（拓展思考：除了链路追踪，微服务高可用还需要限流、降级、熔断等手段。后续我们再聊聊这些方案如何配合，构建完整的高可用体系～）

幂等性（idempotent）起源于数学，指 “对同一操作重复执行，结果与单次执行一致”。在编程中，幂等方法 / 接口的特点是：使用相同参数重复调用，不会改变系统状态，或改变的状态与单次调用完全相同。price=200（全量更新商品价格，多次调用结果一致 ）。（购物车商品数量 +1，多次调用会持续累加 ）。幂等性与 “分布式 / 高并发” 无关：核心是 “操作本身是否幂等”。即使是单体系统，若存在重试、重复提交，也需设计幂等逻辑。业务优先：幂等性需结合业务场景设计。

服务雪崩效应，是因服务提供者不可用，引发服务调用者不可用，并不断放大不可用范围的恶性现象。比如 A 是服务提供者，B 调用 A，C、D 调用 B，当 A 故障，B 因依赖 A 不可用，C、D 也会受牵连，像多米诺骨牌般让故障范围蔓延。服务雪崩是分布式系统的 “大敌”，需从成因入手，用扩容、流控、熔断等策略构建防护网；gRPC 的超时、重试、幂等性，则是保障服务调用可靠的 “三驾马车”。理解并实践这些内容，才能让分布式服务更稳定、高效，从容应对高并发与故障挑战。

最大努力通知是一种轻量级、柔性的分布式事务方案，核心逻辑是 “通知重试 + 主动校对”。它放弃了强一致性，通过 “尽最大努力 + 兜底查询” 实现最终一致，非常适合交易结果通知类场景。理解它与可靠消息一致性的区别后，面对支付回调、物流通知等需求，就能快速判断是否用最大努力通知简化实现，同时通过 MQ 重试和主动校对保证结果不丢失。（拓展思考：如果接收方长期宕机，如何避免通知重试风暴？可以结合 “通知次数上限 + 熔断机制”，达到上限后暂停重试，转为定时校对～ ）

本地消息表是“最终一致性” 的经典实践对实时性要求不高（如积分、通知、物流状态同步）。业务逻辑简单，不想引入复杂分布式事务框架。高并发场景，但能通过优化（如分库分表、异步落库）缓解数据库压力。它的核心逻辑是“本地事务保证业务 + 消息的一致性，异步重试保证最终一致”。理解这套思路后，面对 “跨服务数据同步” 需求，就能快速判断是否适用本地消息表，或结合其他方案（如 TCC + 本地消息表兜底）。（拓展思考：如果消息表数据量极大，如何设计归档策略？定时任务扫描效率低，有没有更高效的消息投递方式？

TCC 分布式事务通过 Try、Confirm、Cancel 三个阶段的协调，实现了跨服务业务操作的原子性。先通过 Try 操作检查业务可行性并锁定资源如果所有 Try 操作都成功，通过 Confirm 操作完成最终业务如果任何 Try 操作失败，通过 Cancel 操作回滚所有预备操作TCC 特别适合那些对数据一致性要求高，且需要跨多个服务协同完成的业务场景。虽然它增加了开发成本和复杂度，但相比其他分布式事务解决方案，它在性能和灵活性方面具有明显优势。

2PC 是分布式事务的经典尝试，它用 “两阶段” 拆解复杂的一致性问题，思路值得学习。但缺点也很明显，尤其是性能和故障恢复的问题，让它在实际场景中常被 “嫌弃”。不过，理解 2PC 后，再去学 TCC、Saga 等其他分布式事务方案，会更清晰 —— 它们本质是在 2PC 基础上，优化性能、容错性，做各种 “妥协” 和 “补充”。学分布式事务，2PC 是绕不开的 “第一课”。

CAP 像一盏灯，告诉我们分布式系统设计 “不可能三角” 的限制，让我们明白 C、A、P 无法同时满足；BASE 则是踩在 CAP 肩膀上，给出的落地解法 —— 放弃强一致，用基本可用、软状态换高可用，最终让数据达成一致。实际开发中，得根据业务场景选策略：金融交易优先 CP（强一致），哪怕偶尔不可用；电商抢购、社交 feed 流优先 AP（高可用），接受短暂数据不一致；然后通过 BASE 思路，让系统在可用性和一致性间找到平衡，最终满足业务需求。