RabbitMQ-模式、集群、故障恢复

MQ并不是在寻找一个消息队列，而是解决解耦问题的方法。本质为：解耦请求和操作； 从同步编程模型转向异步编程模型。

解决Rabbit相关问题 编码与模式

---

解耦

1. 分离请求和动作 – kfc订单和取餐
2. 提供扩展性： 不用负载均衡器
   
   1. 当处理服务无法负载时，可通过添加处理服务器，而不用负载均衡，得益于RabbitMQ自动轮询行为
3. 零成本API：跨语言

发后即忘模型

关注任务的完成，但无须实时完成。用无须应答的消息来触发工作
匹配该模式的两种一般类型任务：
    批处理： 针对大型数据集合的工作或转换
    通知： 对发生事件的描述

用RabbitMQ实现RPC并等待响应

私有队列和发送确认：  消息头的reply_to字段

集群并处理失败

---

RabbitMQ高可用性的两种方法
    1. 设置Rabbit集群
    2. 扩大程序的规模以提升性能
RabbitMQ 的内建集群 的目标：
    允许消费者和生产者在Rabbit节点崩溃的情况下继续运行。
    通过添加更多节点来线性扩展消息通信吞吐量。

集群架构

RabbitMQ始终记录的四种类型的内部元数据：
    队列元数据 - 队列名称和他们的属性
    交换器元数据 - 交换器名称、类型和属性
    绑定元数据  - 一张简单的表格展示了如何将消息路由到队列
    vhost元数据 - 为vhost内的队列、交换器、绑定提供命名空间和安全属性。

构建集群式，RabbitMQ会追踪新的元数据类型： 集群节点位置，以及节点与已记录的其他类型元数据的关系。
1. 集群中的队列：
只有队列所有者节点知道有关队列的所有信息。所有其他非所有者节点只知道队列的元数据和指向该队列存在的那个节点的指针。
节点崩溃，集群就与之失去了联系。新消息也就丢失了。让指定队列重回集群的唯一方式是 恢复故障节点。
默认情况下RabbitMQ不将队列内容和状态复制到所有节点原因：
a. 存储空间
b. 性能： 消息发布时消息会到每个集群节点，都会触发一次磁盘活动。
往Rabbit集群添加更多的节点意味着你将拥有更多的节点来传播队列。 因为所有其他节点需要将接收到的该队列的消息传递给该队列的所有者节点。
2. 分布交换器
交换器只是名称和队列的绑定列表。信道按照绑定匹配的结果，将消息路由到队列。
创建新的交换器时，RabbitMQ会将查询表添加到集群中的所有节点上。这样每个节点上的每条信道都可以访问到新的交换器了。
当消息已经在发布信道上，但在路由完成之前节点发生故障的话，为避免生产者一直生产消息，造成消息丢失的风险。处理方式：
a. 使用amqp事务。
b. 使用发送方确认模式来记录连接中断时尚未被确认的消息。
3. 是内存节点还是磁盘节点
每个RabbitMQ节点，要么是内存节点，要么是磁盘节点。 内存节点将所有的队列、交换器、绑定、用户、权限和vhost的元数据定义都存储在内存中。而磁盘节点将元数据存储在磁盘中。单节点系统只允许磁盘类型的节点。在集群中，可选择配置部分节点为内存节点。
RabbitMQ要求集群中至少有一个磁盘节点。但是如果只有一个节点的话，如果这个节点崩溃了，集群仍然可以保持运行。但是在该节点恢复前你无法更改任何东西。通常会在集群中设置两个磁盘节点。保证只要一个可用。
如果磁盘节点故障的话，内存节点重启后就无法找到集群了，所以当添加内存节点时，确保告知其所有的磁盘节点（内存节点唯一存储 到磁盘的元数据信息是集群中磁盘节点的地址）

升级集群节点

独立系统中升级到最新版RabbitMQ很容易，只需解压新版并运行即可，旧的数据会被保留。

集群升级并不简单，他的升级是半自动化的。如果简单升级会抹去集群上的所有配置和数据。
升级步骤：
    1 备份当前配置
    2 关闭所有生产者并等待消费者消费完队列中的所有消息。
    3 关闭节点，并解压新版本到现有安装目录
    4 选择其中一个磁盘节点作为升级节点
    5 其启动时，该节点会持久化集群数据升级到新版本
    6 启动其他集群磁盘节点，会获取升级后集群数据
    7 启动集群内存节点。

镜像队列和保留消息

RabbitMQ2.6.0之后有了内建的双话冗余选项：镜像队列； 镜像队列的主拷贝仅存在于一个节点上，并可在其他节点拥有从队列拷贝。主节点不可用时，最老的从节点会被选举成新的主队列。
声明并使用镜像队列
声明：
queue_args={"x-ha-policy": "all"}
channel.queue_declare(queue="queuename", arguments=queue_args)
上面是在所有节点都建一个从节点。建议使用all
queue_args={"x-ha-policy" : "nodes",
"x-ha-policy-params" :["rabbit@xxx"]}
这个会在指定节点上见从节点，或造成该节点挂了，就声明不成功了。
工作原理：
信道将消息发送到镜像队列时，会将消息同时发送的从队列。类似于fanout节点。
消费者取消。
对于消费但未返回确认的消息，会重新入队。

从故障中恢复

---

构建弹性消息通信基础架构的两部分：
1. 构建RabbitMQ集群来确保可用性和性能
2. 编写当节点发生故障时知道如何重连到集群的应用程序。
通过负载均衡来处理重连到集群：
1. 可以减少应用程序处理节点故障代码的复杂性
2. 确保在集群中链接的平均分布

将负载均衡器放置到Rabbit集群的前端，你就可以让它来处理节点选择、故障服务器检测以及负载分布这些复杂的事情了。
使用HAProxy做负载均衡

连接丢失和故障转移
当故障转移到新的节点时，你无法对集群的状态做任何假定。不管节点故障什么时候发生，在检测到故障并进行重连之后的首要任务是构造交换器、队列和绑定，以便应用程序的运作。