流处理架构中反压机制是如何工作的？

27 Haz 00:27

说到反压我特别有感触！之前做物联网数据流项目时，一开始就是因为忽视了反压机制，把消费者的处理速度默认比生产者快，结果 Kafka consumer 直接把集群内存撑满，一堆 OOM 崩溃，线上服务跪了半天才发现。后来加了基于滑动窗口的动态流量控制，消费者用剩余处理能力实时反馈到生产者的 pause/resume API，这才把峰值流量时的内存使用稳定在 60% 以下。 设计反压时有几个坑特别容易踩：第一是流量调节的 granularity，必须根据业务 QPS 和延迟 SLA 来分层，比如高优先级的 alert 数据就不能和普通日志混用同一个反压信号；第二是反馈的粒度不能太粗，否则眨眼间就溢出了，我当时用的就是每 100ms 更新一次 consumer lag，太频繁又影响性能；第三是回退策略，很多系统直接丢消息拉倒，但我们得持久化到本地磁盘再重试，否则就是数据丢失 bug 的温床。这个阶段踩过的坑，现在回头看真的能让人成长不少！