消息交付语义取决于生产、存储与消费边界

消息系统把发送方和处理方在时间与容量上解耦，但网络中断、进程崩溃和重试会让“消息送达一次”变得复杂。至多一次、至少一次和恰好一次不是营销等级，而是对特定边界内丢失与重复可能性的描述。要判断业务最终发生什么，必须把生产、代理存储、消费确认和外部副作用连在一起分析。

即使代理内部提供事务，消费者向数据库写入或调用第三方接口时仍可能出现新的失败窗口。消息系统的保证不能自动延伸到它不了解的外部系统。

确认时点决定丢失与重复窗口

生产者发送消息后需要知道代理是否已持久化。若在收到确认前连接断开，生产者无法确定消息是未写入，还是已写入但确认丢失。选择不重试可能丢消息，选择重试可能产生重复。

幂等生产者可以让代理识别同一生产会话中的重发，降低日志重复，但其作用范围受协议、会话和配置约束。应用重新生成不同标识的业务事件时，代理无法知道它们语义相同。

持久化确认还涉及副本数量和故障模型。只写入一个暂时可用节点就确认，节点丢失可能带走已确认消息；等待更多副本提高耐久性，但增加延迟并可能在部分故障时降低可用性。

生产端应为每个业务事件分配稳定标识，并记录消息产生与业务事务的关系。数据库更新成功但发送失败是常见双写问题，可以通过事务性发件箱把待发事件与业务状态写入同一数据库事务，再由独立发布器重试。

至多一次通常在处理前就确认消息，或失败后不重试。每条消息最多产生一次处理尝试，因此不会因重新投递形成重复，但消费者在确认后崩溃会造成丢失。

这种语义适合可丢弃遥测、周期性刷新或后续样本会覆盖前值的场景。它不适合订单、账务或不可重建状态。选择它应明确可接受丢失率和补偿来源。

“没有重复”也只限于交付过程。上游可能本来就产生重复事件，用户可能重复提交，网络入口也可能重放请求。业务层仍需定义事件身份。

至少一次在处理完成后提交确认或消费偏移。消费者在副作用完成后、确认前崩溃，消息会再次投递。这样减少丢失，但重复不是偶发异常，而是协议允许的正常结果。

消费者应按业务键实现幂等。简单插入可以使用唯一约束，状态变更可以记录已处理事件标识，累计操作则需要避免重复加总。幂等键的保留期限必须覆盖消息可能重放的最长时间，否则过期后旧消息仍会再次生效。

有些动作天然不幂等，例如发送短信、扣款或调用不支持幂等键的外部接口。可以引入业务状态机、供应商幂等标识、预授权和补偿流程，但不能只在代码外层捕获异常后重试。

消息乱序会进一步复杂化处理。分区通常只在单个分区内保序，扩容、重分配和不同键会形成并发。事件应携带版本或序列，消费者要定义迟到事件是忽略、重算还是补偿。

代理与流处理框架可以在受控范围内把输入偏移、状态更新和输出消息作为一个事务提交，使重启后不会重复产生框架内结果。这是一项有价值的保证，但不是所有外部世界的绝对恰好一次。

当事务输出写入另一个支持同一协议的消息主题时，边界较清晰；写入普通数据库、对象存储或发送邮件时，仍需要跨系统协调。分布式事务可以扩展原子边界，却带来可用性、锁定和运维复杂度，并非所有系统支持。

更准确的说法是“在指定组件、配置和故障条件下实现一次可见效果”。设计文档应写清生产者幂等、代理事务、消费者隔离级别和外部落地策略，而不只标注 exactly-once。

消费者通常按分区读取日志并提交处理位置。先提交偏移再写业务状态会在崩溃时丢失处理；先写业务状态再提交偏移会在崩溃时重复读取。至少一次系统通常选择后者，并依赖幂等消费。

批量提交提高吞吐，但一次失败可能重放整批。批内部分成功时，应能识别已完成项。并行处理还要保证偏移不能越过未完成消息，否则重启后这些消息会被跳过。

长时间处理可能超过消费者会话或租约期限，引起分区转移，旧实例和新实例同时处理。需要延长租约、拆分任务、暂停拉取或采用外部工作队列，而不能假定单线程代码就不会并发。

暂时性故障适合指数退避和抖动，永久性格式错误则应进入隔离队列或人工处理。无限快速重试会阻塞分区、放大依赖压力并增加成本。

死信记录应保留原消息、失败原因、处理版本和重放审计。重放前要确认缺陷已修复以及副作用能否再次执行。跳过错误消息也要有业务授权，因为它可能破坏后续事件的前置状态。

监控应覆盖生产失败、确认延迟、副本状态、消费滞后、重试、重复抑制、死信和端到端业务计数。只看队列深度无法区分消费者慢、分区倾斜还是外部依赖失败。

消息交付语义最终是一组跨边界协议。可靠系统不会追求一个脱离上下文的“一次”，而是明确每个失败窗口，选择可接受的丢失或重复策略，并让业务副作用具有可恢复证据。