RabbitMQHA初步分析.docxVIP

RabbitMQ HA初步分析普通MQ的结构Rabbitmq大体上可以分为两部分（Exchange和MQ），所有发送给RabbitMQ的消息都会先交给Exchange， Exchange的功能类似于路由器，它会根据自身类型（fanout、direct、topic）以及binding信息决定一个消息该被放到哪一个MQ，而MQ的功能在于暂时存储消息，并将MQ中的消息以订阅或者poll的方式交给接收方。MQ内部大致又可以分为两部分:amqueue和backing queue,amqqueue负责实现amqp协议规定的mq的基本逻辑，backing queue则实现消息的存储，它会尽量为durable=true的消息做持久化的存储，而在内存不足时将一部分消息放入DISK换取更多的内存空间。Backing queu内部又细分为5各小Q，消息在这些Q中传递的“一般”过程q1-q2-delta-q3-q4，这几个Q实现的是“RAM -DISK-RAM”这一过程中对消息的分类管理。大多数情况下，一个消息并非需要走完每个小Q，通常大部分都可以略过。与这5各Q对应，在backing queue中消息的生命周期可以分为四个状态：Alpha：该消息的位置信息和消息本身都在RAM中，这类消息排列在Q1和Q4。Beta：消息的位置保存在RAM中，消息本身保存在DISK中，这类消息排列在Q2或Q3中。Gamma: 消息的位置保存RAM和DISK中，消息本身保存在DISK中，这类消息排列在Q2或Q3中。Delta：消息的位置和消息本身都保存在DISK中，这类消息排列在delta中。从Q1-Q2-delta这一个过程是将消息逐步从RAM移动到DISK的过程，而delta-Q3-Q4是从DISK逐步移动到RAM的过程。通常在负载正常时，一个消息不会经历每种状态，如果消息被消费的速度不小于接收新消息的速度，对于不需要保证可靠不丢的消息极可能只会有Alpha状态。对于durable=true的消息，它一定会进入gamma，若开启publish confirm，只有到了这个阶段才会确认该消息已经被接收，若消息消费的速度足够快，内存也充足，这些消息也不会继续走到下一状态。从上述backing queue对消息的处理过程可以看出，消息若能尽早被消费掉即在不要走完这5个队列，尽量在q1或q2中就被消费掉，就能减少系统的开销。若走的“太深”则会有内存的换入换出增加系统开销。这样就存在一个问题：通常在系统负载较高时，已接收到的消息若不能很快的被消费掉，这些消息就会进入到很深的队列中去，增加处理每个消息的平均开销。因为要花更多的时间和资源处理“积压”的消息，所以用于处理新来的消息的能力就会降低，使得后来的消息又被积压进入很深的队列，继续加大处理每个消息的平均开销，这样情况就会越来越恶化，使得系统的处理能力大大降低。根据官方博客，应对这一问题，有三个措施：进行流量控制。增加prefetch的值，即一次发送多个消息给接收者，加快消息被消费掉的速度。才有mutliack，降低处理ack带来的开销。目前RabbitMQ已经有了很好的流量控制机制，通过前面多次的测试，在测试过程中观察到的现象是，MQ中堆积的消息数一直都很少（低于5个）。需要使用者做的就是2，3两点。镜像MQ的结构mirror queue基本上就是一个特殊的backing queue，它内部包裹了一个普通的backing queue做本地的消息持久化处理，在此基础上增加了将消息和ack复制到所有镜像的功能。所有对rabbit_mirror_queue_master的操作，会通过组播GM（Guarenteed Multicast）的方式同步到各slave节点。新节点加入允许新的slave节点中途加入到集群中，新加入的slave节点并不同步master节点的所有在该slave加入之前存在的消息，只对新来的消息保持同步，随着旧的消息被消费，经过一段时间后，slave节点就会与master节点完全同步。节点失效当master节点失效后，所有slave中消息队列最长者会成为新的master，因为这样的节点最有可能与原来的master节点完全同步。节点重启当一个节点无论master还是slave失效后重启，都会丢弃本地记录在disk中的所有消息，作为一个全新的slave节点加入到集群中去。GMGM模块实现的一种可靠的组播通讯协议，该协议能够保证组播消息的原子性，即保证组中活着的节点要么都收到消息要么都收不到。它的实现大致如下：一个组的所有成员组成一个ring，例如 A-B-C-D-A。假如A是master节点，A要发组播消息，A首先会将消息发送到A的后继节点B，B接收到消息后在传递给C然后是D，最后D再发给A。在此过程中若有节点失效，