网站建设招标网网易企业邮箱价格

当前位置： 首页 > news >正文

网站建设招标网,网易企业邮箱价格,如何制作手机网页,平台做的h5如何嫁接到网站目录 一、RabbitMQ 集群原理 1、默认集群原理2、镜像集群原理3、负载均衡方案 二、RabbitMQ 高可用集群搭建 1、RabbitMQ 集群搭建2、配置镜像队列3、HAProxy 环境搭建4、Keepalived 环境搭建
一、RabbitMQ 集群简介 1、默认集群原理 3-1、RabbitMQ 集群简介 单台 RabbitM…目录 一、RabbitMQ 集群原理 1、默认集群原理2、镜像集群原理3、负载均衡方案 二、RabbitMQ 高可用集群搭建 1、RabbitMQ 集群搭建2、配置镜像队列3、HAProxy 环境搭建4、Keepalived 环境搭建
一、RabbitMQ 集群简介 1、默认集群原理 3-1、RabbitMQ 集群简介 单台 RabbitMQ 服务器处理消息的能力是有瓶颈的而且可靠性还无法保证所以需要通过集群来提高消息的吞吐量和提高数据可靠性。 由于 RabbitMQ 本身是基于 Erlang 编写而 Erlang 语言天生具备分布式特性通过同步 Erlang 集群各节点的 erlang.cookie 来实现。因此RabbitMQ 天然支持集群并且还能通过水平扩展节点的方式提高吞吐量。 在一个多节点的 RabbitMQ 集群中Exchange交换器的元数据Metadata信息在所有节点上都是一致的而 Queue存放消息的队列的完整数据只会存在于创建它的那个节点上其他节点只知道这个 Queue 的 Qetadata 信息和一个指向 Queue 的 owner node 的指针起到消息转发作用。 3-2、RabbitMQ 集群同步的元数据 RabbitMQ 集群会始终同步以下四种类型的内部元数据 Queue 元数据队列名称和它的属性Exchange 元数据交换器名称、类型和属性Binding 元数据一张简单的表格展示了如何将消息路由到队列VHost 元数据为 VHost 内的队列、交换器和绑定提供命名空间和安全属性 所以当用户访问其中任何一个 RabbitMQ 节点时通过 rabbitmqctl 查询到的 QueueExchange/Binding/VHost 等信息都是相同的。 3-3、为什么 RabbitMQ 集群只同步元数据 第一存储空间。如果每个集群节点都拥有所有 Queue 的完全数据那么每个节点的存储空间会非常大集群的消息积压能力会非常弱无法通过集群节点的扩容提高消息积压能力第二性能。消息的发布者需要将消息复制到每一个集群节点对于消息持久化、网络和磁盘同步复制的开销都会明显增加。 3-4、RabbitMQ 集群发布/订阅消息的基本原理 集群原理图如下 客户端消息收发有以下两种情况 客户端直接连接队列所在的节点 如果消息生产者或者消费者通过 amqp-client 的客户端连接至节点 1 进行消息的发布或者订阅那么此时的集群中的消息收发只与节点 1相关。客户端连接的是非队列数据所在的节点 如果消息生产者所连接的是节点 2 或者节点 3此时由于队列 1 的完整数据不在该两个节点上所以在发送消息时这两个节点会根据节点上队列 1 的元数据将消息转发至节点1上最终发送的消息还是会存储至节点 1 的队列 1 上这两个节点主要起了一个路由转发作用。同样如果消息消费者所连接的节点在 2 或者 3那这两个节点也会作为路由节点起到转发作用将会从节点 1 的队列 1中 拉取消息进行消费。 3-5、集群节点类型 RabbitMQ 集群节点分为磁盘节点和内存节点两种类型 磁盘节点 将配置信息和元信息存储在磁盘上单节点系统必须是磁盘节点否则每次重启 RabbitMQ 之后所有的系统配置信息都会丢失。内存节点 将配置信息和元信息存储在内存中性能是优于磁盘节点的。 RabbitMQ 要求集群中至少有一个磁盘节点当节点加入和离开集群时必须通知磁盘节点如果集群中唯一的磁盘节点崩溃了则不能进行创建队列、创建交换器、创建绑定、添加用户、更改权限、添加和删除集群节点。 总之如果唯一磁盘的磁盘节点崩溃集群是可以保持运行的但不能更改任何东西。因此建议在集群中设置两个磁盘节点只要一个可以就能正常操作。 2、镜像集群原理 2-1、镜像集群简介 RabbitMQ 在普通集群模式下可以提高消息的吞吐量但不能保证队列的高可用。尽管交换机、绑定这些可以复制到集群里的任何一个节点但是队列内容不会复制。虽然该模式解决一项目组节点压力但队列节点宕机直接导致该队列无法应用只能等待重启。 所以要想在队列节点宕机或故障时也能正常使用就要复制队列内容到集群里的每个节点这些队列就是镜像队列而镜像集群就是 RabbitMQ 集群的高可用部署方案HA方案。 RabbitMQ 镜像集群模式是在普通集群模式的基础上配置镜像队列模式来实现的换句话说就差 RabbitMQ 镜像集群依赖于普通集群所以要搭建镜像集群就需要先搭建普通集群。镜像集群模式其实就是把需要的队列做成镜像队列然后将镜像队列放在多个 RabbitMQ 节点当中。 2-2、镜像队列架构 普通队列的进程及其数据仅仅维持在单个节点上所以当其所在的节点失效后就会导致对应的队列不可用。 引入镜像队列Mirror Queue的机制可以将队列镜像到集群中的其他 Broker 节点之上如果集群中的一个节点失效了队列能够自动切换到镜像中的另一个节点上来保证服务的可用性。 每个镜像队列都包含一个主节点master和若干个从节点slave架构图如下 我们以3个 Broker 节点为例假如在节点1创建了队列1的 master 队列则会在节点2和3中各镜像一个对应的 slave 队列这些 master 队列节点和所有 slave 队列节点会形成一个循环链表结构。 由于 master 队列提供读写服务而在 slave 上的操作都会路由到 master 上slave 只做备份-主备切换所以同一个队列的负载基本上会集中在一个节点上。为了尽可能地确保各节点的负载均衡我们需要将队列的 master 节点均匀散落在集群中的各个 Broker 节点上比如队列2的 master 放在节点2而对应的 slave 则放在节点1和3上以此类推。当然每个 master 队列消息请求的数量可能会有不同无法保持绝对的负载均衡。 2-3、镜像队列的工作原理 消息的发布除了 Basic.Publish 之外与消费都是通过 master 队列完成。master 对消息进行处理的同时将消息的处理动作通过 GM 广播给所有的 slave 队列slave 队列所在的节点的 GM 收到消息后通过回调交由对应的镜像 slave 队列进行实际的处理。 而对于 Basic.Publish消息会同时发送到 master 和所有 slave 上如果此时 master 宕掉了由于消息还发送到了 slave 上这样当 slave 提升为 master 的时候消息也不会丢失。 GMGuarenteed Multicast 即可靠的组播通讯协议该协议能够保证组播消息的原子性即保证组中活着的节点要么都收到消息要么都收不到。 GM 的工作原理如下 GM 将所有的 Broker 节点形成一个循环链表每个节点都会监控位于自己左右两边的节点当有节点新增时相邻的节点保证当前广播的消息会复制到新的节点上当有节点失效时相邻的节点会接管保证本次广播的消息会复制到所有的节点。在 master 队列的节点和 slave 队列的节点上的 GM 形成一个 groupgm_groupgroup 的信息会记录在 mnesia 中不同的镜像队列形成不同的 group。消息从 master节点对应的 GM 发出后顺着链表依次传送到所有的节点由于所有节点组成一个循环链表master 队列所在的节点对应的 GM 最终会收到自己发送的消息这个时候 master 就知道消息已经复制到所有的 slave 队列了。 镜像队列间的消息流转 当消费者与 master 队列建立连接消费者可以直接从 master 队列上获取信息当消费者与 slave 队列建立连接呢消费者是从 slave 队列直接获取数据的吗当然不是的消息的流转顺序如下所示 slave 队列先将消费者的请求转发给 master 队列然后再由 master 队列准备好数据返回给 slave 队列最后由 slave 队列将消息返回给消费者。 节点失效 如果某个 slave 失效了系统处理做些记录外几乎啥都不做。master 依旧是 master客户端不需要采取任何行动或者被通知slave失效。 如果 master 失效了那么 slave 中的一个必须被选中为 master。被选中作为新的 master 的 slave 通常是最老的那个基于slave加入cluster的时间排序因为最老的 slave 与前任 master 之间的同步状态应该是最好的。需要注意的是如果没有任何一个 slave 与 master 完全同步的话那么旧 master 中未被同步的消息将会丢失。 新节点消息同步 每当一个节点加入或者重新加入例如从网络分区中恢复过来镜像队列该节点之前保存的队列内容会被清空。 将新节点加入已存在的镜像队列时默认情况下 ha-sync-modemanual镜像队列中的消息不会主动同步到新节点除非显式调用同步命令。当调用同步命令后队列开始阻塞无法对其进行操作直到同步完毕。当 ha-sync-modeautomatic 时新加入节点时会默认同步已知的镜像队列但由于同步过程的限制所以不建议在生产的消费队列中操作。 简单总结一下 镜像队列的引入可以极大地提升 RabbitMQ 的可用性及可靠性提供了数据冗余备份、避免单点故障的功能一旦 master 队列不可用最老的 slave 队列将被选举为新的 master 队列。 同时镜像队列也会带来明显的缺点由于镜像队列需要为每一个节点都要同步所有的消息实体所以会导致网络带宽压力很大。 而提供了数据的冗余备份会导致存储压力变大可能会出现IO瓶颈 3、负载均衡方案 本质上镜像队列只是有一个备份队列所以不能作为负载均衡使用。也就是说对于一个三节点的集群每个节点的负载可能都是不相同的。 我们可以通过硬件负载均衡或者软件负载均衡的方式解决这个问题这里我们选择使用软件 HAProxy 来进行负载均衡当然也可以使用其他负载均衡中间件如 LVS 等。HAProxy 同时支持四层和七层负载均衡并基于单一进程的事件驱动模型因此它可以支持非常高的井发连接数。 假如我们只采用一台 HAProxy 那么它就存在明显的单点故障的问题所以至少需要两台 HAProxy 同时这两台 HAProxy 之间需要能够自动进行故障转移常用的解决方案就是 KeepAlived 。KeepAlived 采用 VRRP Virtual Router Redundancy Protocol虚拟路由冗余协议来解决单点失效的问题它通常由一主一备两个节点组成同一时间内只有主节点会提供对外服务并同时提供一个虚拟的 IP 地址 (Virtual Internet Protocol Address 简称 VIP) 。 如果主节点故障那么备份节点会自动接管 VIP 并成为新的主节点 直到原有的主节点恢复。 最后任何想要连接到 RabbitMQ 集群的客户端只需要连接到虚拟 IP而不必关心集群是何种架构示例如下 ConnectionFactory factory new ConnectionFactory(); // 假设虚拟ip为 192.168.0.100 factory.setHost(192.168.0.100);整体架构图如下 二、RabbitMQ 高可用集群搭建 1、RabbitMQ 集群搭建 首先需要搭建 RabbitMQ 集群。 2、配置镜像队列 3、HAProxy 环境搭建 4、Keepalived 环境搭建