java-reader分布式专题分布式事务、Raft协议与高可用裂脑问题从入门到原理【免费下载链接】java-readerJava工程师学习历程与笔记附含算法、Java基础、框架实战、框架源码、框架实现、中间件、面试题等知识和学习蓝图。项目地址: https://gitcode.com/gh_mirrors/ja/java-readerjava-reader 是一个 Java 工程师学习历程笔记仓库其「分布式专题」与「架构设计」板块系统记录了分布式事务XA、JTA、TCC、LCN、消息驱动、Raft 协议与高可用裂脑问题的完整学习路径。本文将从零讲清楚为什么一个Transactional在跨库场景下会失效、四大主流分布式事务方案如何取舍、集群为何需要 Raft 选主、以及让高可用集群自相残杀的裂脑问题从何而来、如何根治。一、为什么本地事务在分布式场景下失效在单库中Spring 的一个Transactional注解就能保证多表操作要么全成功、要么全回滚。但分库分表之后故事就不一样了场景抢票功能中库 B 扣减票数、库 A 写入抢票记录。如果 B 扣票成功后抛异常A 没有保存记录——票扣了记录没了本地事务无法跨库回滚。这就是分布式事务要解决的核心问题跨数据源的一致性。 值得注意的一个常见误区单数据源事务的关键是所有 SQL 必须跑在同一个数据库连接上。Spring 通过TransactionSynchronizationManager把Connection绑定到当前线程ThreadLocal从而在切面内保证同一连接执行。理解这一点你就理解了为什么跨数据源天然是普通事务的禁区。哪些场景不该用普通事务场景事务边界说明单库多表本地事务Transactional即可数据库 MQ分布式事务两个数据源各自提交异常时已提交的部分无法回滚多微服务调用分布式事务一次请求横跨多个服务/库必须借助分布式事务方案二、先懂两条宪法CAP 与 BASE分布式事务的设计不可能同时满足所有要求两条理论帮你快速判断方案取舍CAP 定理一致性(C)、可用性(A)、分区容错性(P)三者不可兼得。网络分区在分布式系统中必然发生所以实际取舍是CP 还是 AP。BASE 理论对 CAP 的妥协核心是最终一致性——Basically Available基本可用允许故障时损失部分功能Soft State软状态允许数据同步有延迟Eventually Consistent最终一致不强求实时一致最终一致即可。一句话总结强一致牺牲性能最终一致换高并发方案选择本质是在这两条理论之间做权衡。三、四大分布式事务方案全解析 java-reader 的分布式事务笔记按原理—协议—框架—场景的顺序展开主流方案可以归纳为四派3.1 XA / JTA强一致的老牌选手XA 协议由 X/Open 组织提出基础是两阶段提交2PC先 prepare各参与者准备并提交到待决状态再 commit协调者统一通知提交。JTA是 XA 协议的 Java 规范实现UserTransaction提供begin / commit / rollback等接口工程上常配合Atomikos事务管理器嵌入 SpringBoot实现跨数据源强一致回滚。三大经典缺陷缺陷说明性能差事务期间各节点一直占用数据库资源直到全部准备完毕才统一提交协调者单点故障协调者宕机参与者卡在中间状态无法完成事务消息丢失不一致二阶段时局部网络故障部分节点收到 commit、部分没收到XA 三阶段提交3PC增加了 CanCommit 阶段和超时机制缓解了协调者单点问题但性能与不一致问题并未根治。3.2 TCC把一致性下沉到业务层TCCTry-Confirm-Cancel是 2PC 思想在应用层的落地每个业务接口都要实现 try预留资源、confirm确认执行、cancel取消预留三个操作且必须保证幂等。✅ 优点应用自己定义数据操作粒度锁冲突少、吞吐高❌ 缺点对业务侵入性极强每个分支都要写三个操作实现成本高。3.3 LCN基于本地事务协调的轻量方案LCN 本身不创建新事务而是协调各节点已有的本地事务切面生成事务组 ID 绑定各分支事务统一收集 commit/rollback 结果后协调执行。✅ 优点性能好、对代码侵入低❌ 缺点需额外部署 tx-manager 服务服务超时时会长时间锁住相关资源如支付超时导致库存一直被锁。3.4 消息驱动事务互联网高并发的最终答案基本思路本地操作与发送消息放在同一个本地事务中同成败下游订阅消息后执行操作失败则重试补偿。本质是把一个大分布式事务拆成两个本地事务 重试达到最终一致性。⚠️ 需要注意消息可能重复、顺序无法保证业务侧必须做好幂等与补偿机制。选型速查表方案一致性性能适用场景XA/JTA强一致低金融支付、强一致要求的业务TCC最终一致高高并发且愿意做业务改造LCN强一致中高微服务间数据库协调消息驱动最终一致最高交易成功发通知、推送等弱时效场景四、Raft 协议分布式集群如何选主 ️如果说分布式事务解决的是数据一致性那Raft 协议解决的是集群状态一致性——它是 Zookeeper、etcd、TiKV 等分布式系统高可用的核心。Raft 把一个复杂的共识问题拆成三个独立子问题这也是它比 Paxos 更易理解、易实现的原因领导者选举Leader Election集群中节点分为 Leader 与 Follower。Follower 长时间收不到 Leader 心跳后发起选举通过随机超时避免选票对半多数派quorum同意后成为新 Leader。这也是为什么 Raft 集群通常部署 3 或 5 个奇数节点——奇数节点下挂一半节点仍能选出多数派。日志复制Log Replication所有客户端请求都由 Leader 处理Leader 把日志条目发给所有 Follower获得多数派确认后才提交并响应客户端保证日志在节点间强一致。安全性Safety通过任期号Term和候选者日志必须至少和其他节点一样新等约束保证一旦日志被提交就永远不会丢失已选出的 Leader 不会分叉。 理解 Raft 的关键一句话少数服从多数日志即真相。它天然容忍少数节点宕机这正是分布式中间件如 Zookeeper能扛住单点故障的根基。java-reader 的架构设计板块收录了由浅入深的 Raft 协议解读资料适合作为延伸精读。五、高可用的黑天鹅裂脑问题 什么是裂脑Split-Brain高可用集群的两个节点互相认为对方已经挂掉于是主备同时上线争抢 VIP、共享存储等同一资源——结果就是系统混乱、数据损坏。裂脑是怎么产生的心跳链路故障心跳线断了/老化、网卡或驱动坏了、IP 冲突、交换机故障、仲裁节点出问题防火墙误拦截iptables 挡住了心跳包配置错误心跳网卡地址配置不对、主备心跳方式不一致、心跳广播冲突软件 BUG。三大根治/缓解手段手段原理双心跳线路串行电缆 以太网双线并行一条坏了另一条仍工作Fencingfence/stonith检测到裂脑时通过独立线路强制关掉一个节点宁可牺牲一半可用性也不让两个大脑同时存活监控报警 人工仲裁短信/邮件第一时间通知管理员甚至支持回复指令自动处理故障把损失降到最低工程上还可以写一个简单的裂脑检测脚本如果能 ping 通对端主机、且本地又持有 VIP 地址基本就可以断定裂脑已发生java-reader 的架构设计笔记中附有可运行的检测脚本示例路径见下文。六、仓库资料定位从入门到原理的阅读路径 按先本地事务 → 再分布式事务 → 后架构原理的顺序精读收益最大主题笔记路径事务四大特性、隔离级别、传播机制入门4. 分布式专题/4.1 分布式事务/1. Spring事务管理-快速入门.mdCAP/BASE 理论 JTA/Atomikos 多数据源实战4. 分布式专题/4.1 分布式事务/2. Spring事务管理-分布式事务管理之JTA与链式事务.mdXA/TCC/LCN/消息驱动四大方案全景对比4. 分布式专题/4.1 分布式事务/分布式事务原理简介Raft 协议由浅入深解读9. 架构设计/由浅入深理解Raft协议.md裂脑成因、解决方案与检测脚本9. 架构设计/高可用之裂脑问题.md配合仓库的 SpringCloud 实战3. 框架专题/3.1 实战篇/SpringCloud/与 Zookeeper 中间件笔记可以完整走通分布式事务 共识协议 高可用这条主线。七、总结一张图看懂学习路线入门吃透本地事务同连接、ThreadLocal 绑定、ACID 与隔离级别——这是一切分布式事务的对照系进阶用 CAP/BASE 建立取舍思维横向对比 XA、TCC、LCN、消息驱动四种方案的适用场景架构理解 Raft 的多数派与日志复制明白分布式系统高可用的数学根基实战针对高可用部署掌握裂脑的成因识别、fencing 强制隔离与监控报警三板斧。分布式技术没有银弹只有取舍。希望这篇从入门到原理的导读能帮你在 java-reader 的笔记体系中快速搭起自己的分布式知识骨架 。【免费下载链接】java-readerJava工程师学习历程与笔记附含算法、Java基础、框架实战、框架源码、框架实现、中间件、面试题等知识和学习蓝图。项目地址: https://gitcode.com/gh_mirrors/ja/java-reader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 java-reader分布式专题：分布式事务、Raft协议与高可用裂脑问题，从入门到原理
java-reader分布式专题分布式事务、Raft协议与高可用裂脑问题从入门到原理【免费下载链接】java-readerJava工程师学习历程与笔记附含算法、Java基础、框架实战、框架源码、框架实现、中间件、面试题等知识和学习蓝图。项目地址: https://gitcode.com/gh_mirrors/ja/java-readerjava-reader 是一个 Java 工程师学习历程笔记仓库其「分布式专题」与「架构设计」板块系统记录了分布式事务XA、JTA、TCC、LCN、消息驱动、Raft 协议与高可用裂脑问题的完整学习路径。本文将从零讲清楚为什么一个Transactional在跨库场景下会失效、四大主流分布式事务方案如何取舍、集群为何需要 Raft 选主、以及让高可用集群自相残杀的裂脑问题从何而来、如何根治。一、为什么本地事务在分布式场景下失效在单库中Spring 的一个Transactional注解就能保证多表操作要么全成功、要么全回滚。但分库分表之后故事就不一样了场景抢票功能中库 B 扣减票数、库 A 写入抢票记录。如果 B 扣票成功后抛异常A 没有保存记录——票扣了记录没了本地事务无法跨库回滚。这就是分布式事务要解决的核心问题跨数据源的一致性。 值得注意的一个常见误区单数据源事务的关键是所有 SQL 必须跑在同一个数据库连接上。Spring 通过TransactionSynchronizationManager把Connection绑定到当前线程ThreadLocal从而在切面内保证同一连接执行。理解这一点你就理解了为什么跨数据源天然是普通事务的禁区。哪些场景不该用普通事务场景事务边界说明单库多表本地事务Transactional即可数据库 MQ分布式事务两个数据源各自提交异常时已提交的部分无法回滚多微服务调用分布式事务一次请求横跨多个服务/库必须借助分布式事务方案二、先懂两条宪法CAP 与 BASE分布式事务的设计不可能同时满足所有要求两条理论帮你快速判断方案取舍CAP 定理一致性(C)、可用性(A)、分区容错性(P)三者不可兼得。网络分区在分布式系统中必然发生所以实际取舍是CP 还是 AP。BASE 理论对 CAP 的妥协核心是最终一致性——Basically Available基本可用允许故障时损失部分功能Soft State软状态允许数据同步有延迟Eventually Consistent最终一致不强求实时一致最终一致即可。一句话总结强一致牺牲性能最终一致换高并发方案选择本质是在这两条理论之间做权衡。三、四大分布式事务方案全解析 java-reader 的分布式事务笔记按原理—协议—框架—场景的顺序展开主流方案可以归纳为四派3.1 XA / JTA强一致的老牌选手XA 协议由 X/Open 组织提出基础是两阶段提交2PC先 prepare各参与者准备并提交到待决状态再 commit协调者统一通知提交。JTA是 XA 协议的 Java 规范实现UserTransaction提供begin / commit / rollback等接口工程上常配合Atomikos事务管理器嵌入 SpringBoot实现跨数据源强一致回滚。三大经典缺陷缺陷说明性能差事务期间各节点一直占用数据库资源直到全部准备完毕才统一提交协调者单点故障协调者宕机参与者卡在中间状态无法完成事务消息丢失不一致二阶段时局部网络故障部分节点收到 commit、部分没收到XA 三阶段提交3PC增加了 CanCommit 阶段和超时机制缓解了协调者单点问题但性能与不一致问题并未根治。3.2 TCC把一致性下沉到业务层TCCTry-Confirm-Cancel是 2PC 思想在应用层的落地每个业务接口都要实现 try预留资源、confirm确认执行、cancel取消预留三个操作且必须保证幂等。✅ 优点应用自己定义数据操作粒度锁冲突少、吞吐高❌ 缺点对业务侵入性极强每个分支都要写三个操作实现成本高。3.3 LCN基于本地事务协调的轻量方案LCN 本身不创建新事务而是协调各节点已有的本地事务切面生成事务组 ID 绑定各分支事务统一收集 commit/rollback 结果后协调执行。✅ 优点性能好、对代码侵入低❌ 缺点需额外部署 tx-manager 服务服务超时时会长时间锁住相关资源如支付超时导致库存一直被锁。3.4 消息驱动事务互联网高并发的最终答案基本思路本地操作与发送消息放在同一个本地事务中同成败下游订阅消息后执行操作失败则重试补偿。本质是把一个大分布式事务拆成两个本地事务 重试达到最终一致性。⚠️ 需要注意消息可能重复、顺序无法保证业务侧必须做好幂等与补偿机制。选型速查表方案一致性性能适用场景XA/JTA强一致低金融支付、强一致要求的业务TCC最终一致高高并发且愿意做业务改造LCN强一致中高微服务间数据库协调消息驱动最终一致最高交易成功发通知、推送等弱时效场景四、Raft 协议分布式集群如何选主 ️如果说分布式事务解决的是数据一致性那Raft 协议解决的是集群状态一致性——它是 Zookeeper、etcd、TiKV 等分布式系统高可用的核心。Raft 把一个复杂的共识问题拆成三个独立子问题这也是它比 Paxos 更易理解、易实现的原因领导者选举Leader Election集群中节点分为 Leader 与 Follower。Follower 长时间收不到 Leader 心跳后发起选举通过随机超时避免选票对半多数派quorum同意后成为新 Leader。这也是为什么 Raft 集群通常部署 3 或 5 个奇数节点——奇数节点下挂一半节点仍能选出多数派。日志复制Log Replication所有客户端请求都由 Leader 处理Leader 把日志条目发给所有 Follower获得多数派确认后才提交并响应客户端保证日志在节点间强一致。安全性Safety通过任期号Term和候选者日志必须至少和其他节点一样新等约束保证一旦日志被提交就永远不会丢失已选出的 Leader 不会分叉。 理解 Raft 的关键一句话少数服从多数日志即真相。它天然容忍少数节点宕机这正是分布式中间件如 Zookeeper能扛住单点故障的根基。java-reader 的架构设计板块收录了由浅入深的 Raft 协议解读资料适合作为延伸精读。五、高可用的黑天鹅裂脑问题 什么是裂脑Split-Brain高可用集群的两个节点互相认为对方已经挂掉于是主备同时上线争抢 VIP、共享存储等同一资源——结果就是系统混乱、数据损坏。裂脑是怎么产生的心跳链路故障心跳线断了/老化、网卡或驱动坏了、IP 冲突、交换机故障、仲裁节点出问题防火墙误拦截iptables 挡住了心跳包配置错误心跳网卡地址配置不对、主备心跳方式不一致、心跳广播冲突软件 BUG。三大根治/缓解手段手段原理双心跳线路串行电缆 以太网双线并行一条坏了另一条仍工作Fencingfence/stonith检测到裂脑时通过独立线路强制关掉一个节点宁可牺牲一半可用性也不让两个大脑同时存活监控报警 人工仲裁短信/邮件第一时间通知管理员甚至支持回复指令自动处理故障把损失降到最低工程上还可以写一个简单的裂脑检测脚本如果能 ping 通对端主机、且本地又持有 VIP 地址基本就可以断定裂脑已发生java-reader 的架构设计笔记中附有可运行的检测脚本示例路径见下文。六、仓库资料定位从入门到原理的阅读路径 按先本地事务 → 再分布式事务 → 后架构原理的顺序精读收益最大主题笔记路径事务四大特性、隔离级别、传播机制入门4. 分布式专题/4.1 分布式事务/1. Spring事务管理-快速入门.mdCAP/BASE 理论 JTA/Atomikos 多数据源实战4. 分布式专题/4.1 分布式事务/2. Spring事务管理-分布式事务管理之JTA与链式事务.mdXA/TCC/LCN/消息驱动四大方案全景对比4. 分布式专题/4.1 分布式事务/分布式事务原理简介Raft 协议由浅入深解读9. 架构设计/由浅入深理解Raft协议.md裂脑成因、解决方案与检测脚本9. 架构设计/高可用之裂脑问题.md配合仓库的 SpringCloud 实战3. 框架专题/3.1 实战篇/SpringCloud/与 Zookeeper 中间件笔记可以完整走通分布式事务 共识协议 高可用这条主线。七、总结一张图看懂学习路线入门吃透本地事务同连接、ThreadLocal 绑定、ACID 与隔离级别——这是一切分布式事务的对照系进阶用 CAP/BASE 建立取舍思维横向对比 XA、TCC、LCN、消息驱动四种方案的适用场景架构理解 Raft 的多数派与日志复制明白分布式系统高可用的数学根基实战针对高可用部署掌握裂脑的成因识别、fencing 强制隔离与监控报警三板斧。分布式技术没有银弹只有取舍。希望这篇从入门到原理的导读能帮你在 java-reader 的笔记体系中快速搭起自己的分布式知识骨架 。【免费下载链接】java-readerJava工程师学习历程与笔记附含算法、Java基础、框架实战、框架源码、框架实现、中间件、面试题等知识和学习蓝图。项目地址: https://gitcode.com/gh_mirrors/ja/java-reader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考