凌晨三点的告警群里，有人贴出一张延迟曲线图。数据流处理系统的"实时"承诺，正在吃掉工程师的睡眠。

事件现场：一次典型的深夜救火

打开网易新闻 查看精彩图片

某团队用Spark Streaming做实时推荐，延迟指标漂亮，但用户投诉推荐结果"慢半拍"。排查发现：系统为了保证exactly-once语义，在故障恢复时重放了三小时数据。实时？确实实时。正确？也正确。用户体验？崩了。

打开网易新闻 查看精彩图片

这不是个案。Kafka和Spark这类系统的设计哲学，正在制造一种隐蔽的技术债。

时间线：正确性如何变成性能杀手

2010年代，流处理系统开始承诺"exactly-once"——每条消息只处理一次，不丢不重。实现这个需要记录偏移量、做事务协调、维护状态快照。Kafka用幂等生产者和事务API，Spark用微批+检查点。

代价逐渐暴露。exactly-once的延迟通常在数百毫秒到秒级。对比at-least-once的毫秒级延迟，差距不是倍数，是数量级。

更隐蔽的是故障恢复。一次broker重启，事务协调器需要重建状态。某生产环境实测：10万TPS的场景下，exactly-once恢复时间比at-least-once慢40倍。

打开网易新闻 查看精彩图片

关键节点：2024年的转折点

越来越多团队开始分层设计。金融交易用exactly-once，日志监控用at-least-once，推荐系统用at-most-once。 correctness变成可配置项，而非默认强制。

Redis Streams、Pulsar的架构演进也印证这个趋势：把一致性级别暴露给用户，而不是替用户做决定。

启示：重新理解"实时"的定义

技术选型时，先问业务能容忍什么，再问系统能提供什么。延迟、正确性、成本，这个三角没有免费午餐。下次设计架构时，把exactly-once当成奢侈品而非必需品——你的告警群会安静很多。