5.RabbitMQ实战 --- 集群并处理失败_rabbitmq安装完成善后处理失败

5.1 开足马力：RabbitMQ集群
	让rabbitmq变成高可用性的2种方法：
		1.设置rabbit集群
		2.扩展程序的规模以提升性能
 
	rabbitmq 内建集群的设计用于完成2个目标：
		1.允许消费者和生产者在rabbit集群节点崩溃的情况下继续运行
		2.通过添加更多的节点来线性扩展消息通信吞吐量
 
	rabbitmq通过Erlang 提供的开放电信平台(Open Telecom Platform,OTP)分布式通信框架来巧妙的解决上面2个问题。当你失去一个rabbit节点，同时
  客户端能够重新连接到急群众的任意其他节点并继续生产或者消费消息，就像什么都没发生过一样。
 
    当一个rabbit集群几点崩溃时，该节点上队列的消息也会消失，这是因为rabbit默认不会将队列的内容复制到整个集群上。如果不进行特殊的配置，这些消息
  仅存在于队列所属的那个节点上。
 
5.2 集群架构
	rabbitmq 会始终记录以下4种类型的内部元数据：
		1.队列元数据---队列名称和它们的属性(是否可持久化，是否自动删除)
		2.交换器元数据---交换器名称，类型和属性(可持久化等)
		3.绑定元数据---一张简单的表格展示了如何将消息路由到队列
		4.vhost元数据---为 vhost 内的队列，交换器和绑定提供命名空间和安全属性
 
	在单一节点内，rabbitmq会将所有的这些信息存储到内存中，同时将那些标记位可持久化的队列和交换器(以及它们的绑定)存储到磁盘上。存储到磁盘上可以确保队列
  和交换器在重启rabbit节点后重新创建。当你引入集群时，rabbitmq需要重新追踪新的元数据类型：集群节点位置，以及节点与已记录的其他类型元数据的关系。集群也提供
  了选择：将元数据存储到磁盘上(独立节点的默认设置)，或者仅存储在 RAM 中。
 
  5.2.1 集群中的队列
  	在将2个节点组成集群的那一刻，事情将发生巨大的变化 ：不是每一个节点都有所有队列的完全拷贝。在单一节点设置中，所有关于队列的信息(元数据，状态和内容)都完全存储
  在该节点上。但是如果在集群中创建队列的话，集群只会在单个节点而不是所有节点上创建完整的队列信息(元数据，状态，内容)。结果是只有队列的所有者节点知道队列的所有信息。
  所有其他非所有者节点只知道队列的元数据和指向该队列存在的那个节点的指针。因此，当集群节点崩溃时，该节点队列和管理的绑定就都消失了。附加在那些队列上的消费者丢失了其
  订阅信息，并且任何匹配该队列绑定信息的新消息也都丢失了。
    别担心，你可以让消费者重新连到集群并重新创建队列。这种做法仅当队列最开始没有被设置成可持久化时才是可行的。如果重新创建的队列被标记为持久化了，那么在其他节点重新声明
  它们的话就会得到一个404 NOT_FOUND 错误。这样确保了当节点失败恢复后加入集群，该节点上的队列消息不会丢失。想要该指定队列重回集群的唯一方法是恢复故障节点。但是如果消费者
  尝试重建的队列是不可持久化，那么重新声明就会成功，你可以准备重新绑定它们并传输数据。
 
    为什么默认情况下rabbitmq不将队列内容和状态复制到所有的节点上呢？
    	1.存储空间
    	2.性能 : 消息的发布需要将消息复制到哪个节点上。对于持久化的消息来说，每一条消息都会触发磁盘活动。
 
    通过设置集群中的唯一节点来负责任何特定队列，只有该负责节点才会因队列消息而遭受到磁盘活动的影响。其他所有的节点需要将接收到的该队列的消息传递给该队列的所有者节点。因此，
  往rabbit集群添加更多的节点意味着你讲拥有更多的节点传播队列，这些新增的节点为你带来了性能的提升。
 
  5.2.2 分布交换器
  	事实上，不同于队列那样拥有自己的进程，交换器说到底只是一个名称和一个队列绑定列表。当你的消息发布到交换器时，实际上是由你所连接到的信道将消息上的路由键同交换器的绑定列表
  进行比较，然后路由消息。正是信道按照绑定匹配的结果，将消息路由到队列。这是为什么呢？理解信道是真正的路由器这一点很重要，因为这解释了为什么交换器不会像集群中的队列那样受到
  相同的限制。
 
    注意：
    	理解rabbitmq 背后的消息路由工作机制的方法是把每个队列想象成节点上运行的进程，每个进程拥有自己的进程ID(PID)。交换器不过是路由模式列表和匹配消息应发往的队列进程ID
      的列表。当发布的消息匹配了交换器中的绑定规则时，实际上是由信道完成了匹配工作，并在匹配之后建立到队列PID的连接，然后将消息传送过去。队列的进程ID本质上是在集群中的
      erlang 地址。
 
    由于交换器只不过是一张查询表，而非实际上的消息路由器，因此将交换器在整个集群中进行复制会更加简单。举例来说，当创建一个新的交换器时，rabbitmq所要做的是将查询表添加到
  集群中的所有节点上。这时，每个节点上的每条信道都可以访问新的交换器了。因此，相对于默认情况下队列的完整信息存储于集群中的单一节点来说，集群中的每个节点拥有每个交换器的
  信息。就可用性来说，这非常棒，因为这意味着你不用担心在节点故障时重新声明交换器。只需要让故障的节点上的生产者重新连接到集群上，它们就能立即开始往交换器上发布消息了。
 
    AMQP的 basic.publish 命令不会返回消息的状态。这意味着当前信道节点崩溃时信道仍然可能在路由消息，而生产者已经继续创建下一条消息了。在这种情况下，你将承受丢失消息
  的风险。解决的方法是使用 AMQP 事务，在消息路由到队列之前它会一直阻塞；或者使用发送方确认模式来记录连接中断时尚未被确认的消息。
 
  5.2.3 是内存节点还是磁盘节点
  	每个rabbitmq节点，不管是单一节点系统或者是庞大集群的一部分，要么是内存节点，要么是磁盘节点。内存节点将所有的队列，交换器，绑定，用户，权限和vhost的元数据定义都仅存储
  在内存中。而磁盘节点则将元数据存储在磁盘中。单节点系统允许磁盘类型的节点；否则，每次你重启rabbit之后，所有关于系统的配置信息都会丢失。不过在集群中，你可以选择配置部分节点
  为内存节点。因为它使得队列和交换器声明之类的操作更加快速。
    当在集群中声明队列，交换器或者绑定的时候，这些操作会直到所有集群节点都成功提交元数据变更之后返回。对于内存节点来说，这意味着变更写入内存；对于磁盘节点来说，这意味着
  昂贵的磁盘写入操作，直到完成之后，节点才能说：'完事了'。假设你有5个节点的集群，并且所有节点都是磁盘节点，则你必须得等待所有这5个节点将元数据写入磁盘后，队列声明操作
  才能返回。对于队列长存的服务器来说没什么。但如果你正在处理繁重的rpc呢？如果每个rpc客户端正创建和销毁每秒数以百计的应答队列，你就会明白磁盘节点会降低性能。内存节点可以提供
  出色的性能，和磁盘节点能够保障集群配置信息免于重启。
    rabbit只要求在集群中至少有一个磁盘节点，所以其他节点都可以是内存节点，记住，当节点加入或者离开集群时，它们必须要将变更通知到至少一个磁盘节点。如果只有一个磁盘节点，
  而且不凑巧的是它又刚好崩溃了，那么集群可以继续路由消息，但是不能做以下的操作：
  	1.创建队列
  	2.创建交换器
  	3.创建绑定
  	4.添加用户
  	5.更改权限
  	6.添加或者删除集群节点
 
  	换句话说，如果集群中唯一的磁盘节点崩溃的话，集群仍然可以保持运行，但是直到该节点恢复到集群之前，你无法更改任何东西。解决方案是在集群中设置2个磁盘节点，因此它们中至少
  有一个是可用的，能够在任何时刻保持元数据的变更。只有一个需要所有的磁盘节点必须在线的操作是添加或者删除集群节点。当内存节点重启后，它们会连接到预先配置的磁盘节点，下载
  当前集群元数据拷贝。如果你只将2个磁盘节点中的一个告诉了内存节点，而不凑巧的是当前内存节点供电中断时该磁盘节点页发生故障的话，那么内存节点在重启之后就无法找到集群节点了。
  所以当添加内存节点时，确保告知其所有的磁盘节点(内存节点唯一存储到此的元数据信息是机器中磁盘节点的地址)。只要内存节点可以找到至少一个磁盘节点，那么它就能在重启后重新
  加入集群。

 

  Rabbit集群的四种方式：单主集群、普通集群、镜像集群、主从集群
 
  1.单机集群：就是在一台物理机器上启动多个节点，每个节点作为作为集群的一部分。此种方式只适合在学习的时候玩一下，
	或者在验证在生产环境中出现特殊情况的现象，在实际情况下不会使用单机集群，因为如果服务器宕机了整个服务器将完全不能再使用.
  
  2.普通集群：这里指的每台物理机器作为一个节点，此种模式消息只存在其中一个节点上，集群中的其他节点仅有相同的元数据(即队列元数据)，
    当拥有消息的节点宕机了，那么其他节点就无法获取故障节点中尚未消费的消息，如果故障节点使用了持久化，那只能等故障节点恢复后才能从该节点上的队列进行消费，
    如果没有持久化，那么所有消息将丢失。例如消费者A连接到节点1，但是队列内容并不在节点1上，可以通过消费者所消费的队列找到该队里所在的节点，
    然后从该节点上获取消息，返回给消费者。
 
  3.镜像集群：与普通集群不同，镜像集群会把对垒结构和消息都同步到每个节点。该模式的好处就是随便连接到哪个节点都能获取到消息，
    坏处是，当队列数量很多，消息也很多的时候，集群内部的网络带宽将会被这种同步通讯大量的消耗掉，此种模式用于可靠性要求较高的场合中。
 
  4.主从集群warren: 是指一对主备独立服务器，并设置一台负载均衡器来处理故障转移，使用HAproxy设置备用服务器很简单,
    使用backup来标记一下，只有当主服务器不可用时才使用备用服务器。
 
   每5秒对服务器进行健康检查，后台服务器失败3次之后被认为不可用，也就是15秒后消费者会连接到备用服务器。
 
   内存节点RAM和磁盘节点disk :
   	1.内存节点：将所有的队列、交换机、绑定、用户、权限、vhost的元数据都存储在内存中 。内存节点更快
   	2.磁盘节点：将数据存放在磁盘上。磁盘节点需要保存集群的配置信息
 
      单节点系统只允许磁盘节点，否则每次重启所有数据将会丢失。 一个集群至少有一个节点是磁盘节点，其他节点可以都是内存节点，
    当节点加入或者离开集群时都要将变更通知到至少一个磁盘节点。实际使用时至少要两个磁盘节点，原因是如果只有一个磁盘节点，恰巧磁盘节点崩溃了，
    那么RabbitMQ将不能创建队列、创建交换机、创建绑定、添加用户、更改权限、添加或删除节点等操作，可以正常的发布和消费消息。 
    在实际使用经常将集群的配置放到磁盘节点上来保存。
 
 
单机集群搭建详细步骤 : 
	1.第一步：为每个节点配置节点名称和端口号
		1. RABBITMQ_NODE_PORT=5672 RABBITMQ_NODENAME=rabbit@localhost /usr/lib/rabbitmq/bin/rabbitmq-server
 
		2. RABBITMQ_NODE_PORT=5673 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15673}] -rabbitmq_stomp tcp_listeners [61614] -rabbitmq_mqtt  tcp_listeners [1884]" RABBITMQ_NODENAME=rabbit1@php-server /usr/lib/rabbitmq/bin/rabbitmq-server -detached
 
		3. RABBITMQ_NODE_PORT=5674 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15674}] -rabbitmq_stomp tcp_listeners [61615] -rabbitmq_mqtt tcp_listeners [1885]" RABBITMQ_NODENAME=rabbit2@localhost /usr/lib/rabbitmq/bin/rabbitmq-server -detached
 
	2.安装 rabbit web UI
	rabbitmq-plugins enable rabbitmq_management
 
	http://server_ip:15672/
 
	3.将rabbit1加入到rabbit中
	// 加入集群时可以指定是磁盘模式还是内存模式，默认是disk，可以通过--ram来指定
	rabbitmqctl -n rabbit1@MacOSX stop_app
	rabbitmqctl -n rabbit1@MacOSX reset
	rabbitmqctl -n rabbit1@MacOSX join_cluster rabbit@MacOSX
	rabbitmqctl -n rabbit1@MacOSX start_app
 
	// 查看指定节点的状态 
	rabbitmqctl status -n rabbit1
 
	4.将rabbit2加入到rabbit中
	rabbitmqctl -n rabbit2@MacOSX stop_app
	rabbitmqctl -n rabbit2@MacOSX reset
	rabbitmqctl -n rabbit2@MacOSX join_cluster rabbit@MacOSX --ram
	rabbitmqctl -n rabbit2@MacOSX start_app
 
	// 查看集群的状态
	rabbitmqctl cluster_status -n rabbit@MacOSX
 
 

 

 

 

5.1 开足马力：RabbitMQ集群

5.2 集群架构

 

5.3 在你的笔记本上设置集群
    

5.4 将节点分布到更多的机器上