MQ 如何保证数据一致性？

树上有只程序猿

于 2025-03-28 17:32:06 发布

阅读量636

点赞数 24

本文链接：https://blog.csdn.net/fefdfg/article/details/146606624

版权

（MQ）消息队列的数据一致性设计，绝对能排进分布式系统三大噩梦之一！

今天这篇文章跟大家一起聊聊，MQ如何保证数据一致性？希望对你会有所帮助。

1 数据一致性问题的原因

这些年在Kafka、RabbitMQ、RocketMQ踩过的坑，总结成四类致命原因：

生产者悲剧：消息成功进Broker，却没写入磁盘就断电。
消费者悲剧：消息消费成功，但业务执行失败。
轮盘赌局：网络抖动导致消息重复投递。
数据孤岛：数据库和消息状态割裂（下完单没发券）

这些情况，都会导致MQ产生数据不一致的问题。

那么，如何解决这些问题呢？

2 消息不丢的方案

我们首先需要解决消息丢失的问题。

2.1 事务消息的两阶段提交

以RocketMQ的事务消息为例，工作原理就像双11的预售定金伪代码如下：

// 发送事务消息核心代码
TransactionMQProducer producer = new TransactionMQProducer("group");
producer.setTransactionListener(new TransactionListener() {
    // 执行本地事务（比如扣库存）
    public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        return doBiz() ? LocalTransactionState.COMMIT : LocalTransactionState.ROLLBACK;
    }

    // Broker回调检查本地事务状态
    public LocalTransactionState checkLocalTransaction(MessageExt msg) {
        return checkDB(msg.getTransactionId()) ? COMMIT : ROLLBACK;
    }
});

真实场景中，别忘了在checkLocalTransaction里做好妥协查询（查流水表或分布式事务日志）。

去年在物流系统救火，就遇到过事务超时的坑——本地事务成功了，但因网络问题没收到Commit，导致Broker不断回查。

2.2 持久化配置

RabbitMQ的坑都在配置表里：

配置项	例子	作用
队列持久化	durable=true	队列元数据不丢
消息持久化	deliveryMode=2	消息存入磁盘
Lazy Queue	x-queue-mode=lazy	消息直接写盘不读取进内存
Confirm机制	publisher-confirm-type	生产者确认消息投递成功

RabbitMQ本地存储+备份交换机双重保护代码如下：

channel.queueDeclare("order_queue", true, false, false, 
    new HashMap<String, Object>(){{
        put("x-dead-letter-exchange", "dlx_exchange"); // 死信交换机
    }});

去年双十一订单系统就靠这个组合拳硬刚流量峰值：主队列消息积压触发阈值时，自动转移消息到备份队列给应急服务处理。

2.3 副本配置

消息队列	保命绝招
Kafka	acks=all + 副本数≥3
RocketMQ	同步刷盘 + 主从同步策略
Pulsar	BookKeeper多副本存储

上周帮一个金融系统迁移到Kafka，为了数据安全启用了最高配置。

server.properties配置如下：

acks=all
min.insync.replicas=2
unclean.leader.election.enable=false

结果发现吞吐量只剩原来的三分之一，但客户说“钱比速度重要”——这一行哪有银弹，全是取舍。

不同的业务场景，情况不一样。

3 应对重复消费的方案

接下来，需要解决消息的重复消费问题。

3.1 唯一ID

订单系统的架构课代表代码：

// 雪花算法生成全局唯一ID
Snowflake snowflake = new Snowflake(datacenterId, machineId);
String bizId = "ORDER_" + snowflake.nextId();

// 查重逻辑（Redis原子操作）
String key = "msg:" + bizId;
if(redis.setnx(key, "1")) {
    redis.expire(key, 72 * 3600);
    processMsg();
}

先使用雪花算法生成全局唯一ID，然后使用Redis的setnx命令加分布式锁，来保证请求的唯一性。

某次促销活动因Redis集群抖动，导致重复扣款。

后来改用：本地布隆过滤器+分布式Redis 双校验，总算解决这个世纪难题。

3.2 幂等设计

针对不同业务场景的三种对策：

场景	代码示例	关键点
强一致性	SELECT FOR UPDATE先查后更新	数据库行锁
最终一致性	版本号控制（类似CAS）	乐观锁重试3次
补偿型事务	设计反向操作（如退款、库存回滚）	操作日志必须落库

去年重构用户积分系统时，就靠着这个三板斧把错误率从0.1%降到了0.001%：

积分变更幂等示例如下：

public void addPoints(String userId, String orderId, Long points) {
    if (pointLogDao.exists(orderId)) return;
    
    User user = userDao.selectForUpdate(userId); // 悲观锁
    user.setPoints(user.getPoints() + points);
    userDao.update(user);
    pointLogDao.insert(new PointLog(orderId)); // 幂等日志
}

这里使用了数据库行锁实现的幂等性。

3.3 死信队列

RabbitMQ的终极保命配置如下：

// 消费者设置手动ACK
channel.basicConsume(queue, false, deliverCallback, cancelCallback);

// 达到重试上限后进入死信队列
public void process(Message msg) {
    try {
        doBiz();
        channel.basicAck(deliveryTag);
    } catch(Exception e) {
        if(retryCount < 3) {
            channel.basicNack(deliveryTag, false, true);
        } else {
            channel.basicNack(deliveryTag, false, false); // 进入DLX
        }
    }
}

消费者端手动ACK消息。

在消费者端消费消息时，如果消费失败次数，达到重试上限后进入死信队列。

这个方案救了社交系统的推送服务——通过DLX收集全部异常消息，凌晨用补偿Job重跑。