YangChingyuk的博客

生产端：为所有需要保证顺序的消息指定相同的Key。这样它们会被发送到同一个Partition。Topic设置：设置该Topic只有1个分区（Partition）。这是最严格但也性能最低的方案，通常只用于极端场景。更常见的做法是使用多个分区，但通过Key将需要顺序处理的消息路由到同一个分区。消费端：确保消费该Topic的Consumer Group里，只有一个Consumer实例在消费这个特定的Partition。（Kafka的Rebalance机制会自动处理这一点，你无需手动干预）。

图片代码消费者拒绝TTL过期队列满监控DLQ深度分析死信原因检查消费者日志/错误调整TTL或处理逻辑扩容消费者或削峰C/F/G修复代码安全重试消息确认业务恢复。1.​独立消费者组​DLQ 消费者需与主业务隔离（避免占用正常资源）3.​熔断机制​若重试成功率 < 10%，暂停重试并发出告警。2.​闭环处理​：分析 → 修复 → 重试 → 验证。1.​监控先行​：DLQ 深度 >0 即告警。3.​安全重试​：渐进延时 + 重试次数控制。4.​防止污染​：隔离 DLQ 消费者资源。步骤 4：安全重试（3种方案）

Quorum队列通过Raft协议实现多数派复制和自动故障转移，以强一致性为核心牺牲部分灵活性与低延迟，成为RabbitMQ高可用的首选方案。实际部署时需注意副本数配置（推荐奇数节点）、内存监控及业务场景匹配性，避免误用导致性能瓶颈。

​总结​：Kafka 以持久化日志为核心，通过分布式分区、副本机制、零拷贝优化实现高吞吐与高可靠。新版本通过 ​KRaft 去 Zookeeper化进一步简化运维，使其在流处理生态中的地位更加稳固。1.​高吞吐量 (High Throughput)​​。​总结：Kafka 消息问题解决矩阵​。1.​Kafka 内部机制​。​三、消息重复消费问题​。​一、消息顺序性问题​。​二、消息不丢失问题​。​六、架构级容灾设计​。​四、消息堆积问题​。​五、消息延迟问题​。1.​生产者批处理​。