很多接入系统一出数据丢失排查到最后日志里通常都能看到一行很刺眼的话ACK 已返回。发送端看到 ACK以为数据进来了接收端也觉得自己“处理成功”了。可隔半小时去查消息队列、查数据库、翻磁盘目录数据就是没了。问题恰恰出在这儿ACK 从来不等于“收到”它只等于“对方承诺到了某个状态”。这个“某个状态”如果没有提前定义系统量一上来丢数据、重数据、延迟飙升基本总得撞上一样。我做数据管线这些年见过太多系统把确认时机写成一句很轻飘的话——“处理完成后返回 ACK”。这句话放在 PRD 里没毛病落到代码里就麻烦了什么算处理完成数据进了内存算不算写入操作系统页缓存算不算Kafka leader 收到算不算数据库INSERT返回算不算每一层的答案都不一样。先把四种“收到”分开先说一个容易混淆的点TCP 层的 ACK不是应用层的 ACK。TCP ACK 只说明一件事**对端内核已经收到了这个网络包并且按序放进了接收缓冲区。**它不说明业务程序已经read()更不说明数据写进了磁盘、消息队列或数据库。所以你看到发送端的 TCP 连接稳定、重传率很低最多只能证明网络传输这一段没出大问题。后面那几十行业务逻辑TCP 根本管不着。往下拆一层看一个实时数据接入系统里常见的“收到”至少有四种数据到了服务进程内存应用程序从 Socket、HTTP 请求或 RPC 流里读到了数据反序列化完成准备处理。数据写入了操作系统缓存程序调用write()成功内核把数据放进 Page Cache。这个阶段通常很快但机器断电或内核崩溃时数据不一定已经落盘。数据进入了可恢复存储例如调用fsync()后写入本地磁盘或者写进具有持久化能力的消息队列日志。数据完成了业务提交例如数据库事务提交成功且必要的副本、索引、下游事件都处在符合业务要求的状态。这四个状态延迟和可靠性差得不是一点半点。只要 ACK 的含义没写清发送端和接收端其实是在拿不同的尺子量“成功”。最危险的确认数据刚进内存就回 ACK最常见的实现是这样的接收数据 → 放入内存队列 → 返回 ACK → 异步写 Kafka / 磁盘 / 数据库它的优点很明显快。网络一到马上确认发送端不用堵着等接收端的吞吐也能拉高。问题也很明显内存不是恢复点。假设服务刚返回 ACK数据还躺在内存队列里进程 OOM 了、机器重启了、容器被调度走了或者部署时有人手快滚了一版这批数据就没了。发送端因为已经收到了 ACK不会再重发。完了。2022 年我还在做数据平台时接过一类典型的新闻信源接入上游通过长连接推送增量内容接收端先把消息塞进本地内存 Channel再由消费者批量写入 Kafka。正常情况下跑得飞快压测曲线也很好看。后来有一次消费者卡住内存堆积服务被 OOM Killer 干掉。上游那边早就拿到了 ACK重连之后从最新 offset 继续推中间那一段消息没人补得回来。桌上那杯美式已经凉了工单系统红点还在往上跳。这类设计不是不能用只不过它适合的场景很窄**允许少量丢失且更看重低延迟和高吞吐。**比如部分监控指标、点击流采样、调试日志。你得先承认它会丢再谈怎么把丢失控制在可接受范围内。不能一边说“实时”一边默认“可靠”。写进本地磁盘也不一定真落盘很多人意识到内存不可靠后会改成接收数据 → 写本地文件 → 返回 ACK → 异步上传或消费这比纯内存强但这里还有一个坑write()成功不代表数据已经写到了物理磁盘。在 Linux 里普通文件写入通常先进 Page Cache。内核会择机把脏页刷到磁盘时间取决于系统状态、参数和负载。程序拿到“写成功”的返回值实际上只是把数据交给了操作系统。如果你的确认语义是“机器掉电后也必须能恢复”那就需要更强的边界写入本地 WAL / Append-only Log → fsync 或 fdatasync → 返回 ACK这时 ACK 的含义才可以写成该记录已持久化到本机可恢复日志中即使进程重启可以通过日志重放恢复。代价也很实在fsync会拖高尾延迟还可能把磁盘 IOPS 打满。单条数据来一条刷一次盘吞吐通常很难看按时间窗口或按批次 group commit吞吐会好很多但每条消息要多等一个批次窗口。这就是确认策略的第一条原则ACK 不能脱离恢复点谈。你准备从哪里恢复ACK 就至少要晚于哪里。消息队列确认别只看“写进去了”接入层用消息队列做缓冲很常见尤其是 Kafka、Pulsar 这类可持久化日志系统。常见链路会变成发送端 → 接入服务 → 消息队列 → 消费者 → 数据库 / 检索系统 / 对象存储这时要先问清楚ACK 是由谁返回的如果接入服务把消息交给 Producer 就立刻确认Producer 还没拿到 Broker 的响应那只是“准备发送”不算持久化。如果 Broker leader 收到数据后就确认那么 leader 宕机、而副本还没同步完成时已经返回 ACK 的消息仍可能丢。如果等 ISR 副本集合满足要求后再确认可靠性上来了延迟也会上去吞吐还会受副本同步速度影响。所以队列层的 ACK通常要拆成两层看Producer ACK消息是否已经按设定的副本策略写入 BrokerConsumer ACK / Offset Commit消费者是否已经把这条消息处理到可以安全跳过的程度。第二层更容易写错。消费者从 Kafka 拿到一条消息后如果先提交 offset再写数据库消费消息 → 提交 offset → 写数据库中间只要数据库写失败或进程崩溃消息在队列看来已经消费过了数据就丢了。反过来如果先写数据库再提交 offset消费消息 → 写数据库 → 提交 offset中间如果数据库写成功、offset 还没提交进程崩了重启后会重复消费。这地方很多人踩坑——**先提交容易丢后提交容易重。**二选一时绝大多数业务宁愿接受重复也不该接受悄悄丢失。原因不复杂重复是可以设计处理掉的丢失往往连补都没法补。At-least-once 不高级但往往更诚实很多系统设计文档喜欢写“Exactly-once”看上去很稳。实际工程里端到端的 Exactly-once 比想象中难得多。你想想一条数据可能经过接入服务、消息队列、多个消费者、数据库、对象存储和下游回调。只要其中两个系统没有共享事务就会遇到经典问题数据库提交成功了但消息确认没发出去算成功还是失败这不是多加一个try-catch就能解决的。实际工程里更常见、也更靠谱的路线是传输层做到 at-least-once业务层通过幂等把重复收敛掉。也就是允许发送端因为超时、断连、重试而重复发允许消费者因为崩溃恢复而重复处理但保证同一条业务事件重复到达时最终状态不被重复污染。幂等不是一句“数据库加唯一索引”就结束了不过唯一索引确实是最常用的底座。一条进入系统的数据最好从源头就带上稳定的事件 ID例如event_id source_id source_sequence或者由发送方生成全局唯一 ID。关键不在于 UUID 长什么样而在于同一个业务事件重试十次ID 必须还是同一个。数据库侧可以这样处理INSERTINTOingest_event(event_id,source_id,payload,received_at)VALUES(?,?,?,NOW())ONCONFLICT(event_id)DONOTHING;如果重复写入数据库不新增记录如果后续还有聚合、计费、状态流转也要保证这些操作基于同一个幂等键而不是每收到一次就加一次。这里有个常被忽略的问题有些业务的“重复”不是完全相同的数据。比如同一个订单 ID 先推送“已创建”后推送“已支付”再因为网络重试把“已创建”重发一次。你不能只按订单 ID 去重否则会把合法状态更新一起吞掉。这种场景更适合用业务主键 事件版本号业务主键 单调递增序列业务主键 状态机约束业务主键 更新时间与条件更新。说白了幂等的对象不是“这条 JSON”而是“这次业务状态变化”。崩溃恢复才是 ACK 语义的验收题一个确认策略靠不靠谱不要只看压测吞吐拿下面几个问题过一遍更有用ACK 返回后进程立刻崩溃数据还能找到吗ACK 返回后机器掉电数据还能恢复吗消费者处理成功但没提交位点重复执行会怎样数据库事务提交成功、回执丢失发送端重试会怎样同一条消息在不同分区、不同节点乱序到达会不会覆盖正确状态灰度发布时老版本和新版本对同一事件的解析规则不一致会不会制造重复或丢失这几道题过不去文档里写再多“高可用”“最终一致性”都没意义。我自己更偏向把接入系统拆成两个明确阶段阶段一可恢复接收 接收数据 → 写入持久化日志或可靠消息队列 → 返回接收 ACK 阶段二业务处理 消费持久化事件 → 幂等写入业务存储 → 提交消费进度 / 返回处理 ACK第一阶段只承诺“我不会把这条数据弄丢”第二阶段才承诺“它已经被业务系统正确处理”。这两个 ACK 不要混。尤其是对外接口最好把状态名称写得直白一点ACCEPTED已被接收等待处理PERSISTED已写入可恢复存储PROCESSED业务处理完成FAILED_RETRYABLE暂时失败可重试FAILED_FINAL不可恢复失败需要人工或业务侧处理。别全都叫successtrue。后面排障时你会感谢当初多写的这几个字。不同业务确认点应该不一样没有一个放之四海而皆准的 ACK 时机。确认得越早吞吐通常越好确认得越晚丢失窗口越小。该怎么选得看数据价值、可重放能力、时延预算和重复成本。场景推荐确认点可接受语义重点防什么调试日志、低价值埋点入内存队列或批量写队列后可少量丢失防止队列无限堆积监控指标、时序数据本地 WAL 或消息队列持久化后At-least-once防止批量丢失和时间乱序爬虫原始抓取结果对象存储或消息队列持久化后At-least-once 去重防止重复抓取、重复落库订单、支付、计费事件多副本持久化后业务侧幂等提交强 at-least-once防止静默丢单设备控制、任务下发设备明确执行并回传状态后命令确认与执行确认分离防止“已接收但未执行”金融、审计、合规记录不可篡改日志持久化并完成必要副本后可追溯、可重放防止数据缺口与证据链断裂表里最容易被忽略的是“设备控制、任务下发”。比如你给某个采集节点下了一条“停止任务”的命令节点 TCP 收到了不代表任务已经停节点把命令写进本地队列也不代表执行器已经消费执行器消费了还不代表相关资源已经释放。这种场景至少要区分命令已接收 → 命令已持久化 → 命令已开始执行 → 命令执行完成把第一个状态当成最后一个状态生产环境迟早要还债。最后给一套能落地的判断方法如果你正在设计一个新的数据接入接口我建议别先问“什么时候返回 ACK”先按下面四件事把边界写出来这条数据丢了能不能补能从上游重放就可以接受较早 ACK不能补就至少确认到可恢复存储。这条数据重复了业务会不会出事会重复扣费、重复通知、重复执行的必须把幂等键、状态机或去重窗口设计在确认逻辑前面。真正的恢复点在哪里是本地 WAL、Kafka 多副本、数据库事务还是对象存储不要把“进入内存”误当成恢复点。调用方到底需要知道什么它需要的是“系统已收到”还是“业务已处理完成”这两个承诺不能用一个模糊的 ACK 混过去。ACK 本质上不是网络报文也不是一个 HTTP 200。它是一份承诺从这个时刻开始这条数据的责任由谁承担出了故障以后靠什么恢复重复来了又怎么处理。把这份承诺写清楚系统才算真的接住了数据。否则“收到”两个字很多时候只是把数据丢失的时间往后推了几分钟。