消息队列用着用着，最常见的问题是"消费者跟不上——积压掉到天荒地老、或消费在崩溃重连里空转"：生产端进来了几千条/秒，消费端却一个个慢吞吞、还叠加重试与死信，延迟越堆越高。消息积压与消费吞吐治理解决"让消费端跟得上生产端"：把吞吐瓶颈拆清楚（是网络/网络 rp...

当自托管的"事件流"多起来——业务日志、埋点、告警、数据库变更、各类"要广播给多套处理系统"的实时消息——用"点对点消息队列"（前文 RabbitMQ 那一类）会显得不够：它擅长"把一条消息交给一个消费者消费掉"，但扛不住"同一份数据要被多个团队/多套系统反复...