【RabbitMQ】幂等性、顺序性

幂等性

概述

幂等性是数学和计算机科学中某些运算的性质，他们可以被多次应用，而不会改变初始应用的结果。RabbitMQ的幂等性则是指同一条消息，多次消费，对系统的影响是相同的。

一般消息中间件的消息传输保障分为三个层级：

最少一次（At least once）：消息绝对不会丢失，但可能会重复传输。
恰好一次（Exactly once）：每条消息肯定会被传输一次且仅传输一次。
最多一次（At most once）：消息可能会丢失，但绝对不会重复传输。

RabbitMQ支持最少一次和最多一次。对于恰好一次，RabbitMQ目前做不到，而且很多消息中间件都做不到这一点。

在业务使用中，对于可靠性要求较高的场景，建议使用最少一次，以防消息丢失。最多一次会因为消息发送过程中，网络问题、消费出现异常等种种原因，导致消息丢失。但是最少一次，就会使得消费端可能收到重复的消息，也会造成对同一条消息的多次处理。对于一些比较重要的业务而言，重复处理相同的消息，就会造成严重事故。例如：当用户对一个订单付款之后，因为网络问题，付款成功的结果未返回给订单系统，当用户再次点击付款时，如果系统未做幂等性处理，那就会造成两次扣款。

以下场景可能会导致消息重复发送：

发送时消息重复：当一条消息已被成功发送到Broker并完成持久化，此时出现了网络闪断或者客户端宕机，导致Broker对客户端应答失败，如果此时生产者意识到发送失败并尝试再次发送消息，消费者后续会收到两条内容相同并且MessageID也相同的消息。

投递时消息重复：消息消费的场景下，消息已投递到消费者并完成业务处理，当客户端给服务端反馈应答的时候网络中断。为了保证消息至少被消费一次，消息队列会在网络恢复之后再次尝试投递之前已经被处理过的消息，消费者后续会收到两条内容相同并且MessageID也相同的消息。

解决方案

全局唯一ID

首先，为每条消息分配一个唯一标识符，例如雪花算法、UUID等，只要能保证唯一性即可。

其次，消费者收到消息后，先用唯一标识符判断该消息是否已经消费过，如果消费过就直接放弃。

最后，如果没有消费过，消费者就开始消费信息，业务处理成功之后，把唯一标识符保存起来。

可以使用Redis的原子性操作setnx来保证幂等性，将唯一标识符作为KEY放到Redis中。消费消息之前，先SETNX ID 1。如果返回值为1，表示之前没有消费过，正常消费。返回值为0，则表示这条消息之前已消费过，直接抛弃。

业务逻辑判断

在业务逻辑层面实现消息处理的幂等性。

可以使用数据库来保证幂等性，通过检查数据库是否已经存在相关数据记录；也可以使用锁机制来保证幂等性，通过使用乐观锁机制来避免更新已经被其他事务更改的数据；还可以使用相关业务状态来保证幂等性，在消费者处理消息之前，先检查相关的业务状态，确保消息对应的操作尚未执行，然后才进行处理，具体根据业务场景来做。

顺序性

概述

消息的顺序性是指消费者消费的消息和生产者发送消息的顺序是一致的。例如生产者发送的消息依次是msg1、msg2、msg3，那么消费者消费消息的顺序也必须按照msg1、msg2、msg3的顺序进行。

很多业务场景下，消息的消费是不用保证顺序的，比如使用MQ实现订单超时的处理。但是有些业务场景下，可能存在多个消息顺序处理的情况，比如用户信息修改，对同一个用户的同一个资料进行修改，需要保证消息的顺序。

在实际场景中，如果只有一个生产者，也只有一个消费者，并且不考虑消息丢失、网络故障等异常情况，是可以保证消息的顺序性。但是，如果有多个生产者同时发送消息，无法确定消息到达Broker的前后顺序，也就无法验证消息的顺序性。

打破顺序性的场景：

多个消费者：当队列配置了多个消费者时，消息可能会被不同的消费者并行处理，从而导致消息处理的顺序性无法保证。
网络波动或异常：在消息传递的过程中，如果出现网络波动或异常，可能会导致ACK（消息确认）丢失，从而使得消息被重新入队和重新消费，造成顺序性问题。
消息重试：如果消费者在处理消息后未能及时发送确认，或者确认消息在传输过程中丢失，那么MQ可能会认为消息未被成功消费而进行重试，这也可能导致消息处理的顺序性问题。
消息路由问题：在复杂的路由场景中，消息可能会根据路由键被发送到不同的队列，从而无法保证全局的顺序性。
死信队列：消息因为某些原因进入死信队列，死信队列被消费时，无法保证消息的顺序和生产者发送消息的顺序一致。

打破顺序性的场景包括但不限于以上几种，如果要保证消息的顺序性，那就需要对消息进行进一步的处理。

解决方案

消息顺序性保障分为：局部顺序性保障和全局顺序性保障。

局部顺序性保障指的是在单个队列内部保证消息的顺序。全局顺序性保障指的是在多个队列或多个消费者之间保障消息的顺序。

在实际工作中，全局顺序性难以实现，可以考虑使用业务逻辑来保障顺序性。比如在消息中嵌入序列号，并在消费端进行排序处理。相对而言，局部顺序性更常见，也更容易实现。

RabbitMQ作为一个分布式消息队列，主要优化的是吞吐量和可用性，而不是严格的顺序性保障。如果业务场景确实需要严格的消息顺序，可能需要在应用层面进行额外的设计和实现。

单队列单消费者

最简单的实现顺序性保障的方法一定是，使用单个队列，并由单个消费者进行处理。同一个队列中的消息是先进先出的，这就足以实现消息的顺序性。

分区消费

虽然单消费者单队列可以完美保障消息的顺序性，但是其吞吐太低了。当需要多个消费者以提高处理速度时，可以使用分区消费。把一个队列分割成多个分区，每个分区由一个消费者处理，以此保障每个分区内消息的顺序性。例如最开始的修改资料这一业务，我们只需要保障每个用户的消息顺序性即可，因此我们可以使用分区消费来做（可以借助Spring-CLoud-Stream来实现）。