RabbitMQ进阶

        RabbitMQ 可靠性投递分析  

           <1>、确保消息发送到RabbitMQ服务器：服务端确认—Confirm模式

           <2>、确保消息路由到正确的队列 ：备份交换机和生产者发送消息添加ReturnListener，生产上不太可能出现

           <3>、确保消息在队列正确地存储：交换机持久化，队列持久化,消息持久化

           <4>、确保消息从队列正确地投递到消费者：消费者手工应答

           <5>、其他实现：1、消费者回调 生产者提供一个回调的API —— 耦合，消费者也可以发送响应消息    2、补偿机制（消息的重发或者确认）    3、消息幂等性     4、消息顺序性

        RabbitMQ集群

          集群有两种节点类型，一种是磁盘节点，一种是内存节点。集群中至少需要一个磁盘节点以实现元数据的持久化，未指定类型的情况下，默认为磁盘节点。

          RabbitMQ集群的两种模式
               1）普通模式：默认的集群模式。

                    以两个节点（rabbit01、rabbit02）为例来进行说明。

                    rabbit01和rabbit02两个节点仅有相同的元数据，即队列的结构，但消息实体只存在于其中一个节点rabbit01（或者rabbit02）中。当消息进入rabbit01节点的Queue后，consumer从rabbit02节点消费时，RabbitMQ会临时在rabbit01、rabbit02间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连rabbit01或rabbit02，出口总在rabbit01，会产生瓶颈。当rabbit01节点故障后，rabbit02节点无法取到rabbit01节点中还未消费的消息实体。如果做了消息持久化，那么得等rabbit01节点恢复，然后才可被消费；如果没有持久化的话，就会产生消息丢失的现象。

 

               2）镜像模式：把需要的队列做成镜像队列。

                    在普通集群的基础上，把需要的队列做成镜像队列，消息实体会主动在镜像节点间同步，而不是在客户端取数据时临时拉取，也就是说多少节点消息就会备份多少份。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用由于镜像队列之间消息自动同步，且内部有选举master机制，即使master节点宕机也不会影响整个集群的使用，达到去中心化的目的，从而有效的防止消息丢失及服务不可用等问题

           高可用集群架构图：

          

        如何搭建高可用集群：

                      https://www.rabbitmq.com/clustering.html

                      https://my.oschina.net/genghz/blog/1840262