从选型到落地：一次线上事故后，我们为什么从Kafka换成了RocketMQ？

从选型到落地：一次线上事故后，我们为什么从Kafka换成了RocketMQ？

去年双十一大促期间，我们的电商平台遭遇了一次严重的线上事故：由于订单状态同步延迟，导致超卖和重复发货问题集中爆发。事后复盘发现，问题根源在于消息中间件Kafka在事务消息和延迟消息处理上的缺陷。这次事故促使我们重新评估消息中间件选型，最终完成了从Kafka到RocketMQ的架构迁移。本文将分享这一技术决策背后的完整思考过程。

1. 事故复盘：Kafka在电商核心场景的三大短板

1.1 订单状态不一致事件全记录

大促峰值期间，我们的订单系统出现了诡异的"幽灵订单"现象：库存系统显示已扣减，但订单系统却查询不到对应记录。经过日志追踪，发现问题出在支付成功消息的传递环节：

// Kafka生产者伪代码（问题版本）
kafkaProducer.beginTransaction();
try {
    // 1. 数据库记录订单状态
    orderDao.updateStatus(orderId, "PAID"); 
    // 2. 发送支付成功消息
    producer.send(new ProducerRecord<>("payment", orderId)); 
    kafkaProducer.commitTransaction();
} catch (Exception e) {
    kafkaProducer.abortTransaction();
}

这段代码在正常情况下运行良好，但在网络波动时暴露了两个致命缺陷：

1. 事务消息不完整 ：当数据库提交成功但Kafka事务提交失败时，没有完善的重试机制
2. 消息无序到达 ：由于Kafka分区机制，库存系统可能先收到"订单取消"消息后收到"支付成功"消息

1.2 Kafka在电商场景的局限性对比

我们整理了Kafka与RocketMQ在关键特性上的差异：

关键发现 ：对于需要强一致性的订单业务，Kafka在事务和顺序消息上的妥协成为了系统隐患。

2. 技术选型：为什么RocketMQ更适合电商架构

2.1 事务消息的终极解决方案

RocketMQ的事务消息采用"半消息+本地事务检查"机制：

// RocketMQ事务消息示例
TransactionMQProducer producer = new TransactionMQProducer("order_group");
producer.setTransactionListener(new TransactionListener() {
    @Override
    public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        // 执行本地事务
        boolean success = orderService.processOrder((OrderDTO)arg);
        return success ? LocalTransactionState.COMMIT_MESSAGE : 
                       LocalTransactionState.ROLLBACK_MESSAGE;
    }
    
    @Override
    public LocalTransactionState checkLocalTransaction(MessageExt msg) {
        // 事务状态回查
        return orderService.checkOrderStatus(msg.getKeys());
    }
});

这种设计完美解决了分布式事务问题：

1. 先发送半消息到MQ服务器
2. 执行本地数据库事务
3. 根据本地事务状态提交或回滚消息

2.2 顺序消息的队列级保障

在库存扣减场景中，RocketMQ的队列顺序保证至关重要：

# 库存消费者必须保证顺序处理
consumer.registerMessageListener(lambda msgs: {
    for msg in msgs:
        if not inventory_service.process(msg):  # 处理失败时挂起当前队列
            return ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT
    return ConsumeOrderlyStatus.SUCCESS
})

我们通过以下配置确保顺序性：

• 相同订单ID路由到同一队列（MessageQueue）
• 消费者采用顺序消费模式
• 失败时自动暂停当前队列（避免乱序）

3. 迁移实战：零停机切换方案

3.1 双写过渡期架构设计

为确保平滑迁移，我们设计了为期两周的双写期：

[生产者端] 
订单服务 → Kafka（原有链路）
       ↘ RocketMQ（新链路）

[消费者端]
并行消费两个消息源 → 数据比对 → 异常报警

关键迁移步骤：

1. 数据同步 ：使用Connector工具将历史Kafka消息导入RocketMQ
2. 流量切换 ：通过配置中心逐步将生产者流量切至RocketMQ
3. 验证阶段 ：对比两个消息管道的处理结果差异
4. 收尾工作 ：下线Kafka相关组件，完成监控体系迁移

3.2 遇到的典型问题与解决方案

问题1 ：消费者重复处理消息
解决方案 ：在业务层增加幂等判断

-- 订单处理幂等表
CREATE TABLE order_idempotent (
    msg_id VARCHAR(64) PRIMARY KEY,
    order_id BIGINT,
    status TINYINT,
    created_time DATETIME
) ENGINE=InnoDB;

问题2 ：RocketMQ控制台监控指标缺失
解决方案 ：自定义Exporter对接Prometheus：

# Prometheus配置示例
scrape_configs:
  - job_name: 'rocketmq_exporter'
    static_configs:
      - targets: ['mq_exporter:5557']

4. 迁移后的效果验证

4.1 性能指标对比

迁移前后关键指标变化：

4.2 运维体验升级

1. 监控可视化 ：RocketMQ控制台原生支持消息轨迹追踪
2. 动态扩缩容 ：无需像Kafka那样调整分区数
3. 消息查询 ：支持按MessageID或Key快速定位消息
4. 延迟队列 ：替代原基于Redis的延迟任务系统

5. 最佳实践总结

经过半年生产验证，我们提炼出以下经验：

1. 队列规划原则 ：

   • 核心业务（如订单）使用独立Topic
   • 按业务维度设计Tag（如 PAYMENT_SUCCESS 、 INVENTORY_DEDUCT ）
   • 队列数=消费者实例数×2（预留扩容空间）

2. 消费者配置黄金法则 ：

   # consumer.properties
   consumeThreadMin=20
   consumeThreadMax=64
   pullBatchSize=32
   consumeMessageBatchMaxSize=10
   

3. 必须实现的监控项 ：

   • 堆积消息数（超过1000条触发报警）
   • 消费RT时间（大于1秒需要优化）
   • 死信队列增长趋势

这次架构升级给我们的重要启示是：消息中间件的选型必须匹配业务场景的特性。对于需要强一致性的电商系统，RocketMQ在事务支持和消息顺序性上的优势，使其成为比Kafka更合适的选择。