消息端要点:

消息将以轮询的分发方式发送给消费者。每条消息只会发送给订阅列表里的一个消费者。这种方式非常适合扩展，如果负载加重，那么只需要创建更多的消费者来消费处理消息即可。
       轮询分发机制也不是那么优雅，默认有n个消费者，那么RabbitMQ会将第m条消息分发给第 m%n(取余的方式)个消费者，RabbitMQ不管消费并已经确定消息。

   channel.basicQos()这个方法允许限制信道上的消费者所能保持的最大未确认消息数量。

      在订阅消费队列之前，消费端程序调用了channel.basicQos(5),之后订阅了某个队列继续消费。RabbitMQ会保存一个消费者的列表，每发送 一条消息都会为对应的消费者计数，如果到达了所设定的值，那么RabbitMQ不会向这个消费者再发送任何消息，直到消费者确定了某条消息之后，RabbitMQ将相应的计数减一，之后消费者可以继续接收消息。

拉模式的消费方式无效

消息的顺序性:

消费到的消息和发布者发布的消息顺序是一致的.
    在不使用任何RabbitMQ的高级特性,也没有消息丢失、网络故障之类异常的情况发生，并且只有一个消费者的情况下，最好也只有一个生产者的情况下可以保证消息的顺序性。如果有多个生产者同时发送消息，无法确定消息到达Broker的前后顺序，也就无法验证消息的顺序性。

RabbitMQ的消息顺序会被打乱的情况？

  • 生产者使用事务机制，在发送消息时发生错误进行了事务回滚，需要重新补发数据，如果补发数据是在另一个线程里面实现的，同样 publisher confirm机制也有同样的原因
  •  生产者发送消息设置了不同的超时时间，并且设置了死信队列，整体来说就是一个延迟队列，消费者消费死信队列数据时顺序不被保证
  • 消息设置了优先级，同样消息的顺序不被保证