Java面试宝典：重复消费、顺序消费、分布式事务

重复消费

 

诱因

消息队列拥有重试机制，下游业务因（服务器网络抖动，开发人员代码BUG，数据问题）等原因发生异常后，程序会抛出异常并要求重新发送请求。

解决方法

幂等(idempotent、idempotence)：

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。

• 强检验：用于金钱相关的操作，将金钱与流水接口一起事物，通过流水确定唯一性，方便对账与排查问题

• 弱检验：使用token / 将场景数据存于Redis

顺序消费

情景

一般都是同个业务场景下不同几个操作的消息同时过去，本身顺序是对的，但是你发出去的时候同时发出去了，消费的时候却乱掉了(多线程同时消费)，这样就有问题了。

解决方法

RocketMQ SelectMessageQueueByHash.class MessageQueueSelector.class

因为同一订单Hash值相同，故可使用Hash取模，让同一个订单发送到同一个队列，再使用同步发送。只有同个订单的创建消息发送成功再发送只发消息，至此确保了发送有序。RocketMQ仅保证顺序发送，顺序消费由消费者业务保证!!!

 consumer.registerMessageListener(new MessageListenerOrderly() {
            @Override
            public ConsumeOrderlyStatus consumeMessage(List msgs, ConsumeOrderlyContext context) {
                context.setAutoCommit(true);
                for (MessageExt msg : msgs) {
                    // 可以看到每个queue有唯一的consume线程来消费, 订单对每个queue(分区)有序
                    System.out.println("consumeThread=" + Thread.currentThread().getName() + "queueId=" + msg.getQueueId() + ", content:" + new String(msg.getBody()));
                }
                return ConsumeOrderlyStatus.SUCCESS;
            }
        });

对于消费者(consumer)来说，消费消息的时候，会有一个 PullMessageService 拉取线程（单线程）拉取消息，然后放入到 processQueue（每个消费队列对应一个 processQueue） 中，因为是单线程拉取的，对于同一个队列的消息（虽然消费者可以订阅多个队列，但是对于同一个队列是有序的）是有序的。在放入 processQueue 之后，会调用 ConsumeMessageConcurrentlyService 或 ConsumeMessageOrderlyService 来进行消费，这里是调用 ConsumeMessageOrderlyService 进行消费。ConsumeMessageOrderlyService 在消费的时候，会先获取每一个 ConsumerQueue 的锁，然后从 processQueue 获取消息消费，这也就意味着，对于每一个 ConsumerQueue 的消息来说，消费的逻辑也是顺序的。

分布式事务

事务 (Transaction)

事务 (Transaction) = 事务开始 + 全体操作 + 事务结束**，它具有以下四个特性 (ACID)

1. 原子性（atomicity）：一个事务是一个不可分割的工作单位，事务中包括的操作要么都做，要么都不做。

2. 一致性（consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。

3. 隔离性（isolation）：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

4. 持久性（durability）：持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

大致分类  

• 2pc（两段式提交）

  通过消息中间件协调多个系统，在两个操作系统操作事物时都锁定资源但不提交事务，等两者都准备好后告诉消息中间件，再吻别提交事务 

  缺点：有可能因为网络波动或各种原因导致两系统一个提交成功一个提交失败。

• 3pc（三段式提交）

• TCC（Try、Confirm、Cancel）

• 最大努力通知

• XA

• 本地消息表（ebay研发出的）

• 半消息/最终一致性（RocketMQ）

最终一致性

整个流程中，我们能保证是：

• 业务主动方本地事务提交失败，业务被动方不会收到消息的投递。

• 只要业务主动方本地事务执行成功，那么消息服务一定会投递消息给下游的业务被动方，并最终保证业务被动方一定能成功消费该消息（消费成功或失败，即最终一定会有一个最终态）。