一些需要注意的地方- 集群配置：
一个集群中多个节点共享一份.erlang.cookie文件；若是没有启用RABBITMQ_USE_LONGNAME，需要在每个节点的hosts文件中指定其他节点的地址，不然会找不到其他集群中的节点。
- 脑裂（网络分区）：
RabbitMQ集群对于网络分区的处理和忍受能力不太好，推荐使用 或者shovel插件去解决。
但是，情况已经发生了，怎么去解决呢？放心，还是有办法恢复的。
当网络断断续续时，会使得节点之间的通信断掉，进而造成集群被分隔开的情况。
这样，每个小集群之后便只处理各自本地的连接和消息，从而导致数据不同步。当重新恢复网络连接时，它们彼此都认为是对方挂了-_-||，便可以判断出有网络分区出现了。但是RabbitMQ默认是忽略掉不处理的，造成两个节点继续各自为政（路由，绑定关系，队列等可以独立地创建删除，甚至主备队列也会每一方拥有自己的master）。
可以更改配置使得连接恢复时，会根据配置自动恢复：
- ignore：默认，不做任何处理
- pause-minority：断开连接时，判断当前节点是否属于少数派（节点数少于或者等于一半），如果是，则暂停直到恢复连接。
- {pause_if_all_down, [nodes], ignore | autoheal}：断开连接时，判断当前集群中节点是否有节点在nodes中，如果有，则继续运行，否则暂停直到恢复连接。这种策略下，当恢复连接时，可能会有多个分区存活，所以，最后一个参数决定它们怎么合并。
- autoheal：当恢复连接时，选择客户端连接数最多的节点状态为主，重启其他节点。
配置：
- 多次ack
客户端多次应答同一条消息，会使得该客户端收不到后续消息。
结合Docker使用集群版本的实现：详见一个例子
消息队列中间件的比较- RabbitMQ：
- 优点：支持很多协议如：AMQP，XMPP，STMP，STOMP；灵活的路由；成熟稳定的集群方案；负载均衡；数据持久化等。
- 缺点：速度较慢；比较重量级，安装需要依赖Erlang环境。
- Redis：
- Kafka：
- 优点：高吞吐；分布式；快速持久化；负载均衡；轻量级
- 缺点：极端情况下会丢消息
最后附一张网上截取的测试结果:
performance
更多性能参数见：
如果有兴趣简单了解下RabbitMQ的简单介绍，可以继续往下看～ |
