分布式事务与一致性：本地消息表

可视化演示

演示业务与消息同事务写入、定时扫描投递MQ与幂等消费闭环，理解本地消息表保障分布式最终一致性的机制。

问题背景：一张被喊丢的菜单

餐厅刚开业时，老板觉得装传菜系统太贵，让收银员直接对厨房喊单。周末爆满，喊声淹没在炒勺声里，顾客等了四十分钟，厨房却查无此菜，投诉率飙升。老板被迫思考：到底怎样才能让“楼下收钱”和“楼上做菜”这两件跨楼层的事，准确对上号？

在分布式系统里，“楼下”和“楼上”是两个独立服务，订单库和支付库分属不同数据库，单个数据库的事务管不到别人家。最经典的办法是两阶段提交（2PC）：先让所有参与者“预提交”，都同意后再“正式提交”。这就像两个楼层各派一名主管，举着对讲机反复确认“你可以吗？我可以”。一旦有人手机没电，整条链路僵住，所有桌都别想上菜——同步阻塞、协调者单点、可用性差，是 2PC 的致命伤。

本地消息表的思路完全换了一个方向：不追求“同一瞬间达成一致”，而是先保证“我方这一亩三分地绝对可靠”，再靠异步任务把差异慢慢抹平。它放弃强一致，接受一个可量化的“最终一致窗口”，换取系统的可用性和吞吐。业务上只要窗口足够短、失败可监控可补偿，用户几乎无感。

节点越多，两阶段提交越容易整体失败，这个直觉可以用一个公式表达：

所以老板明白了一个道理：与其让两个主管举着对讲机互等，不如先把单子用复写纸锁死在夹板上，后面慢慢送。跨楼层的问题，从来不是“喊得响不响”，而是“有没有一张跑不掉的票根”。

核心原理：同一块夹板上的复写纸

老板定下铁律：接单时，收银员必须把“顾客点了什么”和“这张单子已记录”同时写在复写纸上，一次落笔，两份都清晰。笔没水了？两份一起作废重写。这就是原子性：不许出现“单子记了菜没记”，或者“菜记了单子没记”的尴尬。

映射到技术：业务服务在操作自己的数据库时，把“业务变更”（如插入订单）和“往本地消息表插入一条待发消息”放进同一个数据库本地事务。消息表和业务表同库，共享同一个事务管理器，由数据库保证原子提交。

流程很朴素：开启事务 → 写业务记录 → 写消息记录 → 提交。提交成功，业务和消息同时对外可见；提交失败，一起回滚，连“消息曾经存在过”的痕迹都没有。这正是“本地消息表”名字的由来：消息不是先发给 MQ，而是先稳稳落在业务库的表里，事后由任务捞出来投递。它天然保证了“业务成功则消息必不丢”这一条最重要的可靠性。

复写纸的妙处在于：顾客和厨房各拿一份，互不打扰。同理，业务服务写完即返回“下单成功”，不用等支付、库存等服务同步响应——解耦换来的是响应更快、可用性更高，代价只是“别人晚一点知道”。

消息表设计：一张票根上要印哪些栏

复写纸不能是白纸，老板设计了栏目：单号、桌号、菜品、金额、状态（待做/已出餐/已上桌）、重试次数、备注。栏太少，传菜员没法判断；栏太多，写字都费劲。

消息表字段也遵循同样的逻辑：主键 id；业务唯一键（如订单号），它是幂等的锚点；消息内容（JSON 字符串）；状态（待发/已发/完成/死信）；重试次数；下次投递时间；创建与更新时间。其中“状态 + 下次投递时间”要建联合索引，定时扫描就靠它命中。

状态机要严格单向：待发 → 已发 → 完成。投递失败不倒退，而是留在“待发”并累加重试次数，超过上限进入“死信”，由人工或补偿任务兜底。业务键要建唯一索引：同一订单无论产生多少条消息，业务语义上只能有一个“锚”，否则消费端根本无法去重。

老板还发现，若在票根上印“本单唯一编号”，就算单子送重复了，厨房也能认出来。消息表里的“业务唯一键”就是这个编号，它是后面幂等消费的第一道保险。

投递机制：传菜员定时翻票架

票根写好了，不能等顾客自己上厨房取。老板雇了一个传菜员，每 5 分钟巡视一次票架，每次最多抽 20 张送到厨房窗口，并在票根上盖“已送”章。如果厨房说没收到，传菜员就在重试次数上加一，按“1 分钟、2 分钟、4 分钟……”的节奏延长后再来。

技术实现：一个定时任务（Quartz、XXL-Job 或自研调度组件）周期性扫描消息表，选出 status=待发 且 下次投递时间 <= now 的记录，按 limit 分批取出，调用 MQ 发送接口。发送成功，状态置为“已发”；失败，则记录重试次数，并按指数退避更新下次投递时间。

工程要点：线上常常部署多个服务实例，如果每个实例都跑定时任务，同一消息可能被并发捞起。必须用行锁（SELECT …… FOR UPDATE）或乐观锁（update …… where status='待发'）保证只有一台机器投递成功。此外，扫描要加 limit，避免一次捞几十万条把数据库拖垮；批大小要可配置，配合分片一起使用。

传菜员的节奏也很讲究：翻太勤，空转浪费；翻太慢，顾客饿肚子。退避重试就是让“越失败，越要冷静”，给下游系统喘息的时间，而不是用重试把对方打垮。

幂等消费：厨房认单不认人

传菜员手一滑，把同一张单子送进厨房两次。第一次厨师做了菜，第二次怎么办？如果无脑再做一份，顾客会收到两份宫保鸡丁。老板的规矩是：先看单号，已出过餐的单子直接塞进废纸篓。认单不认人，就是幂等。

MQ 的消息投递语义是“至少一次”：网络超时、客户端重启、服务端重发，都会导致同一条消息被消费方收到多次。所以消费端绝不能假设“我收到的每条消息都是第一次”。唯一的防线，是业务逻辑自身的幂等。

常见做法：消费端建一张去重表，把消息里的业务唯一键（订单号/流水号）作为唯一索引，处理前先插入，冲突则说明已处理，直接 ACK 跳过；或者利用业务表本身的唯一约束（如支付流水号）。流程总结为：查重 → 业务处理 → 记录已处理 → 确认消费。四个步骤要和业务操作放在同一个本地事务里，才能保证“处理了就一定记下来”。

厨房认单号，顾客才能安心。幂等看似是消费端的“额外负担”，实则是整个方案的最后一道闸门：投递可以重发、扫描可以重复，只要闸门在，系统永远只会产生一次业务效果，最终一致就不会变成“最终混乱”。

性能优化：一张票架变成一排票架

餐厅火了，一天一万桌，一个票架塞满单子，传菜员翻找都要排队。老板把票架按楼层和区域拆成十几个，传菜员分组负责，翻单速度立刻提上去。这就是分片。

高并发下，消息表会迅速膨胀，单表扫描慢、索引大、写入变热。优化三板斧：第一，联合索引 + 分批 limit，让扫描走索引而不是全表；第二，分片，按订单号哈希或用户 ID 拆成多张表，每张表独立扫描投递；第三，归档，把“完成”状态的老消息定期迁移到历史表，缩小热表。

分片不是越多越好：分片键必须和业务查询模式对齐，否则某个分片成为热点，总吞吐被最短的木板卡住。多线程扫描时，不同分片天然隔离，不会互相竞争行锁；同一个分片内部仍要加锁防重投。容量监控要盯着每个分片的积压量、扫描延迟，而不是只看总量。

老板的经验是：拆票架之前，先数清楚哪个区域单量最大。技术同理，分片之前必须摸清业务键的分布，把热键打散，否则分片再多，也挡不住某个爆款桌把对应票架挤爆。

生产实践：打烊后的三方对账

每天打烊，老板做三件事：看票架还有没有积压的单，翻重试次数异常高的票根，把点菜单、出餐记录、收银记录三方比对。发现“有单没菜”立刻补做，“有菜没单”追查谁漏了单。这套日常，就是生产的监控与对账。

上生产前必须配好监控：消息表积压量、扫描任务延迟、发送失败率、重试分布、死信数量。任何指标异常都应告警。更关键的是定期对账：业务库里的真实业务记录、消息表记录、MQ 消费方的处理结果，三方比对，发现缺口用补偿任务重新投递。因为本地消息表只能降低丢失概率，不能做到绝对零丢失，对账是最后的安全网。

经典故障复盘：某平台订单服务改造本地消息表后，定时任务误配成每分钟全表扫描，扫描 SQL 又没走索引，数据库 CPU 被打满，业务写入连带变慢。对策是强制 limit、加联合索引、按分片并发扫。另一个案例是双实例定时任务未加锁，同一条支付成功消息被投递两次，最终靠消费端幂等键拦截，用户感知无异常——这正好说明幂等设计不是锦上添花，而是防线。

老板的结论写在墙上：“可以慢，不能错；可以晚，不能丢。”本地消息表买到的是可靠性，付出的代价是一段可衡量的时间差。架构师要做的，是度量这个窗口、监控这个窗口，然后把窗口压缩到业务能接受的范围之内。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-# 模拟数据库: 本地消息表message_table = []msg_id_counter = 0 # 消费端幂等去重集合(模拟去重表)processed_key_set = set() # 模拟消息队列(投递目标)outbox = []  def create_order_with_message(order_id, amount):    """核心: 业务操作与消息写入在同一个本地事务中原子完成"""    global msg_id_counter     # 模拟业务执行结果, 失败则两者都不落库    business_success = True     if business_success:        msg_id_counter += 1        message_table.append({            'msg_id': msg_id_counter,            'order_id': order_id,            'amount': amount,            'status': 'PENDING',   # 待发            'retry': 0        })        return True    return False  def scan_and_deliver(batch_size=2):    """定时任务: 扫描待发消息, 模拟发送到 MQ"""    pending = [m for m in message_table if m['status'] == 'PENDING']    for msg in pending[:batch_size]:        msg['status'] = 'SENT'    # 已发        outbox.append(msg)  def consume(msg):    """消费端: 先幂等校验, 再执行业务"""    key = msg['order_id']     # 重复投递: 业务键已存在则直接跳过    if key in processed_key_set:        print('  幂等拦截: 订单 %s 已处理, 跳过重复消费' % key)        return     processed_key_set.add(key)    print('  处理订单 %s, 扣款金额 %.1f 元' % (key, msg['amount']))    msg['status'] = 'DONE'        # 完成  def run():    print('== 第一步: 两笔订单的业务与消息同库提交 ==')    create_order_with_message('A001', 99.9)    create_order_with_message('A002', 199.0)     print('== 第二步: 定时扫描并投递到 MQ ==')    scan_and_deliver(batch_size=5)     print('== 第三步: 消费端处理(含重复投递) ==')    for msg in list(outbox):        consume(msg)        consume(msg)   # 模拟 MQ 重复投递同一条消息     print('== 第四步: 新订单产生, 下一轮扫描重试 ==')    create_order_with_message('A003', 59.0)    scan_and_deliver(batch_size=5)    consume(outbox[-1])     print('== 本地消息表最终状态 ==')    for msg in message_table:        print('  ', msg)  if __name__ == '__main__':    run()

1. message_table.append({把一条消息记录追加进本地消息表，只有业务成功才会执行这步
2. if business_success:模拟业务执行成功才写消息，失败则两条都不落库
3. for msg in pending[:batch_size]:分批取出待发消息，避免一次捞太多压垮数据库
4. msg['status'] = 'SENT'投递成功后，状态从“待发”流转为“已发”
5. if key in processed_key_set:幂等校验：业务键已处理过则直接跳过
6. msg['status'] = 'DONE'消费完成后状态流转为“完成”，闭环收尾

常见误区

面试题