北京
凌晨三点的告警群里，有人贴出一张延迟曲线图。数据流处理系统的"实时"承诺，正在吃掉工程师的睡眠。
事件现场：一次典型的深夜救火
某团队用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当成奢侈品而非必需品——你的告警群会安静很多。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
