企业级消息系统需兼顾高并发、可靠性、可运维，Kafka适合海量流式场景，RabbitMQ适合强一致性业务；选型看消息量级、顺序性、消费模型、运维成熟度；Python客户端须调优关键参数并实施DLQ、幂等、隔离、监控等防御策略。
Python企业级消息系统不是堆库写 demo，而是围绕高并发、可靠性、可运维三个刚性需求来落地。Kafka 和 RabbitMQ 各有主战场：Kafka 适合日志采集、事件溯源、海量流式数据的吞吐；RabbitMQ 更适合任务调度、订单履约、强路由与事务一致性要求高的业务场景。选对中间件、配对客户端、压住关键参数，才能扛住真实流量。
选型不靠感觉，看这四个硬指标
判断该用 Kafka 还是 RabbitMQ，别只看“听说 Kafka 快”——直接对照业务特征：
- 消息量级 & 延迟容忍：每秒持续 5 万+ 消息、允许毫秒级延迟 → Kafka；每秒几千消息、要求端到端 100ms 内响应 → RabbitMQ 更稳
- 消息顺序性：必须严格保序（如交易流水）→ Kafka 分区 + Key 路由天然支持；RabbitMQ 单队列 FIFO 可保序，但集群下需禁用镜像队列或用 Quorum 队列
- 消费模型：一个消息要被多个系统同时处理（短信、风控、BI）→ Kafka 的 topic 多订阅；一个任务只能被一个 worker 执行（导出报表、发券）→ RabbitMQ 的 queue 点对点更自然
- 运维成熟度：团队熟悉 Docker/K8s、有 Prometheus/Grafana → Kafka 可控；团队偏重快速上线、无专职 MQ 运维 → RabbitMQ 管理界面直观，插件丰富（如 MQTT、STOMP），上手快
RabbitMQ 生产环境必调的三个 Python 参数
用 pika 写消费者，不调参=线上裸奔。以下三处不设好，高峰期必积压：
- prefetch_count = 10~50：限制每个消费者未确认（unack）消息数。设太大（如默认 0）会让慢消费者卡住整个 channel；设太小（如 1）又浪费吞吐。建议从 20 起调，结合平均处理耗时和并发 worker 数反推
- connection heartbeat = 30：启用心跳检测，避免网络闪断导致连接假死。pika 默认 0（禁用），务必显式设为非零值（单位秒）
- queue_declare(durable=True) + basic_publish(delivery_mode=2)：双持久化组合。队列声明加 durable=True，消息发送加 delivery_mode=2，才能保证 broker 重启后消息不丢
Kafka Python 消费者稳定运行的实操要点
用 kafka-python 或 aiokafka，光连上 broker 不代表能扛住生产流量：
立即学习“Python免费学习笔记（深入）”；
- group_id 必须固定且语义清晰：比如 "etl-user-activity-v2"，不能用随机字符串。否则 offset 提交混乱，重复消费或跳过消息
- enable_auto_commit=False，手动 commit：在业务逻辑真正执行成功后调用 consumer.commit()。自动提交可能在处理中途 crash 导致消息丢失
- 批量拉取 + 异步处理：设置 max_poll_records=500，用 asyncio.create_task 并发处理每条消息，再统一 await 批次完成。比单条串行快 3~5 倍
- 监控 consumer lag：用 kafka-consumer-groups.sh 或 Python 调用 AdminClient 查 lag。超过 10 万条就该扩容 consumer 实例或优化处理逻辑
高并发下的共性防御策略
无论用哪个中间件，以下四件事必须做：
- 死信队列（DLQ）兜底：RabbitMQ 配置 x-dead-letter-exchange；Kafka 将失败消息写入专用 topic（如 "dlq-order-error"），并接入告警
- 幂等写入前置：在消费逻辑最开头校验 message_id 或业务唯一键（如 order_no + event_type）。数据库加唯一索引，或 Redis SETNX 记录已处理 ID
- 连接与资源隔离：不同业务域用独立 vhost（RabbitMQ）或独立 topic/group（Kafka）；Python 进程内用 connection pool，避免每次新建连接
- 可观测性闭环：暴露关键指标（队列长度、消费延迟、错误率）到 Prometheus；Grafana 做看板；超阈值自动触发企业微信/钉钉告警
