RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。RabbitMQ服务器是用Erlang语言编写的，而集群和故障转移是构建在开放电信平台(OTP)框架上的。所有主要的编程语言均有与代理接口通讯的客户端库。
Erlang(爱浪)特点：
- 并发性：Erlang支持超大量级的并发进程，并且不需要操作系统具有并发机制；
- 分布式：一个分布式Erlang系统是多个Erlang节点组成的网络；
- 健壮性：Erlang具有多种基本的错误检测能力，它们能够用于构建容错系统；
- 可伸缩性；
教程：RabbitMQ实战指南.pdf
消息丢失
如果应用系统对可靠性要求很高，吞吐量不是很care，那么可以从以下几个方面入手：
1、交换器、队列、消息持久化；
2、消费者设置autoAck=false，手动确认；
3、RabbitMQ的镜像队列机制，Master-Slave高可用，集群都挂掉的可能性比单机挂掉的概率要小很多，几乎不用考虑，理由：RabbitMQ 并不会为每条消息都进行同步存盘(调用内核的 fsync方法)的处理，可能仅仅保存到操作系统缓存之中而不是物理磁盘之中。如果在这段时间内RabbitMQ 服务节点发生了岩机、重启等异常情况，消息保存还没来得及落盘，那么这些消息将会丢失；
4、生产者确认：事务机制、发送方确认机制(解决消息在没有到达broker之前出现意外)；
消息顺序性
哪些情况会打破消息顺序性？
1、生产者使用事务机制或Confirm确认机制，如果发生异常导致消息重发，并且重发使用另一个线程执行，这样在发送端就无法保证顺序性；
2、生产者发送的消息设置了不同的过期时间，并且设置了死信队列，整体上来说相当于一个延迟队列，延迟队列的消息顺序势必和发送的顺序不一样；
3、消息设置了优先级，在消息堆积的情况下消费者消费也必然不是顺序性的；
4、消费者在nack或reject消息后，并且让消息重新入队列，此时消息会发送给其他消费者，导致消息顺序发生改变；
总结：一般情况下，一个queue中的消息是无需保证顺序消费的，如果消息需要保证消费顺序，肯定也是两种不同类型的消息，此时可以创建多个queue，每个queue对应一个consumer，完全的顺序消费也就是要求串行化了。
消息传输保障
消息可靠传输保障分为三个层级：
1、At most once: 最多一次，消息可能丢失，但绝不会重复；
2、At least once: 最少一次，消息可能重复，但绝不会丢失；
3、Exactly once: 切好一次，每条消息传输一次且仅传输一次；
RabbitMQ支持其中的At most once和At least once。
针对At least once需要考虑以下几个方面:
1、生产者开启事务机制或确认机制，失败后重发消息；
2、生产者配合使用mandatory参数或者备份交换器确保消息路由到队列；
3、消息和队列进行持久化处理；
4、消费者在消费消息时设置autoAck=false，采用手动确认的方式；
针对At most once，无需考虑以上，生产者随意发送，消费者随意消费，很难确保消息不会丢失。
RabbitMQ无法保证切好一次，目前主流的消息中间件都无法保证，只能在客户端进行判断处理(消费者去重判断处理—唯一ID)。
来源：CSDN
作者：java爱分享
链接：https://blog.csdn.net/ETTTTTSS/article/details/103654539