1. 一次线上故障逼出来的梳理聊分布式系统不落到具体业务和故障现场总是差点意思。先说个我早年踩过的坑一个电商项目订单库和库存库拆开部署下单时先扣库存再创建订单。某个大促预热阶段流量涨了三倍结果库存扣成功了订单插入却因为数据库连接池被打满而超时用户那边显示下单失败实际上库存却已经扣掉。最终运营手工对账发现十几笔超卖订单损失不大但整个团队被复盘会议折腾了一周。那次事故之后我对分布式系统的态度就变了。以前觉得能跑就行什么一致性、容错都是教科书里拿来考试的名词。真正经历过线上事故才明白分库分表、分布式事务、熔断补偿这些技术就是为了应对“并发”、“故障”和“一致性”三座大山堆出来的解决方案。这篇文章就把这些核心东西串起来每个模块都结合我实际跑过的场景聊适合正在搭分布式系统、或者准备把单体应用拆分的工程师看完之后至少能在方案选型上少走弯路。2. 分库分表光拆还不够得拆得聪明2.1 为什么要分库分表而不是靠加硬件硬扛很多人有个误区数据库性能不行无非就是加CPU、加内存、加SSD。确实单机MySQL用好硬件扛到每秒一两万的写入量问题不大。但业务一旦复杂单表数据量过亿索引深度变深B树的层数上去了就算命中索引随机IO和缓存命中率的下降也会让查询变慢。更麻烦的是一个库的所有表共用一个连接池和磁盘IO订单、库存、用户几个热点表挤在一块一个慢SQL就可能拖垮整个库。分库分表的核心目的不是“炫技”而是把数据访问的热点拆开让系统具备平行扩展的能力。分库解决的是“一个库的负载太重”的问题分表解决的是“一张表太大导致索引和扫描低效”的问题。两者经常同时使用。之前接手的一个订单系统日订单量峰值在百万级单表月增长三千万行。这种体量下单库单表连凌晨的离线统计都会把业务查询拖慢。当时我们做的第一步就是先把订单表按照用户ID做水平拆分拆成16张表放在4个库里每库4张表。这样写入的压力被分摊到4个实例单表数据量被控制在两三千万行左右索引效率就恢复到了正常水平。2.2 拆分的核心选对分片键分片键选错后续所有方案都会出问题。我见过有人按订单创建时间按月分表结果日常查询都是查最近一个月的数据一个月前的订单表成了冷数据每次跨月查询都要设计走多个分片。核心原则很简单让绝大多数查询在路由阶段就能确定目标分片。拿订单表举例子如果业务方最常用的查询维度是“我的订单”那分片键就应该选user_id如果运营后台经常按order_id精确查订单那就应该选order_id。两个都要兼顾怎么办可以设计成以order_id为主分片键同时冗余一个user_id的映射关系。我之前在项目里用的是“用户ID派生”策略订单表分片号 user_id % 16库序号固定4。下单时程序根据登录用户的user_id直接算出分片号写入对应分片。查询用户订单时也走同样的路由逻辑一次定位。运营后台要按订单号查呢就把order_id和user_id的映射关系单独扔一张全局表里先用order_id查出user_id再路由到对应分片。2.3 扩容最容易被忽视的噩梦分库分表最让人头秃的不是初始拆分而是后续扩容。早年用取模分片比如分了4个库流量涨到需要扩成8个库时user_id % 4的规则全变了所有数据都得重新分布这个迁移过程既要停机又要保证数据一致非常痛苦。后来我学聪明了用一致性哈希的分片思路或者时间片取模结合的两级路由策略第一级先按月份分片数据天然按时间归档冷热数据自动分离。第二级同一个月内再按user_id % 16分表。这样新的一个月开始时扩容只需要调整“当月分片的数量”历史数据不用动。虽然跨月查询要并行扫多个分片但配合一个统一的查询路由中间件当时用的是ShardingSphere实际研发成本要比做一次全量数据迁移低一个数量级。关键经验技术选型永远要向“未来可能扩容”倾斜宁可现在多写一层路由逻辑也不要把数据分布写死在一条硬编码取模里。3. 分布式事务一致性不是零和博弈3.1 绕不开的“订单和库存”场景只要完成分库分表原来单体应用里用本地事务就能保证的一致性立刻被打破。拿最经典的“下单扣库存”流程来说用户提交订单订单数据写入订单库分片A。库存数据在库存库分片B。扣减库存必须和订单创建保持原子性要么都成功要么都失败。在单体架构里这两步在同一个数据库事务里一条BEGIN TRANSACTION和COMMIT就解决了。但在分布式架构下订单库和库存库是两个独立的数据源本地事务根本管不到对方。分布式事务要做的事情本质上就是在多个数据源之间模拟出类似本地事务的原子性。但这里有个天然的约束网络总是不可靠的两个服务之间的调用可能成功也可能失败还可能“超时但实际成功了”。这种不确定状态注定了分布式事务无法像本地事务那样百分百实时强一致只能在“最终一致性”和“强一致性”之间做trade-off。3.2 五大方案横向对比别再用错场景我把调研和实践过的分布式事务方案整理成一张对比表直接照着选型就行方案一致性级别性能影响代码侵入性适用场景我在项目中的评价2PC两阶段提交强一致高需要锁定资源高接口需实现prepare/commit/rollback并发量低、对一致性要求极高不建议在互联网高并发场景用性能瓶颈太明显3PC三阶段提交强一致比2PC稍好更高理论研究多于实际落地工程上几乎不选TCCTry-Confirm-Cancel最终一致/准强一致中等需要额外写3套逻辑高业务逻辑侵入大需要实时回滚资金类业务很灵活但是开发量真大团队要扛得住本地消息表 定时任务最终一致性低中等对实时性要求不苛刻最接地气小团队首选事务消息RocketMQ最终一致性低中等异步解耦场景我比较推荐的应用方案2PC拿来做技术理解很好它像两个人的“握手协议”协调者先问每个参与者“能不能提交”大家都说能再发正式提交命令。如果第二步有节点挂了整个事务卡死资源一直被锁着高并发下是致命的。3PC加了一个PreCommit阶段减少阻塞窗口但也没根除问题。TCC是真刀真枪的业务方案。把每个操作拆成Try预占资源、Confirm确认执行业务、Cancel回滚释放资源三阶段。以订单和库存举例Try创建“待支付状态”的订单记录锁定库存比如把冻结库存字段1可用库存-1。Confirm用户实际支付成功把订单状态改为“已支付”把冻结库存转为实际出库。Cancel支付超时或用户取消订单状态改为“已取消”回滚库存冻结库存-1可用库存1。TCC的好处是每个分支事务的粒度由业务自己控制性能比2PC高很多坏处是每个参与方都要写三套方法代码复杂度呈指数级上升。团队规模小、业务不复杂的用TCC很有可能会把迭代速度拖垮。3.3 我最推荐的落地组合本地消息表 事务消息大部分互联网业务的“订单和库存分布式事务”其实只需要最终一致性。用户看到“下单成功”库存扣减稍后生效完全没问题真正需要强一致的是“扣了钱必须生成订单”这种账务关系。我后来做的项目里采用的是本地消息表 RocketMQ事务消息的混合模式核心链路订单创建 消息入库同一个本地事务在订单库里建一张local_message消息表。下单接口里开启数据库本地事务先插订单再插一条“扣减库存”的消息记录然后一起提交。这一步保证了只要订单库的事务提交了消息就一定存在事务没提交消息也不会出现。异步发送后台有个消息发送线程扫描local_message表中状态为“待发送”的记录调用RocketMQ的sendMessageInTransaction业务代码里确认发送成功后把消息表状态改成“已发送”。消费端保证幂等库存服务消费这条消息执行扣减。扣减成功后调用订单服务反写一个“扣减完成”的标记如果消费者挂了RocketMQ会重试重试到一定次数进死信队列。这套方案没有2PC的资源锁定问题也没有TCC四处写钩子的复杂度。代价是从下单到库存扣减生效之间有秒级的延迟且业务上要接受这个短暂不一致的窗口。我的看法是99%的业务场景都能忍不能忍的才要上TCC。3.4 幂等设计比分布式事务更重要的底层能力很多同学纠结分布式事务框架选型却忘了基础工作——幂等。分布式事务的方案千千万全链路幂等没做好上什么框架都白搭。什么是幂等同一个操作执行一次和执行多次产生的结果是一样的。扣库存这个动作如果由于网络重试被消费端执行了两次库存就多扣了。解决办法里比较通用的是“唯一键防重”具体做法是在库存扣减表里设置order_id为唯一索引。消费端收到消息先试插一条deduplication表记录相当于占坑插入成功才继续执行真正的扣减逻辑插入失败说明这条订单已经处理过直接丢弃消息。实际做过处理单子多的都知道表结构多一个唯一索引比在代码里写一堆“if 已处理 then return”要可靠得多。4. 熔断、限流、补偿系统保命的三件套4.1 熔断别让雪崩从你这里开始分布式系统里最典型的故障模式就是雪崩一个服务响应变慢调用它的人等不到响应线程池占满又拖垮下游逐级传导最终整个系统挂掉。熔断机制就是干这个的当某个依赖的失败率达到阈值启动“保险丝”后续请求快速失败不再真正打到下游。等下游恢复了再尝试放流量过去。当时我们的订单服务依赖一个第三方风控接口对方故障时rt从50ms暴涨到10秒。没做熔断前订单服务的Tomcat线程池很快被阻塞占满正常的本地逻辑也全部超时。后来引入了Sentinel阿里的开源组件做熔断配置基本是这样子的熔断策略慢调用比例 阈值50% 最小请求数10 统计时长5秒 熔断时长10秒 熔断恢复策略半开状态允许探测请求当5秒内请求数超过10个且慢调用超过1秒比例超过50%就开启10秒熔断之后的请求直接快速返回“系统繁忙”。10秒后进入半开状态先放5个请求过去探一下下游如果成功了就关闭熔断失败则继续熔断。这个参数怎么调经验是熔断阈值要看下游的可用性目标而不是上线的理想值。比如第三方接口的SLA承诺是99.5%可用那失败率阈值设在10%左右比较合理太低了容易误触发太高了熔断动作就没意义了。4.2 限流防患于未然比熔断更主动熔断是系统已经出问题后的“被动止血”限流才是主动拒绝额外流量保证核心链路稳定。常见限流算法有四种算法原理优缺点适用场景固定窗口计数器每秒/每分钟计数超阈值拒绝实现简单但临界点流量可能双倍突发一般管理系统滑动窗口计数器时间窗口内细分多个小格流量平滑统计相对公平内存开销略大API网关通用漏桶请求进桶匀速漏出桶满溢出严格执行平滑速率不能应对突发流量对突发敏感的保护场景令牌桶按固定速率生成令牌请求拿令牌通过允许一定突发量兼顾平滑和弹性大多数业务API接口使用Sentinel的网关限流时我比较常用的是令牌桶参数设置参考经验别的服务调用我们下单接口压测得到的极限QPS大概在5000那线上限流阈值就设在4000留20%余量。限流不是设置一个永远到不了的数字而是在系统真正濒临崩溃前主动把流量曲线削平。4.3 补偿最终一致落地离不开的“兜底网络”一致性和稳定性方案都做了还是可能出现数据不一致。比如事务消息发出去后库存服务一直在重试但业务代码有bug消息进了死信队列那笔订单就永远扣不了库存了。这个时候补偿机制就是最后的兜底网络。我们当时设计了一套对账补偿流程属于常规的架构治理手段定时对账任务每分钟扫描订单库里状态为“已创建但库存扣减未确认”的订单调用库存服务查询看当前实际库存和预期扣减值差异是否一致。死信队列告警 人工介入消息重试15次仍然失败进入死信队列发送告警到值班群管理员在控制台一键重发。业务补偿接口给每个核心业务设计人工触发的补偿操作比如“手动发起库存扣减重试”。这不是偷懒是任何自动化方案都有bug的必然前提留一个人工操作通道是工程成熟的标志。关于补偿有个血泪教训补偿逻辑一定是独立的、幂等的不要和主流程耦合在同一个类里。不然补偿时复用了主流程有bug的代码那补偿就变成重复犯错了。5. 实战解析一个订单与库存分布事务的完整技术链路5.1 业务流程拆分与数据流设计把前面所有要素串起来有一个项目里的典型上下游是这么设计的我拆开给你看。上下文用户下单需要生成订单数据并扣减库存。拆解后的服务拓扑用户端 - API网关限流 接口鉴权API网关 - 订单服务接收下单请求订单服务内部写入订单分片库写local_message消息表这两个操作走一个本地事务后台线程从local_message查待发送消息发到RocketMQ的order-stock-topic库存服务消费order-stock-topic消息执行库存扣减stock表按sku_id分片更新deduplication表库存服务扣减成功后通过业务接口回调订单服务标记“库存扣减完成”定时任务扫描未完成标记的订单触发对账补偿流程以下是简化后的核心接口伪代码用了类似Java的分步说明。真实工程还要加上参数校验、分布式锁和全链路日志这里重点看结构// 订单服务下单 public boolean createOrderAndSendStockMessage(OrderDTO order) { // 本地事务订单数据 本地消息表同库同事务 return transactionTemplate.execute(status - { // 1. 初始化订单为“待扣库存”状态 orderMapper.insert(order); // 2. 插入本地消息表状态为“待发送” LocalMessage msg new LocalMessage(); msg.setTopic(order-stock-topic); msg.setPayload(buildStockDeductMessage(order)); msg.setStatus(MessageStatus.PENDING); localMessageMapper.insert(msg); // 3. 事务提交后后台线程扫描PENDING状态并发送 return true; }); }// 库存服务消费扣减消息 RocketMQMessageListener(topic order-stock-topic, consumerGroup stock-service) public void onStockDeductMessage(StockDeductMsg msg) { // 幂等控制插入去重表成功才继续处理 boolean first dedupMapper.insertIfAbsent(msg.getOrderId()); if (!first) { // 已处理过直接返回 return; } try { // 实际扣减库存 stockMapper.deduct(msg.getSkuId(), msg.getQuantity()); // 回调订单服务标记完成 orderClient.markStockDeducted(msg.getOrderId()); } catch (Exception e) { // 抛出异常让MQ重试重试15次进死信 throw new IllegalStateException(扣减库存失败, e); } }5.2 核心扣减逻辑与防超卖设计库存扣减这条线最需要小心。常规的UPDATE stock SET available available - #{num} WHERE sku_id #{skuId}在高并发下暴露出的典型问题就是覆盖更新丢数据。我们当时的库存扣减SQL至少是两段式的-- 试扣预占乐观锁思路 UPDATE stock SET frozen frozen #{num}, available available - #{num} WHERE sku_id #{skuId} AND available #{num};available #{num}这个条件就是防超卖的最后一道防线的核心——在SQL层面保证扣减不会越过库存边界。如果更新影响行数返回0说明库存不足消息重试也没用应当直接终止。5.3 这套链路是怎么扛住故障的这条链路设计完成之后我模拟过几个典型故障场景结果是这样的故障场景表现影响机制保障订单库宕机下单接口失败用户看到错误本地事务无法提交消息未入库用户可重试MQ集群故障消息暂时发送不出去后台发送线程持续重试订单状态保持“待扣库存”不会错乱库存服务宕机扣减延迟但请求不会雪崩MQ消息积压服务恢复后继续消费最终一致库存不足订单已生成但扣减失败死信队列告警人工介入处理或自动取消订单大流量冲击接口整体过载风险API网关限流 Sentinel熔断保护核心线程池这套设计里没有高性能的分布式事务框架但胜在每个环节都能自解释出问题谁都能看得懂。分布式系统方案不是越高级越好而是越可控越好。6. 常见问题与排查技巧实录我在设计、维护这套核心链路的过程里积累了下面这些问题和对应排查方法整理出来分享。6.1 消息重复消费导致多扣了库存现象同一笔订单的库存扣减执行了两次可用库存对不上。排查后发现RocketMQ的默认投递语义是At Least Once最少一次消费端红了会重试网络抖动可能导致多个投递线程同时进来。解决方法是幂等去重表必须先行先插deduplication成功再执行业务这招不是可选项是必需品。6.2 本地消息表事务提交了消息却一直发不出去多数是后台发送线程问题最常踩的是这两个消息表里的状态枚举搞混了比如初始状态设为0代码里却只扫状态为1的这种属于低级错误建议枚举字段加注释。后台发送线程挂了。解决方式是发送线程加定时重启机制并配置监控待发送消息数超过200就告警。6.3 熔断被误触发正常接口被快速失败排查下来是统计时长设置太短触发了慢调用比例虚高。比如统计时长5秒刚好这个时间段内一个接口跑了5次因为一次GC停顿导致3次超1秒慢调用比例就60%了直接熔断。后来我把最小请求数提升到20统计时长也改成10秒整体稳定了很多。最小请求数不要设置太小不然容易受偶发慢请求干扰。6.4 分库分表后的全局唯一ID千万别用自增分库后多库自增必然冲突。我们在项目里用的方案是雪花算法Snowflake主要组成部分包含时间戳、机器ID、序列号生成的ID是趋势递增且全局唯一。用的时候注意两点一是不同服务要配置不同的机器ID二是时间回拨会导致ID重复要加偏差校验。我的落地方案里机器ID存配置中心每台实例启动时从配置下发避免人为手改出错。6.5 事务消息和本地消息表能不能换成Kafka我在项目里试过用Kafka事务消息。结论是能用但Kafka的事务API使用门槛比RocketMQ高且RocketMQ对“事务消息”有专门的半消息机制在开销上更直观且更贴近业务。如果你的团队对Kafka已经很熟且在事务场景里已经有了稳定封装继续用没问题但仅因为“公司只有Kafka”就把事务消息硬套进去后期排查落地的复杂度会很难受。7. 核心要点记录与个人体会整个分布式系统技术体系聊到这里把最关键的内容放在最后这节方便大家回顾并记录自己的落地方案核心要点。分库分表的核心是分片键的选择和可扩展性。分布式事务没有银弹先想清楚你的业务能不能容忍“秒级最终一致窗口”配合幂等设计和消息机制大多数场景已经够用了。熔断限流是稳定性的底线一定要提前做压测把阈值定到有依据的数字而不是拍脑袋。有一个细节值得单独提醒全链路日志的traceId贯穿。分布式系统排查问题最怕的就是一个请求跨了五六个服务日志里各管各的根本串不起来。当时我们把这套系统落地完才发现已经是后期了每次排查都要靠时间戳手动关联效率极低。所以做分布式系统日志链路追踪最好第一版就设计进去。架构本身没有标准答案只有适合与否的分寸。我踩过的坑希望你能绕开。之后我会再整理一篇针对TCC事务框架的源码级拆解聊聊框架内部的空回滚和悬挂问题先把这篇收藏起来那篇出了可以直接衔接看。最后再分享一个小技巧真正上线一个新的分布式方案前比如引入某个事务框架或者新的限流配置最稳妥的验证方式是拿一台真实业务Pod切1%的流量过去对照监控指标跑一整天。不要迷信压测报告压测环境永远模拟不出生产环境的真实调用关系和数据分布。灰度验证永远比在会议室里推演靠谱。