在即时业务里，至少一次投递很容易，准确一次才是难题；但“准确一次”更多是系统级效果，而非某一环节的魔法。秒单将一致性拆成三层：传输层保证“可重放+有顺序”、应用层保证“幂等+去重”、业务层保证“补偿+对账”。三层合力，才能把“幽灵事件”“重复入账”“顺序错乱”关在安全边界之外。
第一层是传输与位点。消息总线按分区与副本提供吞吐与持久化，消费者组以位点（offset）记录进度；拥塞触发背压，迫使上游限速。秒单把“位点管理”做成受控资源：提交 offset 只有在本地事务落地后进行，防止“读到—没处理—却已前进”的假进度；异常回放支持“按位点/按时间窗/按 TraceID”三种模式，复原迅速。
第二层是幂等与去重。应用侧必须设计幂等键（Idempotency Key）与去重表：每个业务事件携带天然唯一键（如业务 ID + 版本），处理前先查重，处理后写入“已处理明细”，并设置 TTL 与合并策略。秒单对跨服务的链路，要求在端到端传递幂等键，避免“到下游又生成一次新键”。当同一键重复提交时，系统返回“成功但不重复执行”的幂等回执，用户端体验连贯。
第三层是Outbox/InBox 模式。在需要与数据库事务打包时，服务把要发送的事件先写进本地 Outbox 表，与业务写入同属一个事务；随后由可靠的出站任务“扫 Outbox → 发消息 → 标记已发”，彻底消除“写了业务却没发消息”的丢失。下游对应Inbox 表，记录已消费的幂等键，做到“收到了就只处理一次”。秒单把 Outbox/InBox 做成框架能力，让业务方“开箱即用”。
第四层是Saga/补偿。分布式长事务不追求强一致，而追求可补偿的一致。每个步骤都有对应补偿动作（撤销/反向写），并由协调器记录状态；失败时按反向顺序触发补偿，最终回到一致状态。秒单在账务类场景中严格区分“可补偿字段/不可补偿字段”，前者走 Saga，后者采取更保守的“小范围强一致 + 事务外补偿”，把风险集中在最小闭环。
第五层是顺序与幂等的博弈。消息系统的全局顺序昂贵且不必要，秒单采取“分区内有序 + 业务键路由”的策略：按用户/订单/商家维度路由到稳定分区，保证局部顺序，同时用幂等避免跨分区回放引发的副作用。对于确实需要全局约束的场景（如同一商家同一时刻只能有一个结算批次），由分布式锁/法定人数写入承载，不把全局有序强加给消息总线。
第六层是死信与中毒消息。任何系统都会遇到“毒消息”（无法解析/违反约束/触发异常）。秒单设置死信队列与隔离消费：达到重试阈值的消息被转入死信，人工或离线作业介入；死信不是“黑洞”，而是带有上下文、堆栈、样本数据的工作池。周期性“毒性拆解”会修正解析器/校验器/字段约束，并产出回归测试，防止同类问题重演。
第七层是对账与审计。准确一次的证据不在“口头承诺”，而在可回放的账目。秒单保留“事件—处理—结果”的全链路指纹：谁产生、何时入总线、何时被消费、处理成什么结果；按日跑差异对账（来源对账、内部对账、外部对账），自动生成修复任务（重放、补账、冲正）。合规侧，敏感字段端到端加密、访问经权限网关审批，所有读取与导出留痕。
第八层是观测与告警。消息系统的健康不是“TPS 有多高”，而是“堆积曲线、延迟分布、重复比率、死信速率、位点抖动”。秒单在看板上提供“主题/分区/消费者组”的三维视图，异常检测以季节性分解+突变识别为主；任何一次回放、回退、补偿都被记录为一等事件，便于复盘恢复时间（MTTR）与影响半径。
把这些拼起来你会发现，“准确一次”并非某一层的承诺，而是多层协同后的系统级属性：传输可重放、应用可去重、业务可补偿、全链可对账。对 秒单 而言，这种“有证据的确定性”，才是即时业务赖以生存的真正速度。
