消息队列顺序具体分为局部有序和全局有序：

局部顺序：一个Topic下只需要满足同一消息key是有序的既可。例如，一个Topic下是内容变更流水，消息key值为内容ID，同一个内容ID下所有的消息是有序的；

全局有序：一个Topic下的所有消息都要有序。

Kafka

全局有序

通常Kafka一个Topic对应多个Partition，消息会被分散写入到各个Partition中，导致顺序混乱。上篇文章介绍过在一个Partition内消息是有序的，一个Partition只能对应一个Consumer。所以要满足全局有序，就需要一个Topic唯一对应一个Partition就可以了。Producer_1将消息msg1、msg2依次写入Topic_1，Topic_1将消息转发到唯一的队列Partition_1中，顺序依旧为mage2<-msg1，Consumer_1先读到msg1，然后是msg2。

这种单点架构在实际场景中有很大局限性。

局部有序

在发消息时指定PartitionKey，Kafka会对起其进行Hash计算，计算结果决定将消息放到哪个Partition。这样对于相同的PartitionKey总能被Hash到同一个Partition。这种情况下，一个Topic依然可以对应多个Partition，业务可根据实际情况进行扩容。

Pulsar

路由模式

• RoundRobinPartition：默认路由模式。消息没指定Key就以轮询的方式将消息发送到各个分区。如果指定了Key，会对Key进行Hash并根据结果将消息分发到对应分区；
• SinglePartition：消息没指定Key，Producer会随机选择一个分区，将所有消息都分发到这个分区。消息指定了Key，会对Key进行Hash并根据结果将消息分发到对应分区；
• CustomPartition：自定义模式，用户可以通过MessageRouter实现自定义路由规则。

订阅方式

Pulsar的订阅方式有4种，独占、共享、灾备、key共享。

独占模式下，一个Topic只能有Consumer A-0一个消费者；

灾备模式下，在两个Consumer都正常运行的情况下，Consumer B-0权重较高可以收到消息。只有当Consumer B-0断开时，Consumer B-1才能收到消息；

共享模式下，三个Consumer共同监听一个分区，现有m0-m4五条消息，Pulsar均匀的把这消息分发给三个Consumer。同一个消息未执行Ack，可以被多个Consumer读到；执行Ack后，该消息不会被再次消费；

健共享模式下，多个Consumer可以监听同一个分区，Pulsar会把相同密钥或相同排序密钥的消息分发给同一个Consumer；

全局有序

路由模式SinglePartition，消息不设置Key，根据前面介绍，Pulsar会将所有消息放入同一个分区，实现全局有序。

单点架构扩展性差。

局部有序

路由模式RoundRobinPartition/SinglePartition，消息指定key，Pulsar会对Key进行Hash并根据结果将消息分发到对应分区。

RabbitMQ

全局有序

一个Queue唯一对应一个Consumer，这样保证了消息的全局顺序性。

局部有序

ExchangeType使用Topic模式，通过定义RoutingKey、Bindingkey定义匹配规则，exchange将消息转发到匹配的Queue里，符合同一配规则的消息有序。

RocketMQ

全局有序

一个Queue唯一对应一个Consumer，这样保证了消息的全局顺序性。

局部有序

ExchangeType使用Topic模式，通过定义RoutingKey、Bindingkey定义匹配规则，exchange将消息转发到匹配的Queue里，符合同一配规则的消息有序。

版本控制，全局有序

版本服务只有两个接口，写版本即Redis的Incr，读版本即Redis的Get。 版本号是Key对应的连续自增数字。

1. 写版本：消息发送前先请求版本服务，请求数据：

{
  "key":"fhr2f0hd3v",
  "data":["title","status"],
}

此时fhr2f0hd3v_title和fhr2f0hd3v_status的版本号分别为1、1 2. 将消息发送到消息队列，消息体里需要记录版本号

message:
{
  "modify": {
    "status": {
      "version": 1,
      "value": "-1"
    },
    "title": {
      "version": 1,
      "value": "标题"
    }
  },
  "id": "fhr2f0hd3v",
}

1. 下游服务从Consumer中获取到消息
2. 请求版本服务，获取变更消息对应的版本号。正常来说，fhr2f0hd3v_title和fhr2f0hd3v_status对应的版本号应该都是1，但是这条消息由于网络延迟严重滞后，实际的版本分别是1和3。那么这条消息里的status变更是无效的，应该丢弃掉；title变更是有效的。

特点

• 全局有序
• 紧贴业务：版本控制的纬度必须是业务数据变更的最小纬度
• 数据范围：版本读写的范围，只对变更、新增的数据