分布式系统里最让人头疼的问题之一就是“钱扣了货没发”或者“订单建了库存没减”。这类跨服务的数据一致性问题本质上就是分布式事务要解决的核心矛盾。而“基于本地消息和可靠消息的解决方案”是我在实际项目里用得最多、落地成本最低、也最容易被团队接受的一类最终一致性方案。它不追求强一致那套昂贵的协调开销而是用“消息”这个中间载体把跨服务的写操作拆成可补偿、可重试的异步流程。这篇文章适合正在做微服务拆分、被跨库事务折磨过的后端开发者也适合刚接触分布式事务、想搞清楚“本地消息表”和“可靠消息”到底差在哪里的同学。我会从设计思路、核心原理、落地步骤一直讲到踩坑排查尽量把每个“为什么这么设计”讲透让你看完能直接照着搭一套。1. 方案整体设计与思路拆解1.1 为什么最终一致性方案在业务里更吃香先把概念摆正。分布式事务大致分两条路一条是强一致路线比如两阶段提交、三阶段提交这类需要协调者统一裁决的方案另一条是最终一致路线允许中间状态短暂不一致但保证最终收敛到正确结果。本地消息表和可靠消息都属于后者。我在实际选型时的判断逻辑很简单看业务能不能容忍“短暂不一致”。像支付扣款和订单状态这种用户点完按钮后一两秒内看到“处理中”是可以接受的但如果要求同一时刻两个库的数据必须完全对齐那就得走强一致。问题是强一致方案的代价太高——协调者单点、同步阻塞、性能损耗大跨机房场景下延迟更是灾难。所以绝大多数互联网业务最终都倒向了最终一致性。本地消息方案的核心思路是把“业务操作”和“发消息”放进同一个本地事务里。业务数据写库和消息记录写库在同一个数据库事务中完成要么都成功要么都失败。然后由一个独立的投递环节把消息表里的记录异步发送给下游下游消费成功后回执确认。这样就把“跨服务的分布式事务”降级成了“本地事务 异步重试”复杂度一下子降下来了。可靠消息方案则更进一步它不自己在业务库里建消息表而是依赖一个支持事务消息的消息中间件。生产者先发一条“半消息”给中间件中间件暂存但不投递生产者执行本地事务成功后再向中间件确认提交中间件这才把消息投递给消费者。如果生产者本地事务失败就通知中间件丢弃半消息。这套机制把“消息表”的职责交给了中间件业务代码更干净但对中间件的能力有硬性要求。两者本质是同一个思想的不同实现层次用“消息持久化 重试 幂等”三件套换取跨服务写操作的最终一致。理解了这个内核后面所有细节都是围绕它展开的。1.2 本地消息表与可靠消息的选型对比选哪个不是拍脑袋得看团队的基础设施和业务体量。我把两者的关键差异整理成一张表方便你对照自己的场景。对比维度本地消息表方案可靠消息方案依赖组件仅需业务库无额外中间件要求需要支持事务消息的消息中间件实现复杂度中等需自建消息表、投递任务、补偿逻辑较低中间件封装了半消息机制业务侵入性较高业务库要加消息表代码要嵌入事务较低业务代码只关心发消息和本地事务消息可靠性依赖本地库和投递任务需自行保证不丢依赖中间件持久化可靠性由中间件背书运维成本低无新增组件较高中间件本身要运维和监控适用场景中小团队、组件受限、消息量中等已有成熟消息中间件、消息量大、追求低侵入我个人的经验是如果团队已经有稳定运行的消息中间件且它支持事务消息优先用可靠消息方案代码干净、维护省心。如果中间件不支持事务消息或者压根不想引入新组件那就老老实实做本地消息表虽然多写点代码但可控性极强出问题也好排查。这里有个容易被忽略的点本地消息表方案里消息表和业务表在同一个库意味着消息的写入会占用业务库的资源和连接。消息量大的时候这张表会迅速膨胀必须配套归档和清理策略。而可靠消息方案把存储压力转移给了中间件业务库更轻。所以选型时不能只看“能不能实现”还要看“长期跑下去谁更省心”。1.3 整体架构的分层设计不管选哪种整体架构都可以拆成四层来理解这样设计出来的系统边界清晰后续扩展也方便。第一层是业务服务层负责执行本地业务逻辑并在同一个本地事务里写入消息记录本地消息表方案或发送半消息可靠消息方案。这一层的关键约束是业务写和消息写必须原子。第二层是消息存储层。本地消息表方案下就是业务库里的那张消息表字段通常包括消息ID、业务类型、消息体、状态、重试次数、创建时间、下次重试时间等。可靠消息方案下则是消息中间件的存储业务方不直接感知。第三层是消息投递层这是本地消息表方案的核心。通常是一个定时任务或独立投递服务扫描状态为“待发送”的消息调用下游接口或发送到消息队列成功后更新状态为“已发送”失败则累加重试次数并计算下次重试时间。这一层必须做到“至少投递一次”配合下游幂等实现“恰好一次”的效果。第四层是消费与补偿层。下游消费消息执行业务成功后回执失败则触发重试。对于长时间未确认的消息需要一个对账补偿机制兜底比如定时扫描“已发送但未确认”的消息主动查询下游业务状态决定重发还是标记完成。这四层里投递层和补偿层是最容易出问题的地方也是区分方案成熟度的关键。很多团队把消息表建好了、投递任务写好了就以为万事大吉结果线上出现消息堆积、重复消费、状态卡死全是这两层没设计好。后面我会专门展开讲。2. 核心细节解析与实操要点2.1 本地消息表的结构设计与字段取舍消息表看着简单字段设计却直接影响后续的投递效率和排查难度。我踩过的坑是早期只设计了“状态”和“重试次数”结果线上出问题时根本不知道消息卡在哪个环节、下次什么时候重试、失败原因是什么排查全靠猜。一张实用的本地消息表我建议至少包含这些字段消息ID全局唯一建议用业务ID拼接或雪花算法生成作为幂等键的基础。业务类型/主题标识这条消息属于哪个业务场景方便投递层路由和分类处理。消息体消息的完整内容建议存JSON但要注意控制大小超大消息体应改为存引用。状态至少区分“待发送”“已发送”“已确认”“发送失败”“已取消”几种状态机要清晰。重试次数记录已重试次数用于判断是否超过阈值转入人工处理。下次重试时间配合退避策略避免失败消息被高频重试打爆下游。创建时间、更新时间排查问题时的时间线依据。失败原因最近一次失败的错误信息排查时非常有用。状态机的设计要严谨。我见过有团队把状态设计成“0未发送、1已发送”结果投递任务和消费回执同时更新状态出现覆盖写。正确做法是每次状态变更都带上前置状态条件比如UPDATE ... SET status已发送 WHERE id? AND status待发送用受影响行数判断是否更新成功避免并发下的状态错乱。注意消息体不要存过大的数据。如果业务消息超过几十KB建议消息表只存业务主键或引用下游消费时再回查业务数据。否则消息表膨胀速度会远超预期投递任务的扫描性能也会急剧下降。2.2 本地事务与消息写入的原子性保证这是整个方案的地基地基不稳后面全塌。核心要求是业务数据写入和消息记录写入必须在同一个数据库事务里。很多新手会写成“先写业务再写消息”两个独立事务中间一旦宕机业务成功但消息丢了下游永远收不到数据就不一致了。正确的写法是把两件事放进一个事务方法里用同一个数据库连接。以常见的Java技术栈为例伪代码结构大致是这样Transactional public void createOrder(Order order) { // 1. 写业务数据 orderMapper.insert(order); // 2. 写本地消息记录与业务数据同事务 LocalMessage msg new LocalMessage(); msg.setMessageId(generateId()); msg.setTopic(order.created); msg.setPayload(buildPayload(order)); msg.setStatus(PENDING); msg.setRetryCount(0); msg.setNextRetryTime(now()); messageMapper.insert(msg); // 事务提交时两者一起生效任一失败整体回滚 }这里有个细节值得说消息的初始状态应该是“待发送”而不是“已发送”。因为事务提交的那一刻消息还没真正投递出去如果标成“已发送”投递任务就扫不到它了。只有投递任务成功调用下游后才把状态改成“已发送”。另一个容易忽略的点是事务的传播行为。如果这个方法被另一个带事务的方法调用要确认传播级别是REQUIRED保证复用同一个事务。如果误用了REQUIRES_NEW消息写入会开新事务和业务事务脱钩原子性就没了。这种问题在代码review时很难一眼看出来建议在关键方法上显式标注传播行为并在测试环境用“事务回滚后消息是否也回滚”的用例验证一遍。2.3 投递任务的扫描策略与退避设计投递任务是本地消息方案的“发动机”它的设计直接决定消息的时效性和系统负载。最朴素的做法是定时任务每隔几秒扫一次“待发送”的消息逐条投递。但这里有几个坑必须提前规避。第一是扫描的索引问题。消息表数据量大了以后如果按状态字段全表扫描性能会崩。正确做法是给“状态 下次重试时间”建联合索引查询条件带上statusPENDING AND next_retry_time now()让数据库走索引。同时要限制单次扫描条数比如每次最多取100条避免一次拉太多导致内存和下游压力。第二是并发投递的锁问题。如果部署了多个投递实例同一条消息可能被多个实例同时扫到并重复投递。解决办法有两种一种是用数据库行锁投递前先SELECT ... FOR UPDATE锁住记录另一种是给消息加一个“投递中”的中间状态用条件更新抢占抢到才投递。我更推荐后者因为行锁在消息量大时容易造成锁竞争。第三是退避策略。消息投递失败后不能立刻无限重试否则下游一旦故障会被重试流量打得更惨。常见的做法是指数退避第1次失败等10秒第2次等30秒第3次等1分钟第4次等5分钟超过阈值比如8次后转入“发送失败”状态等待人工介入或对账补偿。退避时间要写进next_retry_time字段投递任务只扫到期的消息这样既保证了重试又不会给系统造成持续压力。提示退避的最大间隔不要设得太长否则消息时效性会很差。我一般把最大间隔控制在10到15分钟超过这个时间还没投递成功的基本说明下游有实质性问题靠重试解决不了应该尽快告警。2.4 下游消费的幂等设计要点“至少投递一次”意味着下游一定会收到重复消息这是方案本身的特性不是bug。所以下游消费必须幂等这是整个方案能成立的前提。幂等的实现方式有好几种我按推荐程度排个序。最可靠的是唯一键约束。下游在处理业务时把消息ID作为业务表的一个唯一索引字段重复消息插入时触发唯一键冲突捕获后直接返回成功。这种方式把幂等交给数据库保证最稳但要求消息ID能落到业务表里。其次是状态机判断。比如订单状态从“待支付”流转到“已支付”消费时先查当前状态如果已经是“已支付”就直接返回不再重复处理。这种方式适合有明确状态流转的业务但要注意并发下的判断和更新要原子用条件更新UPDATE ... WHERE status待支付并检查受影响行数。再次是分布式锁 去重表。消费前先查去重表看消息ID是否处理过没处理过就加锁处理并写入去重表。这种方式通用性强但多了一次查表和锁的开销消息量大时性能一般。我踩过最深的坑是下游用“先查后写”做幂等但查询和写入之间没有原子性两个重复消息并发进来都查到“未处理”然后都执行了写入幂等失效。所以不管用哪种方式判断和写入必须在同一个原子操作里完成要么靠唯一键要么靠条件更新不能靠应用层的“查了再写”。3. 实操过程与核心环节实现3.1 从零搭建本地消息表方案的完整步骤我把落地过程拆成六步按顺序做基本不会乱。第一步建消息表。在业务库中创建本地消息表字段按前面说的设计重点是把“状态 下次重试时间”的联合索引建好。表名建议带业务前缀比如local_message避免和业务表混淆。第二步改造业务写入逻辑。在需要发消息的业务方法上把消息写入嵌进同一个事务。这里要注意消息体的构建应该基于业务数据最好在业务写入之后、事务提交之前构建保证消息内容和业务数据一致。第三步实现投递任务。可以用定时任务框架也可以用独立的投递服务。核心逻辑是扫描到期消息 → 抢占条件更新为“投递中”→ 调用下游或发MQ → 成功则更新为“已发送”失败则更新重试次数和下次重试时间。抢占这一步用条件更新实现保证多实例下不重复投递。第四步实现下游消费。下游收到消息后执行业务按幂等要求处理成功后返回确认。如果是通过MQ中转消费成功后提交ack如果是直接调用下游接口下游返回成功即视为确认。第五步实现对账补偿。定时扫描“已发送但长时间未确认”的消息主动查询下游业务状态。如果下游已处理标记消息完成如果下游未处理重新投递。这一步是兜底防止消息在投递和消费之间丢失。第六步配置监控告警。监控“待发送”消息的积压量、投递失败率、重试次数超阈值的消息数。积压量持续上涨说明投递环节有问题失败率突增说明下游异常这些都要及时告警。这六步里第三步和第五步是工作量最大、也最容易出问题的。投递任务的抢占逻辑如果写错会出现重复投递或消息漏投对账补偿如果设计得太激进会给下游造成额外压力。建议先在测试环境用小流量验证观察消息状态流转是否符合预期再逐步放量。3.2 可靠消息方案的接入流程与关键配置如果选用可靠消息方案流程会简洁不少但对中间件的配置要求更细。以支持事务消息的消息中间件为例接入流程大致是这样。生产者端先发送半消息中间件返回成功后执行本地事务根据本地事务结果向中间件发送提交或回滚指令。这里的关键是本地事务的执行结果要能被中间件回查。因为可能出现生产者发送提交指令时网络中断中间件不知道本地事务到底成没成功会主动回查生产者的一个接口。所以生产者必须实现事务状态回查接口根据业务数据判断本地事务是否成功返回提交或回滚。消费者端正常消费消息并执行业务成功后确认。可靠消息方案同样要求消费幂等因为中间件在异常情况下也可能重复投递。配置上有几个参数要特别注意。半消息的过期时间不能太短否则生产者本地事务还没执行完半消息就被清理了也不能太长否则回查窗口过大。一般设置在几分钟到十几分钟之间根据本地事务的耗时来定。回查的最大次数也要配置合理回查多次仍无法确定状态的应该告警并转人工处理而不是无限回查。注意可靠消息方案虽然业务侵入小但它把复杂度转移到了中间件的配置和运维上。如果团队对中间件的事务消息机制不熟出问题时排查难度反而更高。选型时要评估团队对中间件的掌握程度不能只看代码写得少。3.3 消息状态流转的完整生命周期演示把一条消息从生到死的状态流转理清楚对排查问题极有帮助。以本地消息表方案为例一条消息的典型生命周期是这样的创建时状态为“待发送”此时业务数据和消息记录已同事务提交。投递任务扫描到它条件更新为“投递中”并抢占成功然后调用下游。下游返回成功更新为“已发送”下游返回失败或超时更新重试次数和下次重试时间状态回到“待发送”。如果重试次数超过阈值状态转为“发送失败”等待对账或人工处理。对账任务发现“已发送”但下游实际未处理的重新置为“待发送”再次投递。这个流转里“投递中”是个容易被忽略但很重要的状态。没有它投递任务抢占和投递结果更新之间如果宕机消息会一直卡在“待发送”被反复投递。有了“投递中”配合一个超时机制比如“投递中”超过5分钟未更新视为投递失败重置为“待发送”就能自动恢复卡死的消息。状态流转的每次更新都要用条件更新带上前置状态避免并发覆盖。比如从“投递中”更新为“已发送”SQL要写成UPDATE ... SET status已发送 WHERE id? AND status投递中受影响行数为0说明状态已被其他操作改变当前操作应放弃。3.4 对账补偿机制的实现思路对账补偿是最后一道防线它的作用是发现并修复“消息状态和下游实际状态不一致”的情况。实现上有两种思路。一种是基于消息表的对账。定时扫描“已发送”状态且超过一定时间比如10分钟的消息逐条查询下游业务状态。如果下游已处理说明消息其实成功了只是确认回执丢了把消息标记为“已确认”如果下游未处理说明消息丢了或消费失败重新投递。这种思路实现简单但依赖下游提供状态查询接口。另一种是基于业务数据的双向对账。定时比对上游业务数据和下游业务数据找出“上游有、下游无”的记录反查对应的消息重新投递。这种思路更彻底能发现消息表本身出问题的情况但实现复杂度高适合对一致性要求极高的核心业务。我一般先用第一种思路够用且成本低。对账频率不用太高几分钟一次即可因为它是兜底手段不是主流程。对账时要注意控制查询下游的并发量避免对账任务本身把下游打挂。4. 常见问题与排查技巧实录4.1 消息重复消费的典型场景与根治方法重复消费是这个方案里最高频的问题几乎每个落地团队都会遇到。我把常见场景和对应解法整理成一张速查表。重复场景根本原因解决方法投递成功但确认回执丢失网络抖动或下游响应超时下游幂等 对账补偿投递任务重复扫描多实例未做抢占或抢占失效条件更新抢占 投递中状态重试与正常投递并发退避时间未生效或时钟偏差严格按next_retry_time扫描MQ重复投递中间件at-least-once语义消费端幂等不依赖MQ去重对账重发与正常重试叠加对账和投递任务未协调对账重发前先检查消息当前状态根治重复消费的唯一办法就是下游幂等没有捷径。我见过有团队试图在投递层做“精确一次”投递结果在分布式环境下根本做不到最后还是回到幂等这条路。所以设计阶段就要把幂等作为硬性要求写进下游接口规范而不是等出了问题再补。4.2 消息积压的排查路径与扩容策略消息积压表现为“待发送”消息数量持续上涨投递速度跟不上生产速度。排查时按这个顺序走先看投递任务是否还在正常运行有没有线程卡死或异常退出再看下游接口的响应时间和错误率下游变慢会直接拖慢投递然后看消息表的扫描性能索引是否失效、单次扫描量是否过大最后看生产端是否有突发流量。扩容策略上短期可以增加投递任务的并发线程数或实例数但要注意抢占逻辑必须支持并发中期可以优化下游接口性能减少单条消息的处理耗时长期要考虑消息表的分库分表或归档避免单表数据量过大导致扫描变慢。有个容易被忽略的点投递任务的批量大小和并发数要匹配下游的承受能力。盲目加大并发可能把下游打挂反而造成更大面积积压。我一般会先压测下游的吞吐上限再据此设置投递并发留20%的余量。4.3 消息状态卡死的定位与恢复手段状态卡死是指消息长时间停留在某个中间状态不再流转常见的是卡在“投递中”或“已发送未确认”。定位时先查这条消息的更新时间如果很久没变基本可以确定卡死。然后看它卡在哪个状态卡在“投递中”多半是投递实例宕机或线程异常需要超时重置机制卡在“已发送未确认”多半是下游处理了但回执丢了需要对账补偿确认。恢复手段上对于卡在“投递中”的靠超时扫描任务把超过阈值的重置为“待发送”对于卡在“已发送未确认”的靠对账任务查询下游状态后决定完成还是重发。这两种恢复都应该是自动的不能依赖人工。人工介入只针对重试次数超阈值、对账也无法确定的情况。提示状态卡死往往不是单条消息的问题而是某个环节整体异常的信号。发现卡死消息时要顺带检查同一时间段的其他消息是否也异常避免只修个案忽略系统性故障。4.4 实操心得与避坑清单最后分享几条从实际项目里攒下来的经验都是文档里不会写的。第一条消息表要和业务表同库但可以考虑独立表空间。同库是为了保证事务原子性但消息表增长快独立表空间方便单独做归档和清理不影响业务表。第二条投递任务的日志要打全。每条消息的投递开始、成功、失败、重试都要有日志带上消息ID和耗时。线上排查时这些日志是唯一能还原现场的东西。我吃过日志不全的亏一条消息丢了查了半天不知道是没投还是投了没确认。第三条幂等键的选择要慎重。用消息ID做幂等键最直接但如果业务本身有天然的唯一键比如订单号优先用业务唯一键这样即使消息ID生成逻辑出问题幂等依然有效。第四条退避策略要可配置。不同业务对时效性要求不同把退避的初始间隔、倍数、最大间隔做成配置项不同消息主题用不同策略比写死一套参数灵活得多。第五条上线前一定要做故障演练。模拟投递任务宕机、下游超时、数据库主从切换等场景验证消息不丢、不重复、能自动恢复。演练中暴露的问题比线上出问题代价小得多。这套方案我从单体架构一路用到微服务中间经历过消息量从每天几千到几千万的跨度核心逻辑没变过变的是投递层的并发和存储层的分片。把本地事务原子性、投递抢占、下游幂等、对账补偿这四件事做扎实剩下的就是根据体量做工程优化。真正难的不是写代码是想清楚每个环节失败时系统会怎样、怎么自动恢复——这个思考过程比任何现成的框架都值钱。 
长河君 · 2026/10/27 7:24:19 · 阅读 1.2k 本地消息与可靠消息：分布式事务最终一致性落地方案
分布式系统里最让人头疼的问题之一就是“钱扣了货没发”或者“订单建了库存没减”。这类跨服务的数据一致性问题本质上就是分布式事务要解决的核心矛盾。而“基于本地消息和可靠消息的解决方案”是我在实际项目里用得最多、落地成本最低、也最容易被团队接受的一类最终一致性方案。它不追求强一致那套昂贵的协调开销而是用“消息”这个中间载体把跨服务的写操作拆成可补偿、可重试的异步流程。这篇文章适合正在做微服务拆分、被跨库事务折磨过的后端开发者也适合刚接触分布式事务、想搞清楚“本地消息表”和“可靠消息”到底差在哪里的同学。我会从设计思路、核心原理、落地步骤一直讲到踩坑排查尽量把每个“为什么这么设计”讲透让你看完能直接照着搭一套。1. 方案整体设计与思路拆解1.1 为什么最终一致性方案在业务里更吃香先把概念摆正。分布式事务大致分两条路一条是强一致路线比如两阶段提交、三阶段提交这类需要协调者统一裁决的方案另一条是最终一致路线允许中间状态短暂不一致但保证最终收敛到正确结果。本地消息表和可靠消息都属于后者。我在实际选型时的判断逻辑很简单看业务能不能容忍“短暂不一致”。像支付扣款和订单状态这种用户点完按钮后一两秒内看到“处理中”是可以接受的但如果要求同一时刻两个库的数据必须完全对齐那就得走强一致。问题是强一致方案的代价太高——协调者单点、同步阻塞、性能损耗大跨机房场景下延迟更是灾难。所以绝大多数互联网业务最终都倒向了最终一致性。本地消息方案的核心思路是把“业务操作”和“发消息”放进同一个本地事务里。业务数据写库和消息记录写库在同一个数据库事务中完成要么都成功要么都失败。然后由一个独立的投递环节把消息表里的记录异步发送给下游下游消费成功后回执确认。这样就把“跨服务的分布式事务”降级成了“本地事务 异步重试”复杂度一下子降下来了。可靠消息方案则更进一步它不自己在业务库里建消息表而是依赖一个支持事务消息的消息中间件。生产者先发一条“半消息”给中间件中间件暂存但不投递生产者执行本地事务成功后再向中间件确认提交中间件这才把消息投递给消费者。如果生产者本地事务失败就通知中间件丢弃半消息。这套机制把“消息表”的职责交给了中间件业务代码更干净但对中间件的能力有硬性要求。两者本质是同一个思想的不同实现层次用“消息持久化 重试 幂等”三件套换取跨服务写操作的最终一致。理解了这个内核后面所有细节都是围绕它展开的。1.2 本地消息表与可靠消息的选型对比选哪个不是拍脑袋得看团队的基础设施和业务体量。我把两者的关键差异整理成一张表方便你对照自己的场景。对比维度本地消息表方案可靠消息方案依赖组件仅需业务库无额外中间件要求需要支持事务消息的消息中间件实现复杂度中等需自建消息表、投递任务、补偿逻辑较低中间件封装了半消息机制业务侵入性较高业务库要加消息表代码要嵌入事务较低业务代码只关心发消息和本地事务消息可靠性依赖本地库和投递任务需自行保证不丢依赖中间件持久化可靠性由中间件背书运维成本低无新增组件较高中间件本身要运维和监控适用场景中小团队、组件受限、消息量中等已有成熟消息中间件、消息量大、追求低侵入我个人的经验是如果团队已经有稳定运行的消息中间件且它支持事务消息优先用可靠消息方案代码干净、维护省心。如果中间件不支持事务消息或者压根不想引入新组件那就老老实实做本地消息表虽然多写点代码但可控性极强出问题也好排查。这里有个容易被忽略的点本地消息表方案里消息表和业务表在同一个库意味着消息的写入会占用业务库的资源和连接。消息量大的时候这张表会迅速膨胀必须配套归档和清理策略。而可靠消息方案把存储压力转移给了中间件业务库更轻。所以选型时不能只看“能不能实现”还要看“长期跑下去谁更省心”。1.3 整体架构的分层设计不管选哪种整体架构都可以拆成四层来理解这样设计出来的系统边界清晰后续扩展也方便。第一层是业务服务层负责执行本地业务逻辑并在同一个本地事务里写入消息记录本地消息表方案或发送半消息可靠消息方案。这一层的关键约束是业务写和消息写必须原子。第二层是消息存储层。本地消息表方案下就是业务库里的那张消息表字段通常包括消息ID、业务类型、消息体、状态、重试次数、创建时间、下次重试时间等。可靠消息方案下则是消息中间件的存储业务方不直接感知。第三层是消息投递层这是本地消息表方案的核心。通常是一个定时任务或独立投递服务扫描状态为“待发送”的消息调用下游接口或发送到消息队列成功后更新状态为“已发送”失败则累加重试次数并计算下次重试时间。这一层必须做到“至少投递一次”配合下游幂等实现“恰好一次”的效果。第四层是消费与补偿层。下游消费消息执行业务成功后回执失败则触发重试。对于长时间未确认的消息需要一个对账补偿机制兜底比如定时扫描“已发送但未确认”的消息主动查询下游业务状态决定重发还是标记完成。这四层里投递层和补偿层是最容易出问题的地方也是区分方案成熟度的关键。很多团队把消息表建好了、投递任务写好了就以为万事大吉结果线上出现消息堆积、重复消费、状态卡死全是这两层没设计好。后面我会专门展开讲。2. 核心细节解析与实操要点2.1 本地消息表的结构设计与字段取舍消息表看着简单字段设计却直接影响后续的投递效率和排查难度。我踩过的坑是早期只设计了“状态”和“重试次数”结果线上出问题时根本不知道消息卡在哪个环节、下次什么时候重试、失败原因是什么排查全靠猜。一张实用的本地消息表我建议至少包含这些字段消息ID全局唯一建议用业务ID拼接或雪花算法生成作为幂等键的基础。业务类型/主题标识这条消息属于哪个业务场景方便投递层路由和分类处理。消息体消息的完整内容建议存JSON但要注意控制大小超大消息体应改为存引用。状态至少区分“待发送”“已发送”“已确认”“发送失败”“已取消”几种状态机要清晰。重试次数记录已重试次数用于判断是否超过阈值转入人工处理。下次重试时间配合退避策略避免失败消息被高频重试打爆下游。创建时间、更新时间排查问题时的时间线依据。失败原因最近一次失败的错误信息排查时非常有用。状态机的设计要严谨。我见过有团队把状态设计成“0未发送、1已发送”结果投递任务和消费回执同时更新状态出现覆盖写。正确做法是每次状态变更都带上前置状态条件比如UPDATE ... SET status已发送 WHERE id? AND status待发送用受影响行数判断是否更新成功避免并发下的状态错乱。注意消息体不要存过大的数据。如果业务消息超过几十KB建议消息表只存业务主键或引用下游消费时再回查业务数据。否则消息表膨胀速度会远超预期投递任务的扫描性能也会急剧下降。2.2 本地事务与消息写入的原子性保证这是整个方案的地基地基不稳后面全塌。核心要求是业务数据写入和消息记录写入必须在同一个数据库事务里。很多新手会写成“先写业务再写消息”两个独立事务中间一旦宕机业务成功但消息丢了下游永远收不到数据就不一致了。正确的写法是把两件事放进一个事务方法里用同一个数据库连接。以常见的Java技术栈为例伪代码结构大致是这样Transactional public void createOrder(Order order) { // 1. 写业务数据 orderMapper.insert(order); // 2. 写本地消息记录与业务数据同事务 LocalMessage msg new LocalMessage(); msg.setMessageId(generateId()); msg.setTopic(order.created); msg.setPayload(buildPayload(order)); msg.setStatus(PENDING); msg.setRetryCount(0); msg.setNextRetryTime(now()); messageMapper.insert(msg); // 事务提交时两者一起生效任一失败整体回滚 }这里有个细节值得说消息的初始状态应该是“待发送”而不是“已发送”。因为事务提交的那一刻消息还没真正投递出去如果标成“已发送”投递任务就扫不到它了。只有投递任务成功调用下游后才把状态改成“已发送”。另一个容易忽略的点是事务的传播行为。如果这个方法被另一个带事务的方法调用要确认传播级别是REQUIRED保证复用同一个事务。如果误用了REQUIRES_NEW消息写入会开新事务和业务事务脱钩原子性就没了。这种问题在代码review时很难一眼看出来建议在关键方法上显式标注传播行为并在测试环境用“事务回滚后消息是否也回滚”的用例验证一遍。2.3 投递任务的扫描策略与退避设计投递任务是本地消息方案的“发动机”它的设计直接决定消息的时效性和系统负载。最朴素的做法是定时任务每隔几秒扫一次“待发送”的消息逐条投递。但这里有几个坑必须提前规避。第一是扫描的索引问题。消息表数据量大了以后如果按状态字段全表扫描性能会崩。正确做法是给“状态 下次重试时间”建联合索引查询条件带上statusPENDING AND next_retry_time now()让数据库走索引。同时要限制单次扫描条数比如每次最多取100条避免一次拉太多导致内存和下游压力。第二是并发投递的锁问题。如果部署了多个投递实例同一条消息可能被多个实例同时扫到并重复投递。解决办法有两种一种是用数据库行锁投递前先SELECT ... FOR UPDATE锁住记录另一种是给消息加一个“投递中”的中间状态用条件更新抢占抢到才投递。我更推荐后者因为行锁在消息量大时容易造成锁竞争。第三是退避策略。消息投递失败后不能立刻无限重试否则下游一旦故障会被重试流量打得更惨。常见的做法是指数退避第1次失败等10秒第2次等30秒第3次等1分钟第4次等5分钟超过阈值比如8次后转入“发送失败”状态等待人工介入或对账补偿。退避时间要写进next_retry_time字段投递任务只扫到期的消息这样既保证了重试又不会给系统造成持续压力。提示退避的最大间隔不要设得太长否则消息时效性会很差。我一般把最大间隔控制在10到15分钟超过这个时间还没投递成功的基本说明下游有实质性问题靠重试解决不了应该尽快告警。2.4 下游消费的幂等设计要点“至少投递一次”意味着下游一定会收到重复消息这是方案本身的特性不是bug。所以下游消费必须幂等这是整个方案能成立的前提。幂等的实现方式有好几种我按推荐程度排个序。最可靠的是唯一键约束。下游在处理业务时把消息ID作为业务表的一个唯一索引字段重复消息插入时触发唯一键冲突捕获后直接返回成功。这种方式把幂等交给数据库保证最稳但要求消息ID能落到业务表里。其次是状态机判断。比如订单状态从“待支付”流转到“已支付”消费时先查当前状态如果已经是“已支付”就直接返回不再重复处理。这种方式适合有明确状态流转的业务但要注意并发下的判断和更新要原子用条件更新UPDATE ... WHERE status待支付并检查受影响行数。再次是分布式锁 去重表。消费前先查去重表看消息ID是否处理过没处理过就加锁处理并写入去重表。这种方式通用性强但多了一次查表和锁的开销消息量大时性能一般。我踩过最深的坑是下游用“先查后写”做幂等但查询和写入之间没有原子性两个重复消息并发进来都查到“未处理”然后都执行了写入幂等失效。所以不管用哪种方式判断和写入必须在同一个原子操作里完成要么靠唯一键要么靠条件更新不能靠应用层的“查了再写”。3. 实操过程与核心环节实现3.1 从零搭建本地消息表方案的完整步骤我把落地过程拆成六步按顺序做基本不会乱。第一步建消息表。在业务库中创建本地消息表字段按前面说的设计重点是把“状态 下次重试时间”的联合索引建好。表名建议带业务前缀比如local_message避免和业务表混淆。第二步改造业务写入逻辑。在需要发消息的业务方法上把消息写入嵌进同一个事务。这里要注意消息体的构建应该基于业务数据最好在业务写入之后、事务提交之前构建保证消息内容和业务数据一致。第三步实现投递任务。可以用定时任务框架也可以用独立的投递服务。核心逻辑是扫描到期消息 → 抢占条件更新为“投递中”→ 调用下游或发MQ → 成功则更新为“已发送”失败则更新重试次数和下次重试时间。抢占这一步用条件更新实现保证多实例下不重复投递。第四步实现下游消费。下游收到消息后执行业务按幂等要求处理成功后返回确认。如果是通过MQ中转消费成功后提交ack如果是直接调用下游接口下游返回成功即视为确认。第五步实现对账补偿。定时扫描“已发送但长时间未确认”的消息主动查询下游业务状态。如果下游已处理标记消息完成如果下游未处理重新投递。这一步是兜底防止消息在投递和消费之间丢失。第六步配置监控告警。监控“待发送”消息的积压量、投递失败率、重试次数超阈值的消息数。积压量持续上涨说明投递环节有问题失败率突增说明下游异常这些都要及时告警。这六步里第三步和第五步是工作量最大、也最容易出问题的。投递任务的抢占逻辑如果写错会出现重复投递或消息漏投对账补偿如果设计得太激进会给下游造成额外压力。建议先在测试环境用小流量验证观察消息状态流转是否符合预期再逐步放量。3.2 可靠消息方案的接入流程与关键配置如果选用可靠消息方案流程会简洁不少但对中间件的配置要求更细。以支持事务消息的消息中间件为例接入流程大致是这样。生产者端先发送半消息中间件返回成功后执行本地事务根据本地事务结果向中间件发送提交或回滚指令。这里的关键是本地事务的执行结果要能被中间件回查。因为可能出现生产者发送提交指令时网络中断中间件不知道本地事务到底成没成功会主动回查生产者的一个接口。所以生产者必须实现事务状态回查接口根据业务数据判断本地事务是否成功返回提交或回滚。消费者端正常消费消息并执行业务成功后确认。可靠消息方案同样要求消费幂等因为中间件在异常情况下也可能重复投递。配置上有几个参数要特别注意。半消息的过期时间不能太短否则生产者本地事务还没执行完半消息就被清理了也不能太长否则回查窗口过大。一般设置在几分钟到十几分钟之间根据本地事务的耗时来定。回查的最大次数也要配置合理回查多次仍无法确定状态的应该告警并转人工处理而不是无限回查。注意可靠消息方案虽然业务侵入小但它把复杂度转移到了中间件的配置和运维上。如果团队对中间件的事务消息机制不熟出问题时排查难度反而更高。选型时要评估团队对中间件的掌握程度不能只看代码写得少。3.3 消息状态流转的完整生命周期演示把一条消息从生到死的状态流转理清楚对排查问题极有帮助。以本地消息表方案为例一条消息的典型生命周期是这样的创建时状态为“待发送”此时业务数据和消息记录已同事务提交。投递任务扫描到它条件更新为“投递中”并抢占成功然后调用下游。下游返回成功更新为“已发送”下游返回失败或超时更新重试次数和下次重试时间状态回到“待发送”。如果重试次数超过阈值状态转为“发送失败”等待对账或人工处理。对账任务发现“已发送”但下游实际未处理的重新置为“待发送”再次投递。这个流转里“投递中”是个容易被忽略但很重要的状态。没有它投递任务抢占和投递结果更新之间如果宕机消息会一直卡在“待发送”被反复投递。有了“投递中”配合一个超时机制比如“投递中”超过5分钟未更新视为投递失败重置为“待发送”就能自动恢复卡死的消息。状态流转的每次更新都要用条件更新带上前置状态避免并发覆盖。比如从“投递中”更新为“已发送”SQL要写成UPDATE ... SET status已发送 WHERE id? AND status投递中受影响行数为0说明状态已被其他操作改变当前操作应放弃。3.4 对账补偿机制的实现思路对账补偿是最后一道防线它的作用是发现并修复“消息状态和下游实际状态不一致”的情况。实现上有两种思路。一种是基于消息表的对账。定时扫描“已发送”状态且超过一定时间比如10分钟的消息逐条查询下游业务状态。如果下游已处理说明消息其实成功了只是确认回执丢了把消息标记为“已确认”如果下游未处理说明消息丢了或消费失败重新投递。这种思路实现简单但依赖下游提供状态查询接口。另一种是基于业务数据的双向对账。定时比对上游业务数据和下游业务数据找出“上游有、下游无”的记录反查对应的消息重新投递。这种思路更彻底能发现消息表本身出问题的情况但实现复杂度高适合对一致性要求极高的核心业务。我一般先用第一种思路够用且成本低。对账频率不用太高几分钟一次即可因为它是兜底手段不是主流程。对账时要注意控制查询下游的并发量避免对账任务本身把下游打挂。4. 常见问题与排查技巧实录4.1 消息重复消费的典型场景与根治方法重复消费是这个方案里最高频的问题几乎每个落地团队都会遇到。我把常见场景和对应解法整理成一张速查表。重复场景根本原因解决方法投递成功但确认回执丢失网络抖动或下游响应超时下游幂等 对账补偿投递任务重复扫描多实例未做抢占或抢占失效条件更新抢占 投递中状态重试与正常投递并发退避时间未生效或时钟偏差严格按next_retry_time扫描MQ重复投递中间件at-least-once语义消费端幂等不依赖MQ去重对账重发与正常重试叠加对账和投递任务未协调对账重发前先检查消息当前状态根治重复消费的唯一办法就是下游幂等没有捷径。我见过有团队试图在投递层做“精确一次”投递结果在分布式环境下根本做不到最后还是回到幂等这条路。所以设计阶段就要把幂等作为硬性要求写进下游接口规范而不是等出了问题再补。4.2 消息积压的排查路径与扩容策略消息积压表现为“待发送”消息数量持续上涨投递速度跟不上生产速度。排查时按这个顺序走先看投递任务是否还在正常运行有没有线程卡死或异常退出再看下游接口的响应时间和错误率下游变慢会直接拖慢投递然后看消息表的扫描性能索引是否失效、单次扫描量是否过大最后看生产端是否有突发流量。扩容策略上短期可以增加投递任务的并发线程数或实例数但要注意抢占逻辑必须支持并发中期可以优化下游接口性能减少单条消息的处理耗时长期要考虑消息表的分库分表或归档避免单表数据量过大导致扫描变慢。有个容易被忽略的点投递任务的批量大小和并发数要匹配下游的承受能力。盲目加大并发可能把下游打挂反而造成更大面积积压。我一般会先压测下游的吞吐上限再据此设置投递并发留20%的余量。4.3 消息状态卡死的定位与恢复手段状态卡死是指消息长时间停留在某个中间状态不再流转常见的是卡在“投递中”或“已发送未确认”。定位时先查这条消息的更新时间如果很久没变基本可以确定卡死。然后看它卡在哪个状态卡在“投递中”多半是投递实例宕机或线程异常需要超时重置机制卡在“已发送未确认”多半是下游处理了但回执丢了需要对账补偿确认。恢复手段上对于卡在“投递中”的靠超时扫描任务把超过阈值的重置为“待发送”对于卡在“已发送未确认”的靠对账任务查询下游状态后决定完成还是重发。这两种恢复都应该是自动的不能依赖人工。人工介入只针对重试次数超阈值、对账也无法确定的情况。提示状态卡死往往不是单条消息的问题而是某个环节整体异常的信号。发现卡死消息时要顺带检查同一时间段的其他消息是否也异常避免只修个案忽略系统性故障。4.4 实操心得与避坑清单最后分享几条从实际项目里攒下来的经验都是文档里不会写的。第一条消息表要和业务表同库但可以考虑独立表空间。同库是为了保证事务原子性但消息表增长快独立表空间方便单独做归档和清理不影响业务表。第二条投递任务的日志要打全。每条消息的投递开始、成功、失败、重试都要有日志带上消息ID和耗时。线上排查时这些日志是唯一能还原现场的东西。我吃过日志不全的亏一条消息丢了查了半天不知道是没投还是投了没确认。第三条幂等键的选择要慎重。用消息ID做幂等键最直接但如果业务本身有天然的唯一键比如订单号优先用业务唯一键这样即使消息ID生成逻辑出问题幂等依然有效。第四条退避策略要可配置。不同业务对时效性要求不同把退避的初始间隔、倍数、最大间隔做成配置项不同消息主题用不同策略比写死一套参数灵活得多。第五条上线前一定要做故障演练。模拟投递任务宕机、下游超时、数据库主从切换等场景验证消息不丢、不重复、能自动恢复。演练中暴露的问题比线上出问题代价小得多。这套方案我从单体架构一路用到微服务中间经历过消息量从每天几千到几千万的跨度核心逻辑没变过变的是投递层的并发和存储层的分片。把本地事务原子性、投递抢占、下游幂等、对账补偿这四件事做扎实剩下的就是根据体量做工程优化。真正难的不是写代码是想清楚每个环节失败时系统会怎样、怎么自动恢复——这个思考过程比任何现成的框架都值钱。