【Kafka进阶6】顺序消费深度解析

一、Kafka 顺序消费的核心原理

1.1 Kafka 顺序

Kafka 的顺序保证建立在 分区（Partition） 这一核心概念之上。

Kafka 提供的顺序保证：

💡 核心结论：Kafka 只保证分区内有序，不保证全局有序。

1.2 实现顺序消费的关键步骤

二、核心代码实现 💻

2.1 生产者端——指定 Key 路由到同一分区

@Service
public class KafkaOrderProducer {
    
    @Autowired
    private KafkaTemplate<String, String> kafkaTemplate;

    /**
     * 发送顺序消息
     * @param orderId 订单ID（作为Key，保证同一订单进入同一分区）
     * @param messageBody 消息体
     */
    public void sendOrderlyMessage(Long orderId, String messageBody) {
        // ✅ 技术亮点：指定 Key，Kafka 默认按 Key 哈希分配到同一个 Partition
        // Kafka 使用 MurmurHash2 算法对 Key 进行哈希，与分区数取模决定目标分区
        kafkaTemplate.send("ORDER_TOPIC", orderId.toString(), messageBody);
    }
}

📌 原理补充：当消息指定了 Key 时，Kafka 使用确定性哈希函数（MurmurHash2）将 Key 映射到固定分区。相同 Key 的消息始终进入同一分区，从而保证顺序。

2.2 消费者端——线程数 = 分区数

@Component
public class KafkaOrderConsumer {
    
    private static final Logger log = LoggerFactory.getLogger(KafkaOrderConsumer.class);
    
    @Autowired
    private OrderService orderService;

    /**
     * 顺序消费消息
     * ⚠️ 关键：concurrency 必须等于 Topic 的 Partition 数
     * 每个分区只能被一个消费者线程消费
     */
    @KafkaListener(
        topics = "ORDER_TOPIC", 
        groupId = "ORDER_CONSUMER_GROUP", 
        concurrency = "8"  // 线程数 = 分区数
    )
    public void consumeMessage(ConsumerRecord<String, String> record) {
        Long orderId = Long.parseLong(record.key());
        String messageBody = record.value();
        
        log.info("📨 Kafka顺序消费消息，订单ID：{}，分区：{}，偏移量：{}", 
                 orderId, record.partition(), record.offset());

        // 业务逻辑处理
        orderService.processOrderMessage(orderId, messageBody);
    }
}

⚠️ 重要限制：消费者组内的消费者实例数不能超过分区数，否则多余的消费者将处于空闲状态。

三、技术难点与解决方案 🛡️

3.1 技术难点全景图

3.2 Rebalance 乱序问题深度解析

💡 Rebalance 并不会破坏分区内的顺序，但可能导致：

• 重复消费：新消费者从上次提交的偏移量开始，可能重复消费已处理但未提交的消息
• 短暂处理中断：重平衡期间消费暂停

四、队头阻塞问题与应对策略 🧩

“这正是队头阻塞问题，面试官您问到点上了 🤓。我们有几套策略，根据业务严重性选择：”

4.1 三种应对策略对比

4.2 订单场景推荐方案：状态机校验 + 死信兜底

核心思路：消息体里带前置状态，消费时做乐观锁校验。

-- ✅ 支付消息示例：期望前置状态为"待支付"
UPDATE order 
SET status = '已支付' 
WHERE id = #{orderId} 
  AND status = '待支付';  -- 乐观锁条件

📌 为什么这样有效？

• 如果状态已是 已取消，UPDATE 影响行数为 0，直接 ACK 或移入死信
• 即使历史消息重放，也不会打乱最终结果
• 天然幂等，无需额外去重逻辑

五、幂等性保障——防止重复消息 💪

5.1 重复消息的来源

5.2 幂等性保障方案

消费端去重示例：

-- ✅ 唯一索引保证幂等
CREATE TABLE order_event (
    id BIGINT PRIMARY KEY,
    order_id BIGINT NOT NULL,
    event_id VARCHAR(64) UNIQUE,  -- 业务流水号唯一索引
    event_type VARCHAR(32),
    create_time DATETIME
);

// ✅ 消费时先检查是否已处理
public void consumeMessage(ConsumerRecord<String, String> record) {
    String eventId = extractEventId(record.value());
    
    // Redis 分布式锁 / DB 唯一键检查
    if (eventService.isProcessed(eventId)) {
        log.info("⏭️ 消息已处理，跳过。eventId: {}", eventId);
        return;
    }
    
    // 业务处理 + 记录处理状态（原子操作）
    orderService.processOrderMessage(record);
    eventService.markProcessed(eventId);
}

六、总结 📝

🎯 Kafka 通过分区机制提供顺序保证，通过 Key 哈希实现业务级顺序路由，通过状态机校验+幂等解决乱序和重复两大难题。