顺序消息
消息有序指的是可以按照消息的发送顺序来消费。例如：一笔订单产生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