消息队列(三)

顺序消息

消息有序指的是可以按照消息的发送顺序来消费。例如：一笔订单产生3条消息，分别创建订单消息、订单支付消息、订单物流消息。消费时，需要按照顺序依次消费才有意义，与此同时多笔订单可以又并行消费。

在部分消息队列，例如RabbitMQ，如果多个消费者同时从服务器消费消息，会造成消息异步的发送给各个消费者，这样就会造成消息的无序。在一些消息队列，例如Kafka、RocketMQ使用分区(parttion)的概念，使得消息能够有序且能够并发的处理消息。

全局顺序

首先对于单生产者和单消费者这种情况下能够保证消息的有序。比如上诉情况下，消费者把生成的3条消息放入队列中，由于只有一个消费者，所以能够保证有序。但是当有多个消费者或者说多个消费线程情况下就会出现无序。

分区顺序

分区顺序是部分消息队列支持，例如Kafka、RocketMQ。在生产者发送消息时，如果指定分区(parttion)，那么消息就会发给到该分区下的队列，保证有序。在消费端，消息队列保证1个分区只能被一个Consumer消费，这样我们就可以多个Consumer并发的处理有序消息。注意：这里消息有序指的是一个分区下的消息有序，并发的处理消息指的是消费者可以并发的处理多个分区消息。这样，通过分区的概念，把并发和有序都能够很好的解决。注：图来自顺序消息

对于指定的一个 Topic，所有消息根据 sharding key 进行区块分区。同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。Sharding key 是顺序消息中用来区分不同分区的关键字段，和普通消息的 Key 是完全不同的概念。

分区顺序的例子：电商的订单创建，以订单 ID 作为 sharding key，那么同一个订单相关的创建订单消息、订单支付消息、订单退款消息、订单物流消息都会按照先后顺序来发布和订阅。

消息持久化

消息持久化主要是在消息队列服务器挂掉的情况下，消息不会消失。也就是说在MQ-Server接收到消息后会把消息持久化到磁盘，这样在MQ-Server挂点的情况下也可以从磁盘中恢复。这里持久化主要有两种方式：

• 同步持久化： 同步持久化指的是消息到达MQ-Server后会同步持久化到磁盘中才算真正的接收消息，才会回调SendCallback接口。这样的话缺点是需要较长时间，毕竟写磁盘比写内存慢多了。
• 异步持久化 异步持久化值的是消息到达MQ-Server后会异步的持久化到磁盘中。这样的话缺点是如果在持久化过程中，MQ-Server挂点会导致该条消息的丢失。

消息消费模式

各种消息队列有不同的消费模式，每个消息队列对于消费模式有不同的叫法，但是其实质基本相同，下面介绍两种消费模式：

P2P模式

P2P模式也叫直连模式，指的是生成者生成的消息生成的消息只由一个消费者消费。图来自网络：

Pub/Sub模式

Pub/Sub模式也叫发布订阅模式，其与设计模式中的观察者模式类似。消费者把消息发送给某一主题(Topic)，对这一主题感兴趣的所有消费者都会接收到该消息。图来自网络：

消息队列的其它特性

消息队列还支持许多不同的特性，自己仅仅把一些特性列出来，自己也不太懂，以后写：

• 定时消息
• 消息的存储和消息的堆积
• 消息队列对事务的支持
• ...

Reference

http://www.wangzhe.tech/kafka/Kafka保证消息的有序性/2017/06/18/
https://codeday.me/bug/20171210/105056.html
http://blog.csdn.net/chunlongyu/article/details/53977819
http://dbaplus.cn/news-21-1123-1.html
https://tech.meituan.com/mq-design.html
https://cloud.tencent.com/document/product/406/8303
https://www.jianshu.com/p/453c6e7ff81c