消息队列集成：Python + Kafka/RabbitMQ 生产实践

文章目录

• • 一、消息队列的四大工程价值
  • • [1.1 解耦：消除服务间的直接依赖](#1.1 解耦：消除服务间的直接依赖)
    • [1.2 削峰：缓冲突发流量](#1.2 削峰：缓冲突发流量)
    • [1.3 异步：将慢操作移出主链路](#1.3 异步：将慢操作移出主链路)
    • [1.4 可靠投递：失败不丢消息](#1.4 可靠投递：失败不丢消息)
  • [二、RabbitMQ 核心概念与 Python 生产实践](#二、RabbitMQ 核心概念与 Python 生产实践)
  • • [2.1 核心概念：Exchange、Queue 与 Binding](#2.1 核心概念：Exchange、Queue 与 Binding)
    • [2.2 pika 客户端实战：连接管理与生产级消费](#2.2 pika 客户端实战：连接管理与生产级消费)
    • [2.3 消息可靠性三件套](#2.3 消息可靠性三件套)
    • [2.4 死信队列：异常消息的隔离与重试](#2.4 死信队列：异常消息的隔离与重试)
  • [三、Kafka 核心概念与 Python 生产实践](#三、Kafka 核心概念与 Python 生产实践)
  • • [3.1 核心概念：Topic、Partition 与 Consumer Group](#3.1 核心概念：Topic、Partition 与 Consumer Group)
    • [3.2 confluent-kafka-python 实战：生产者与消费者](#3.2 confluent-kafka-python 实战：生产者与消费者)
    • [3.3 消息顺序性：Partition 级别的顺序保证](#3.3 消息顺序性：Partition 级别的顺序保证)
  • [四、RabbitMQ vs Kafka：量化选型决策](#四、RabbitMQ vs Kafka：量化选型决策)
  • 五、生产实战：订单系统异步通知链路
  • • [5.1 场景设计](#5.1 场景设计)
    • [5.2 生产者代码](#5.2 生产者代码)
    • [5.3 消费者代码：库存扣减服务](#5.3 消费者代码：库存扣减服务)
    • [5.4 消费者代码：短信通知服务](#5.4 消费者代码：短信通知服务)
  • 六、小结

在用户注册完成后，系统通常需要执行发送欢迎邮件、推送短信验证码、初始化用户画像缓存等一系列操作。若采用同步串行处理，主流程必须等待所有附属任务完成后才能返回 HTTP 响应。在实际业务中，这种设计往往导致接口延迟从 200ms 膨胀到 3 秒以上，严重影响终端体验。消息队列的价值在于将这些与主流程非强耦合的任务剥离为异步处理，在保障可靠性的同时，将接口响应时间控制在百毫秒级别。

---

一、消息队列的四大工程价值

消息队列并非简单的"异步工具箱"，其引入对系统架构产生的是结构性影响。下面从四个维度阐述其工程价值，并给出引入前后的代码形态对比。

1.1 解耦：消除服务间的直接依赖

在耦合架构中，订单服务需要直接调用库存服务、支付服务、物流服务的 HTTP 接口。一旦库存服务升级接口签名，订单服务必须同步修改代码并重新部署。

引入消息队列后，订单服务仅需将"订单已创建"事件投递到队列，下游服务各自订阅感兴趣的事件主题。接口变更的影响范围被限制在单个服务内部，服务间的通信契约从"方法签名"降级为"消息格式"，系统的可维护性明显提升。

1.2 削峰：缓冲突发流量

电商大促期间，订单流量可能在 10 秒内从日常 100 QPS 暴涨至 10,000 QPS。若直接冲击数据库，连接池瞬间耗尽将导致全站崩溃。

消息队列作为流量蓄水池，允许生产者以峰值速率写入，而消费者按照自己的处理能力匀速消费。这种"漏斗效应"使得后端服务无需按峰值容量扩容，通常可节省 60% 以上的基础设施成本。

1.3 异步：将慢操作移出主链路

视频转码、PDF 生成、第三方 API 调用等耗时操作（通常在秒级甚至分钟级）若阻塞在主流程中，会导致 HTTP 连接长时间占用，极易触发网关超时。

通过将任务描述投递到队列，主流程立即返回"任务已提交"状态，消费者进程在后台完成实际工作。前端可通过轮询或 WebSocket 获取最终执行结果，用户体验从"长时间白屏等待"转变为"即时响应 + 渐进式结果展示"。

1.4 可靠投递：失败不丢消息

在直接 HTTP 调用的模型中，若下游服务暂时不可用，调用方通常面临两难选择：无限重试可能导致级联阻塞，不重试则直接丢失业务事件。

消息队列通过持久化存储、发布确认（Publisher Confirm）和消费确认（Consumer Ack）机制，确保消息在消费者成功处理前不会从系统中消失。即使下游服务宕机数小时，消息依然安全地保存在磁盘上，待服务恢复后继续处理。

---

二、RabbitMQ 核心概念与 Python 生产实践

RabbitMQ 基于 AMQP 协议实现，其核心设计思想是将消息路由的复杂性集中在 Broker 侧，生产者只需将消息发送到交换机（Exchange），由交换机根据绑定规则（Binding）将消息分发到对应的队列（Queue）。这种设计使得路由策略的调整无需改动生产者代码。

2.1 核心概念：Exchange、Queue 与 Binding

RabbitMQ 的消息流转路径为：Producer → Exchange → (Binding + Routing Key) → Queue → Consumer。

Exchange 承担"分拣中心"的角色，支持四种路由策略：

Exchange 类型	路由规则	典型场景
direct	Routing Key 与 Binding Key 精确匹配	点对点任务分发，如单用户通知
topic	Routing Key 按通配符匹配（# 匹配多级，* 匹配单级）	日志分类路由，如 order.created.success
fanout	忽略 Routing Key，广播到所有绑定队列	全局配置下发、缓存失效广播
headers	匹配消息头属性而非 Routing Key	多维度属性过滤，如按设备类型 + 地区路由

#mermaid-svg-iWi1XX7hfbNML8sc{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-iWi1XX7hfbNML8sc .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-iWi1XX7hfbNML8sc .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-iWi1XX7hfbNML8sc .error-icon{fill:#552222;}#mermaid-svg-iWi1XX7hfbNML8sc .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-iWi1XX7hfbNML8sc .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-iWi1XX7hfbNML8sc .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-iWi1XX7hfbNML8sc .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-iWi1XX7hfbNML8sc .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-iWi1XX7hfbNML8sc .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-iWi1XX7hfbNML8sc .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-iWi1XX7hfbNML8sc .marker{fill:#333333;stroke:#333333;}#mermaid-svg-iWi1XX7hfbNML8sc .marker.cross{stroke:#333333;}#mermaid-svg-iWi1XX7hfbNML8sc svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-iWi1XX7hfbNML8sc p{margin:0;}#mermaid-svg-iWi1XX7hfbNML8sc .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-iWi1XX7hfbNML8sc .cluster-label text{fill:#333;}#mermaid-svg-iWi1XX7hfbNML8sc .cluster-label span{color:#333;}#mermaid-svg-iWi1XX7hfbNML8sc .cluster-label span p{background-color:transparent;}#mermaid-svg-iWi1XX7hfbNML8sc .label text,#mermaid-svg-iWi1XX7hfbNML8sc span{fill:#333;color:#333;}#mermaid-svg-iWi1XX7hfbNML8sc .node rect,#mermaid-svg-iWi1XX7hfbNML8sc .node circle,#mermaid-svg-iWi1XX7hfbNML8sc .node ellipse,#mermaid-svg-iWi1XX7hfbNML8sc .node polygon,#mermaid-svg-iWi1XX7hfbNML8sc .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-iWi1XX7hfbNML8sc .rough-node .label text,#mermaid-svg-iWi1XX7hfbNML8sc .node .label text,#mermaid-svg-iWi1XX7hfbNML8sc .image-shape .label,#mermaid-svg-iWi1XX7hfbNML8sc .icon-shape .label{text-anchor:middle;}#mermaid-svg-iWi1XX7hfbNML8sc .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-iWi1XX7hfbNML8sc .rough-node .label,#mermaid-svg-iWi1XX7hfbNML8sc .node .label,#mermaid-svg-iWi1XX7hfbNML8sc .image-shape .label,#mermaid-svg-iWi1XX7hfbNML8sc .icon-shape .label{text-align:center;}#mermaid-svg-iWi1XX7hfbNML8sc .node.clickable{cursor:pointer;}#mermaid-svg-iWi1XX7hfbNML8sc .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-iWi1XX7hfbNML8sc .arrowheadPath{fill:#333333;}#mermaid-svg-iWi1XX7hfbNML8sc .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-iWi1XX7hfbNML8sc .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-iWi1XX7hfbNML8sc .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-iWi1XX7hfbNML8sc .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-iWi1XX7hfbNML8sc .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-iWi1XX7hfbNML8sc .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-iWi1XX7hfbNML8sc .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-iWi1XX7hfbNML8sc .cluster text{fill:#333;}#mermaid-svg-iWi1XX7hfbNML8sc .cluster span{color:#333;}#mermaid-svg-iWi1XX7hfbNML8sc div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-iWi1XX7hfbNML8sc .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-iWi1XX7hfbNML8sc rect.text{fill:none;stroke-width:0;}#mermaid-svg-iWi1XX7hfbNML8sc .icon-shape,#mermaid-svg-iWi1XX7hfbNML8sc .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-iWi1XX7hfbNML8sc .icon-shape p,#mermaid-svg-iWi1XX7hfbNML8sc .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-iWi1XX7hfbNML8sc .icon-shape .label rect,#mermaid-svg-iWi1XX7hfbNML8sc .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-iWi1XX7hfbNML8sc .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-iWi1XX7hfbNML8sc .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-iWi1XX7hfbNML8sc :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} direct: key=order
topic: order.*
fanout
headers: device=ios
Producer
Exchange
Queue: billing
Queue: analytics
Queue: cache-invalidation
Queue: push-ios
Consumer
Consumer
Consumer
Consumer

上图展示了四种 Exchange 类型在同一条消息流中的不同分发行为。在实际部署中，一个 Exchange 通常只配置一种类型，这里为了对比将它们绘制在一起。

2.2 pika 客户端实战：连接管理与生产级消费

pika 是 RabbitMQ 官方推荐的 Python 客户端。生产环境中，连接管理需要特别关注心跳机制（Heartbeat）和自动重连。

import pika
import json
from typing import Callable

class RabbitMQClient:
    def __init__(self, amqp_url: str):
        params = pika.URLParameters(amqp_url)
        # 心跳间隔：服务端与客户端每 30 秒互相探测一次
        params.heartbeat = 30
        # 阻塞连接超时：建立 TCP 连接的最大等待时间
        params.blocked_connection_timeout = 10
        self.connection = pika.BlockingConnection(params)
        self.channel = self.connection.channel()

    def publish(self, exchange: str, routing_key: str, body: dict):
        message = json.dumps(body, ensure_ascii=False)
        self.channel.basic_publish(
            exchange=exchange,
            routing_key=routing_key,
            body=message.encode("utf-8"),
            properties=pika.BasicProperties(
                delivery_mode=2,  # 持久化消息
                content_type="application/json",
            ),
        )

    def consume(self, queue: str, callback: Callable):
        self.channel.basic_qos(prefetch_count=10)  # 公平分发，避免单消费者积压
        self.channel.basic_consume(queue=queue, on_message_callback=callback)
        self.channel.start_consuming()

上述代码中，prefetch_count=10 是一个关键参数。默认情况下，RabbitMQ 会将队列中的所有消息一次性推送给消费者，若某个消费者处理缓慢，将导致其本地缓存大量消息，而其他空闲消费者却无消息可处理。basic_qos 限制了每个消费者在未返回 ACK 前最多接收 10 条消息，实现了负载的动态均衡。

2.3 消息可靠性三件套

生产环境对消息可靠性的要求远高于演示场景。RabbitMQ 提供了三层保障机制：

持久化（Delivery Mode = 2）

默认情况下，消息仅存储在内存中，Broker 重启后消息全部丢失。将 delivery_mode 设为 2，消息在入队的同时写入磁盘。需要注意的是，持久化消息的性能开销约为非持久化的 5~10 倍，建议在关键业务（如订单、支付）中启用，日志类非关键消息可保持默认。

发布确认（Publisher Confirms）

basic_publish 默认是"发射后不管"模式，生产者无法得知消息是否真正到达 Exchange。开启 Publisher Confirms 后，Broker 会在消息成功路由到队列后返回 Basic.Ack，或在路由失败时返回 Basic.Nack。

self.channel.confirm_delivery()
try:
    self.channel.basic_publish(exchange="", routing_key="task_queue", body=b"data")
    print("消息已被 Broker 确认接收")
except pika.exceptions.UnroutableError:
    print("消息路由失败，需执行补偿逻辑")

手动 ACK（Auto Ack = False）

自动确认模式下，消息一旦推送给消费者即被删除。若消费者在处理过程中崩溃，消息将永久丢失。手动确认要求消费者在业务逻辑完全执行成功后，显式调用 basic_ack。

def callback(ch, method, properties, body):
    try:
        process_message(body)
        ch.basic_ack(delivery_tag=method.delivery_tag)
    except Exception:
        # 拒绝消息并重新入队，供其他消费者或本消费者重试
        ch.basic_nack(delivery_tag=method.delivery_tag, requeue=True)

2.4 死信队列：异常消息的隔离与重试

在生产环境中，消费者因代码 Bug、下游服务超时或数据格式异常导致消息处理失败是不可避免的。若简单地无限重试，失败消息将阻塞队列，导致后续正常消息无法被处理。

死信队列（Dead Letter Queue, DLQ）机制的核心思想是：为原始队列设置"死信交换机"（Dead Letter Exchange, DLX），当消息满足以下任一条件时，自动将其路由到 DLQ：

1. 消息被消费者 basic_reject 或 basic_nack 且 requeue=False
2. 消息在队列中存活时间超过 TTL（Time-To-Live）
3. 队列达到最大长度限制，新消息挤掉最旧消息

#mermaid-svg-1NmxfGoXO4oSuTTE{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-1NmxfGoXO4oSuTTE .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-1NmxfGoXO4oSuTTE .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-1NmxfGoXO4oSuTTE .error-icon{fill:#552222;}#mermaid-svg-1NmxfGoXO4oSuTTE .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-1NmxfGoXO4oSuTTE .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-1NmxfGoXO4oSuTTE .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-1NmxfGoXO4oSuTTE .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-1NmxfGoXO4oSuTTE .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-1NmxfGoXO4oSuTTE .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-1NmxfGoXO4oSuTTE .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-1NmxfGoXO4oSuTTE .marker{fill:#333333;stroke:#333333;}#mermaid-svg-1NmxfGoXO4oSuTTE .marker.cross{stroke:#333333;}#mermaid-svg-1NmxfGoXO4oSuTTE svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-1NmxfGoXO4oSuTTE p{margin:0;}#mermaid-svg-1NmxfGoXO4oSuTTE .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-1NmxfGoXO4oSuTTE .cluster-label text{fill:#333;}#mermaid-svg-1NmxfGoXO4oSuTTE .cluster-label span{color:#333;}#mermaid-svg-1NmxfGoXO4oSuTTE .cluster-label span p{background-color:transparent;}#mermaid-svg-1NmxfGoXO4oSuTTE .label text,#mermaid-svg-1NmxfGoXO4oSuTTE span{fill:#333;color:#333;}#mermaid-svg-1NmxfGoXO4oSuTTE .node rect,#mermaid-svg-1NmxfGoXO4oSuTTE .node circle,#mermaid-svg-1NmxfGoXO4oSuTTE .node ellipse,#mermaid-svg-1NmxfGoXO4oSuTTE .node polygon,#mermaid-svg-1NmxfGoXO4oSuTTE .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-1NmxfGoXO4oSuTTE .rough-node .label text,#mermaid-svg-1NmxfGoXO4oSuTTE .node .label text,#mermaid-svg-1NmxfGoXO4oSuTTE .image-shape .label,#mermaid-svg-1NmxfGoXO4oSuTTE .icon-shape .label{text-anchor:middle;}#mermaid-svg-1NmxfGoXO4oSuTTE .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-1NmxfGoXO4oSuTTE .rough-node .label,#mermaid-svg-1NmxfGoXO4oSuTTE .node .label,#mermaid-svg-1NmxfGoXO4oSuTTE .image-shape .label,#mermaid-svg-1NmxfGoXO4oSuTTE .icon-shape .label{text-align:center;}#mermaid-svg-1NmxfGoXO4oSuTTE .node.clickable{cursor:pointer;}#mermaid-svg-1NmxfGoXO4oSuTTE .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-1NmxfGoXO4oSuTTE .arrowheadPath{fill:#333333;}#mermaid-svg-1NmxfGoXO4oSuTTE .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-1NmxfGoXO4oSuTTE .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-1NmxfGoXO4oSuTTE .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-1NmxfGoXO4oSuTTE .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-1NmxfGoXO4oSuTTE .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-1NmxfGoXO4oSuTTE .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-1NmxfGoXO4oSuTTE .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-1NmxfGoXO4oSuTTE .cluster text{fill:#333;}#mermaid-svg-1NmxfGoXO4oSuTTE .cluster span{color:#333;}#mermaid-svg-1NmxfGoXO4oSuTTE div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-1NmxfGoXO4oSuTTE .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-1NmxfGoXO4oSuTTE rect.text{fill:none;stroke-width:0;}#mermaid-svg-1NmxfGoXO4oSuTTE .icon-shape,#mermaid-svg-1NmxfGoXO4oSuTTE .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-1NmxfGoXO4oSuTTE .icon-shape p,#mermaid-svg-1NmxfGoXO4oSuTTE .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-1NmxfGoXO4oSuTTE .icon-shape .label rect,#mermaid-svg-1NmxfGoXO4oSuTTE .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-1NmxfGoXO4oSuTTE .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-1NmxfGoXO4oSuTTE .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-1NmxfGoXO4oSuTTE :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} publish
consume
处理成功
处理失败
重试次数耗尽
定时巡检
修复后
Producer
原始队列

max_retries=3
Consumer
ACK 删除
NACK requeue=True
死信交换机
死信队列
人工/自动排查
重新投递

上图展示了一个完整的死信处理链路。在该链路中，原始队列通过 x-dead-letter-exchange 参数绑定 DLX。消费者在捕获到业务异常后，可以选择将消息重新入队（requeue=True）进行有限次重试。当重试次数达到上限（可通过消息头自定义计数），消费者以 requeue=False 拒绝消息，消息自动进入 DLQ。运维人员通过监控 DLQ 长度发现异常，修复问题后将消息重新投递回原始队列处理。

# 声明死信交换机和死信队列
self.channel.exchange_declare(exchange="dlx.orders", exchange_type="direct")
self.channel.queue_declare(queue="dlq.orders", durable=True)
self.channel.queue_bind(queue="dlq.orders", exchange="dlx.orders", routing_key="failed")

# 声明原始队列并绑定死信交换机
args = {
    "x-dead-letter-exchange": "dlx.orders",
    "x-dead-letter-routing-key": "failed",
    "x-message-ttl": 300000,  # 消息在队列中最多停留 5 分钟
}
self.channel.queue_declare(queue="orders.main", durable=True, arguments=args)

---

三、Kafka 核心概念与 Python 生产实践

Kafka 的设计哲学与 RabbitMQ 截然不同。RabbitMQ 以消息为中心，强调路由灵活性和低延迟；Kafka 则以日志为中心，将消息视为不可变的追加日志，通过分区和消费者组实现高吞吐和水平扩展。

3.1 核心概念：Topic、Partition 与 Consumer Group

Topic 与 Partition

Topic 是消息的逻辑分类，而 Partition 是 Topic 的物理分片。每个 Partition 是一个有序的、不可变的消息序列，新消息总是追加到 Partition 的末尾。Partition 的数量决定了 Topic 的并行度上限：若一个 Topic 有 4 个 Partition，则同一消费者组内最多只能有 4 个消费者并行消费。

Consumer Group

消费者组是 Kafka 实现横向扩展的核心机制。一个 Consumer Group 订阅一个 Topic 后，组内的消费者会自动协商 Partition 的分配关系，确保每个 Partition 在同一时刻只被组内的一个消费者消费。当消费者数量小于 Partition 数量时，部分消费者会处理多个 Partition；当消费者数量大于 Partition 数量时，多余的消费者将处于空闲状态。
#mermaid-svg-B7YXUZwJCPrn3ugG{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-B7YXUZwJCPrn3ugG .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-B7YXUZwJCPrn3ugG .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-B7YXUZwJCPrn3ugG .error-icon{fill:#552222;}#mermaid-svg-B7YXUZwJCPrn3ugG .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-B7YXUZwJCPrn3ugG .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-B7YXUZwJCPrn3ugG .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-B7YXUZwJCPrn3ugG .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-B7YXUZwJCPrn3ugG .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-B7YXUZwJCPrn3ugG .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-B7YXUZwJCPrn3ugG .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-B7YXUZwJCPrn3ugG .marker{fill:#333333;stroke:#333333;}#mermaid-svg-B7YXUZwJCPrn3ugG .marker.cross{stroke:#333333;}#mermaid-svg-B7YXUZwJCPrn3ugG svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-B7YXUZwJCPrn3ugG p{margin:0;}#mermaid-svg-B7YXUZwJCPrn3ugG .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-B7YXUZwJCPrn3ugG .cluster-label text{fill:#333;}#mermaid-svg-B7YXUZwJCPrn3ugG .cluster-label span{color:#333;}#mermaid-svg-B7YXUZwJCPrn3ugG .cluster-label span p{background-color:transparent;}#mermaid-svg-B7YXUZwJCPrn3ugG .label text,#mermaid-svg-B7YXUZwJCPrn3ugG span{fill:#333;color:#333;}#mermaid-svg-B7YXUZwJCPrn3ugG .node rect,#mermaid-svg-B7YXUZwJCPrn3ugG .node circle,#mermaid-svg-B7YXUZwJCPrn3ugG .node ellipse,#mermaid-svg-B7YXUZwJCPrn3ugG .node polygon,#mermaid-svg-B7YXUZwJCPrn3ugG .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-B7YXUZwJCPrn3ugG .rough-node .label text,#mermaid-svg-B7YXUZwJCPrn3ugG .node .label text,#mermaid-svg-B7YXUZwJCPrn3ugG .image-shape .label,#mermaid-svg-B7YXUZwJCPrn3ugG .icon-shape .label{text-anchor:middle;}#mermaid-svg-B7YXUZwJCPrn3ugG .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-B7YXUZwJCPrn3ugG .rough-node .label,#mermaid-svg-B7YXUZwJCPrn3ugG .node .label,#mermaid-svg-B7YXUZwJCPrn3ugG .image-shape .label,#mermaid-svg-B7YXUZwJCPrn3ugG .icon-shape .label{text-align:center;}#mermaid-svg-B7YXUZwJCPrn3ugG .node.clickable{cursor:pointer;}#mermaid-svg-B7YXUZwJCPrn3ugG .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-B7YXUZwJCPrn3ugG .arrowheadPath{fill:#333333;}#mermaid-svg-B7YXUZwJCPrn3ugG .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-B7YXUZwJCPrn3ugG .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-B7YXUZwJCPrn3ugG .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-B7YXUZwJCPrn3ugG .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-B7YXUZwJCPrn3ugG .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-B7YXUZwJCPrn3ugG .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-B7YXUZwJCPrn3ugG .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-B7YXUZwJCPrn3ugG .cluster text{fill:#333;}#mermaid-svg-B7YXUZwJCPrn3ugG .cluster span{color:#333;}#mermaid-svg-B7YXUZwJCPrn3ugG div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-B7YXUZwJCPrn3ugG .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-B7YXUZwJCPrn3ugG rect.text{fill:none;stroke-width:0;}#mermaid-svg-B7YXUZwJCPrn3ugG .icon-shape,#mermaid-svg-B7YXUZwJCPrn3ugG .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-B7YXUZwJCPrn3ugG .icon-shape p,#mermaid-svg-B7YXUZwJCPrn3ugG .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-B7YXUZwJCPrn3ugG .icon-shape .label rect,#mermaid-svg-B7YXUZwJCPrn3ugG .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-B7YXUZwJCPrn3ugG .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-B7YXUZwJCPrn3ugG .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-B7YXUZwJCPrn3ugG :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} Consumer Group A
Producer侧
key=order_001
Partition 0
Partition 1
Partition 2
Partition 3
Producer
Topic: orders
Partition 0
Partition 1
Partition 2
Partition 3
Consumer 1
Consumer 2
Consumer 3
Consumer 4

上图展示了一个 4 Partition Topic 与 4 消费者组的分配关系。生产者通过消息 Key 的哈希值决定消息进入哪个 Partition（若未指定 Key，则按轮询分配），这保证了相同 Key 的消息总是进入同一 Partition，从而在同一 Partition 内保持顺序。

Offset 与消费位点

Kafka 不像 RabbitMQ 那样在消息被消费后立即删除，而是根据配置的保留策略（按时间或按大小）持久化消息。消费者通过维护 Offset（消费位点）来标记已处理到的位置。这种设计使得消费者可以随时"回溯"到历史位置重新消费，这是 Kafka 相对于传统消息队列的核心差异之一。

3.2 confluent-kafka-python 实战：生产者与消费者

confluent-kafka-python 是对 librdkafka 的 Python 封装，提供了比 kafka-python 更高的性能和更完整的 API。

生产者配置

from confluent_kafka import Producer
import json

conf = {
    "bootstrap.servers": "kafka1:9092,kafka2:9092",
    "client.id": "order-service-producer",
    "acks": "all",              # 等待所有 ISR 副本确认
    "retries": 3,               # 发送失败自动重试 3 次
    "linger.ms": 10,            # 累积 10ms 内的消息批量发送
    "batch.size": 32768,        # 每批最多 32KB
    "compression.type": "lz4",  # 压缩算法，降低网络带宽
    "enable.idempotence": True, # 幂等生产者，避免网络抖动导致重复消息
}

producer = Producer(conf)

def delivery_callback(err, msg):
    if err:
        print(f"消息投递失败: {err}")
    else:
        print(f"消息已投递到 {msg.topic()} [{msg.partition()}] @ {msg.offset()}")

payload = json.dumps({"order_id": "ORD-2024-001", "amount": 199.99})
producer.produce("orders", key="ORD-2024-001", value=payload, callback=delivery_callback)
producer.flush()  # 确保缓冲区消息全部发送完毕

acks=all 是保障消息不丢失的最强设置，它要求 Leader 副本和所有 In-Sync Replica（ISR）都确认写入后才返回成功。虽然这会将延迟从 acks=1 的约 5ms 增加到约 20ms，但在金融交易等对可靠性要求极高的场景中，这种代价是必要的。

消费者配置与 Rebalance 处理

from confluent_kafka import Consumer, KafkaException

conf = {
    "bootstrap.servers": "kafka1:9092,kafka2:9092",
    "group.id": "order-processing-group",
    "auto.offset.reset": "earliest",
    "enable.auto.commit": False,  # 手动提交 Offset
    "max.poll.interval.ms": 300000,  # 两次 poll 之间的最大间隔
    "session.timeout.ms": 45000,     # 消费者会话超时时间
}

consumer = Consumer(conf)
consumer.subscribe(["orders"])

try:
    while True:
        msg = consumer.poll(timeout=1.0)
        if msg is None:
            continue
        if msg.error():
            raise KafkaException(msg.error())
        
        process_order(msg.value())
        
        # 业务处理成功后手动同步提交 Offset
        consumer.commit(msg)
except KeyboardInterrupt:
    pass
finally:
    consumer.close()

max.poll.interval.ms 是一个容易被忽视但极为关键的参数。若消费者的单条消息处理时间超过该值，Coordinator 会认为消费者已"僵死"，触发 Consumer Group 的 Rebalance，将该消费者持有的 Partition 分配给其他消费者，导致当前正在处理的消息在 Offset 未提交的情况下被重新消费。在生产环境中，应将 max.poll.interval.ms 设置为下游最大处理时间的 1.5 倍以上。

3.3 消息顺序性：Partition 级别的顺序保证

Kafka 的消息顺序保证仅限于单个 Partition 内部。若业务要求全局顺序（如所有订单按创建时间严格有序消费），只能将 Topic 配置为单 Partition，但这会牺牲并行处理能力。

更工程化的做法是通过业务 Key 将需要保持顺序的消息路由到同一 Partition。例如，订单的生命周期事件（创建 → 支付 → 发货 → 签收）都使用 order_id 作为 Key，确保同一订单的所有事件进入同一 Partition。不同订单之间无需保证顺序，因此可以充分利用多 Partition 的并行能力。

---

四、RabbitMQ vs Kafka：量化选型决策

在实际架构决策中，选择 RabbitMQ 还是 Kafka 并非"哪个更好"的问题，而是"哪个更适合当前场景"。下面从四个维度给出量化对比和决策逻辑。

维度	RabbitMQ	Kafka	决策建议
消息量级	单机万级 ~ 十万级 TPS	集群百万级 TPS	日均消息 < 1000万 选 RabbitMQ，> 1亿 选 Kafka
延迟要求	端到端延迟 1~10ms	端到端延迟 50~200ms	实时交易、指令下发选 RabbitMQ；日志、指标选 Kafka
消费回溯	消息消费后删除，不支持回溯	消息持久化数天~数周，支持任意 Offset 回溯	需要审计、重放历史数据的场景必选 Kafka
顺序保证	Queue 级别 FIFO	Partition 级别 FIFO	都需要业务侧配合 Key 路由，复杂度相当
多租户	原生支持 vhost 隔离	需通过 ACL + Topic 前缀模拟	多业务线共享集群时 RabbitMQ 管理成本更低
运维复杂度	中等，需关注镜像队列和内存告警	较高，需管理 ZooKeeper/KRaft、分区重分配	团队无专职中间件运维时倾向 RabbitMQ

#mermaid-svg-8DzCNa6kCq3Rdc11{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-8DzCNa6kCq3Rdc11 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-8DzCNa6kCq3Rdc11 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-8DzCNa6kCq3Rdc11 .error-icon{fill:#552222;}#mermaid-svg-8DzCNa6kCq3Rdc11 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-8DzCNa6kCq3Rdc11 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-8DzCNa6kCq3Rdc11 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-8DzCNa6kCq3Rdc11 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-8DzCNa6kCq3Rdc11 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-8DzCNa6kCq3Rdc11 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-8DzCNa6kCq3Rdc11 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-8DzCNa6kCq3Rdc11 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-8DzCNa6kCq3Rdc11 .marker.cross{stroke:#333333;}#mermaid-svg-8DzCNa6kCq3Rdc11 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-8DzCNa6kCq3Rdc11 p{margin:0;}#mermaid-svg-8DzCNa6kCq3Rdc11 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-8DzCNa6kCq3Rdc11 .cluster-label text{fill:#333;}#mermaid-svg-8DzCNa6kCq3Rdc11 .cluster-label span{color:#333;}#mermaid-svg-8DzCNa6kCq3Rdc11 .cluster-label span p{background-color:transparent;}#mermaid-svg-8DzCNa6kCq3Rdc11 .label text,#mermaid-svg-8DzCNa6kCq3Rdc11 span{fill:#333;color:#333;}#mermaid-svg-8DzCNa6kCq3Rdc11 .node rect,#mermaid-svg-8DzCNa6kCq3Rdc11 .node circle,#mermaid-svg-8DzCNa6kCq3Rdc11 .node ellipse,#mermaid-svg-8DzCNa6kCq3Rdc11 .node polygon,#mermaid-svg-8DzCNa6kCq3Rdc11 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-8DzCNa6kCq3Rdc11 .rough-node .label text,#mermaid-svg-8DzCNa6kCq3Rdc11 .node .label text,#mermaid-svg-8DzCNa6kCq3Rdc11 .image-shape .label,#mermaid-svg-8DzCNa6kCq3Rdc11 .icon-shape .label{text-anchor:middle;}#mermaid-svg-8DzCNa6kCq3Rdc11 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-8DzCNa6kCq3Rdc11 .rough-node .label,#mermaid-svg-8DzCNa6kCq3Rdc11 .node .label,#mermaid-svg-8DzCNa6kCq3Rdc11 .image-shape .label,#mermaid-svg-8DzCNa6kCq3Rdc11 .icon-shape .label{text-align:center;}#mermaid-svg-8DzCNa6kCq3Rdc11 .node.clickable{cursor:pointer;}#mermaid-svg-8DzCNa6kCq3Rdc11 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-8DzCNa6kCq3Rdc11 .arrowheadPath{fill:#333333;}#mermaid-svg-8DzCNa6kCq3Rdc11 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-8DzCNa6kCq3Rdc11 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-8DzCNa6kCq3Rdc11 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-8DzCNa6kCq3Rdc11 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-8DzCNa6kCq3Rdc11 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-8DzCNa6kCq3Rdc11 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-8DzCNa6kCq3Rdc11 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-8DzCNa6kCq3Rdc11 .cluster text{fill:#333;}#mermaid-svg-8DzCNa6kCq3Rdc11 .cluster span{color:#333;}#mermaid-svg-8DzCNa6kCq3Rdc11 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-8DzCNa6kCq3Rdc11 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-8DzCNa6kCq3Rdc11 rect.text{fill:none;stroke-width:0;}#mermaid-svg-8DzCNa6kCq3Rdc11 .icon-shape,#mermaid-svg-8DzCNa6kCq3Rdc11 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-8DzCNa6kCq3Rdc11 .icon-shape p,#mermaid-svg-8DzCNa6kCq3Rdc11 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-8DzCNa6kCq3Rdc11 .icon-shape .label rect,#mermaid-svg-8DzCNa6kCq3Rdc11 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-8DzCNa6kCq3Rdc11 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-8DzCNa6kCq3Rdc11 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-8DzCNa6kCq3Rdc11 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 是
否
是
否
是
否
是
否
开始选型
消息量级是否超过

日均 1 亿条?
倾向 Kafka
是否需要消息回溯

或流式处理?
倾向 Kafka
端到端延迟是否

要求 < 50ms?
倾向 RabbitMQ
是否需要复杂路由

如 headers / topic 匹配?
倾向 RabbitMQ
两者均可

按团队熟悉度选择
确定选型

上图的决策树覆盖了大多数业务场景。需要强调的是，两者并非互斥关系。在复杂系统中，RabbitMQ 和 Kafka 常常共存：RabbitMQ 处理需要低延迟和复杂路由的实时指令，Kafka 处理海量日志和事件溯源。

---

五、生产实战：订单系统异步通知链路

下面通过一个完整的订单系统案例，展示 Kafka 在实际业务中的应用。该场景涵盖订单创建、库存扣减、短信通知和日志审计四个环节。

5.1 场景设计

当用户在前端提交订单后，后端执行以下操作：

1. 将订单数据写入数据库
2. 向 Kafka Topic order.created 投递事件
3. 三个独立的消费者组分别订阅该 Topic：
   • inventory-group：扣减库存
   • notification-group：发送短信通知
   • audit-group：记录审计日志

这三个消费者组彼此独立，互不影响。库存扣减失败不会阻碍短信发送，短信服务的延迟也不会拖累日志审计。

5.2 生产者代码

from confluent_kafka import Producer
import json

producer_conf = {
    "bootstrap.servers": "kafka:9092",
    "acks": "all",
    "retries": 5,
    "enable.idempotence": True,
}
producer = Producer(producer_conf)

def publish_order_created(order_id: str, user_id: str, amount: float):
    event = {
        "event_type": "order.created",
        "order_id": order_id,
        "user_id": user_id,
        "amount": amount,
        "timestamp": datetime.utcnow().isoformat(),
    }
    producer.produce(
        topic="order.created",
        key=order_id,
        value=json.dumps(event),
    )
    producer.flush()

使用 order_id 作为 Key 至关重要。若库存扣减和日志审计都要求同一订单的事件按顺序处理，相同 Key 保证它们进入同一 Partition。

5.3 消费者代码：库存扣减服务

from confluent_kafka import Consumer, KafkaError

consumer_conf = {
    "bootstrap.servers": "kafka:9092",
    "group.id": "inventory-group",
    "auto.offset.reset": "earliest",
    "enable.auto.commit": False,
}
consumer = Consumer(consumer_conf)
consumer.subscribe(["order.created"])

def deduct_inventory(order_id: str, items: list):
    # 实际业务逻辑：调用库存服务 API
    pass

while True:
    msg = consumer.poll(1.0)
    if msg is None:
        continue
    if msg.error():
        if msg.error().code() == KafkaError._PARTITION_EOF:
            continue
        else:
            print(msg.error())
            break
    
    event = json.loads(msg.value())
    try:
        deduct_inventory(event["order_id"], event.get("items", []))
        consumer.commit(msg)
    except Exception as e:
        # 库存扣减失败时，不提交 Offset，消息将被重新消费
        print(f"库存扣减失败，等待重试: {e}")

5.4 消费者代码：短信通知服务

consumer_conf = {
    "bootstrap.servers": "kafka:9092",
    "group.id": "notification-group",
    "enable.auto.commit": False,
}
consumer = Consumer(consumer_conf)
consumer.subscribe(["order.created"])

while True:
    msg = consumer.poll(1.0)
    if msg is None:
        continue
    event = json.loads(msg.value())
    try:
        send_sms(event["user_id"], f"订单 {event['order_id']} 已创建")
        consumer.commit(msg)
    except Exception:
        # 短信发送失败不影响库存和审计，独立重试
        pass

由于 notification-group 与 inventory-group 是不同的消费者组，Kafka 会为它们各自维护一套 Offset。即使短信服务滞后 10 分钟，库存服务依然可以全速处理最新消息，两者互不影响。

---

六、小结

消息队列是现代分布式系统的基石组件。RabbitMQ 以其低延迟和灵活的路由能力，在实时交易、任务调度等场景中占据优势；Kafka 则凭借高吞吐和持久化回溯能力，成为事件溯源、日志聚合和流式计算的首选。

在 Python 生态中，pika 和 confluent-kafka-python 分别提供了对接两者的生产级客户端。无论选择哪一种，都需要在代码层面落实消息持久化、发布确认、手动 ACK 和死信队列等可靠性机制，而非停留在简单的"发布-订阅"演示。

若对消息可靠投递仍有疑虑，建议从小流量场景开始试点，逐步验证消息不丢失、不重复、按序处理的各项约束，再推广到核心交易链路。

---

如果本文对工程实践有所启发，欢迎点赞、收藏与关注。后续将持续分享 Python 服务在容器化、编排与可观测性方面的实战经验。也欢迎回顾本专栏此前关于 FastAPI 异步接口设计与 SQLAlchemy 工程化实践的内容，构建完整的 Python 后端知识体系。