❶ 全面分析核心路由器性能指标_思科路由器性能指标
全面分析核心路由器性能指标 副标题：
作者：佚名 文章来源：NET130 点击数： 41 更新时间：2009-12-3 9:17:41
我国的核心路由器发展非常迅速的，这里我们主要介绍核心路由器十项性能指标，包括介绍核心路由器的吞吐量等方面。说到核心路由器的性能，不妨我先给大家简单的介绍一下什么是路由器，路由器是用来做什笑敬么的！
路由器是一种连接多个网络或网段的网络设备，它能将不同网络或网段之间的数据信息进行“翻译”，以使它们能够相互“读”懂对方的数据，从而构成一个更大的网络。核心路由器有两大典型功能，即数据通道功能和控制功能。数据通道功能包括转发决定、背板转发以及输出链路调度等，一般由特定的硬件来完成；控制功能一般用软件来实现，包括与相邻核心路由器之间的信息交换、系统配置、系统管理等。 多少年来，核心路由器的发展有起有伏。90年代中期，传统路由器成为制约因特网发展的瓶颈。ATM 交换机取而代之，成为IP 骨干网的核心，核心路由器变成了配角。进入90年代末期，Internet 规模进一步扩大，流量每半年翻一番，ATM 网又成为瓶颈，路由器东山再起，Gbps 路由交换机在1997年面世后，人们又开始以碰腊慎Gbps 路由交换机取代ATM 交换机，架构以核心路由器为核心的骨干网。相信大家已经对路由器的概念基本了解，那么下面我们就说说核心路由器十项性能指标：
高速路由器的系统交换能力与处理能力是其有别于一般路由器能力的重要体现。目前，高速路由器的背板交换能力应达到40Gbps 以上，同时系统即使暂时不提供OC-192/STM-64接口，也必须在将来无须对现有接口卡和通用部件升级的情况下支持该接口。在设备处理能力方面，当系统满负荷运行时，所有接口应该能够以线速处理短包, 如40字节、64字节，同时，高速路由器的交换矩阵应该能够无阻塞地以线速处理所有接口的交换，且与流量的类型无关。
指标之一：
吞吐量
吞吐量是核心路由器的包转发能力。吞吐量与路由器端口数量、端口速率、数据包长度、数据包类型、路
由计算模式（分布或集中）以及测试方法有关，一般泛指处理器处理数据包的能力。高速路由器的包转发能力至少达到20Mpps 以上。吞吐量主要包括两个方面：
1. 整机吞吐量
整机指设备整机的包转发能力局则，是设备性能的重要指标。路由器的工作在于根据IP 包头或者MPLS 标记选路，因此性能指标是指每秒转发包的数量。整机吞吐量通常小于核心路由器所有端口吞吐量之和。
2. 端口吞吐量
端口吞吐量是指端口包转发能力，它是核心路由器在某端口上的包转发能力。通常采用两个相同速率测试接口。一般测试接口可能与接口位置及关系相关，例如同一插卡上端口间测试的吞吐量可能与不同插卡上端口间吞吐量值不同。
指标之二：路由表能力
路由器通常依靠所建立及维护的路由表来决定包的转发。路由表能力是指路由表内所容纳路由表项数量的极限。由于在Internet 上执行BGP 协议的核心路由器通常拥有数十万条路由表项，所以该项目也是路由器能力的重要体现。一般而言，高速核心路由器应该能够支持至少25万条路由，平均每个目的地址至少提供2条路径，系统必须支持至少25个BGP 对等以及至少50个IGP 邻居。
指标之三：背板能力
背板指输入与输出端口间的物理通路。背板能力是核心路由器的内部实现，传统核心路由器采用共享背板，但是作为高性能路由器不可避免会遇到拥塞问题，其次也很难设计出高速的共享总线，所以现有高速核心路由器一般采用可交换式背板的设计。背板能力能够体现在路由器吞吐量上，背板能力通常大于依据吞吐量和测试包长所计算的值。但是背板能力只能在设计中体现，一般无法测试。
指标之四：丢包率
丢包率是指核心路由器在稳定的持续负荷下，由于资源缺少而不能转发的数据包在应该转发的数据包中所占的比例。丢包率通常用作衡量路由器在超负荷工作时核心路由器的性能。丢包率与数据包长度以及包发送频率相关，在一些环境下，可以加上路由抖动或大量路由后进行测试模拟。
指标之五：时延
时延是指数据包第一个比特进入路由器到最后一个比特从核心路由器输出的时间间隔。该时间间隔是存储转发方式工作的核心路由器的处理时间。时延与数据包长度和链路速率都有关，通常在路由器端口吞吐量范围内测试。时延对网络性能影响较大, 作为高速路由器，在最差情况下, 要求对1518字节及以下的IP 包时延均都小于1ms 。
指标之六：背靠背帧数
背靠背帧数是指以最小帧间隔发送最多数据包不引起丢包时的数据包数量。该指标用于测试核心路由器缓存能力。具有线速全双工转发能力的核心路由器，该指标值无限大。
指标之七：时延抖动
时延抖动是指时延变化。数据业务对时延抖动不敏感，所以该指标通常不作为衡量高速核心路由器的重要指标。对IP 上除数据外的其他业务，如语音、视频业务，该指标才有测试的必要性。
❷ 路由器三层交换的原理是怎样的
一、什么是三层交换机
在92年，就已经有三层交换机诞生，那么到底什么是三层交换机呢？在早期，人们想把二层交换和三层路由功能结合在一台设备上，以减少 设备数量。那时第三层交换是基于软件的，转发速度很慢，后来才发展到以硬件来实现三层交换。从今天来看，三层交换机实质就是一种特殊的路由器，是一种在性能上侧重于交换（二层和三层），有很强交换能力而价格低廉的路由器。它以ASIC实现IP包的三层交换，其交换能力都在MPPS以上，而传统的路由器一般不超过10万包/秒（这里指的是单块板的转发能力，不是指采用分布式转发情况多块板的总的转发能力，也不包括现在采用昂贵的网络处理器构成的GSR等，此外现在有更高速CPU推出，但也很难超过1MPPS 【3】）。网络处理器价格高昂在于它除了三层交换部分本身比较复杂外，它还有很强的QOS，POLICY等功能。以IBM的Rainer处理器为例：它的 硬件可管理上千个流，软件配置不同流的带宽，内嵌 PowerPC 处理器； 拥有大量的协处理器和硬件加速器，可以并行地处理数据。而三层交换机的转发部分为了降低成本，根本不可能线速支持上千个流并有能力进行带宽分配。原来有人有一种观点，那就是用最长匹配实现大路由表查找的CAM很贵，换句话说用硬件来实嫌物现大路由表的最长匹配搜索成本很高，从调查资料来看，这种观点看来并不一定对。路由表的搜索采用CAM实现成本也并不高。以 Kawasaki LSI公司的支持最长匹配搜索的的CAM芯片KE5BLME064为例，它支持64K的路由前缀项，每个ENTRY 40bit 宽，包搜索速度可达6.7Mpps，时延为数百个纳秒，而价格不到60美元【6】。当然减少支持的路由表项无疑能降低成本，而且就三层交换机通常的应用环境来看不需要太多的路由表项，因此一般三层交换机支持的路由表项比GSR要少，例如CISCO 4000系列只支持到16K--32K路由表项，北电的ACCLER 1000支持32K。不过CISCO应用芹袜液在6500系列上的SUPER ENGINES 2已经支持到128K，已经可以和骨干网路由器的表项相当了。CISCO设计的转发引擎上支持的路由表越来越大和CISCO考虑到三层交换机往城域网和骨干网上应用有关。总的来看，网络处理器之所以贵，应该还是贵在它的灵活性上，贵在支持QOS，POLICY，以及多种协议，尤其是有些协议还没有完全角成标准，网络处理器可能只需修改软件就可以支持（多数三层交换机就有困难，这也导致有很多厂家早期三层交换机与现在的协议不兼容），网络处理器要对包内容进行更多的识别，更复杂的调度，为了达到线速处理，里面常集合多个微引擎，支持多线程处理。这些也许才是导致网络处理器价格急剧上升的主要原因。相比起来三层交换机在这方面能力就很弱，例如CISCO 6000系列只支持16个QOS队列，4000只支持一个，5500支持两个，而Extreme的 三层引擎只支持4个队列。
因为是采用硬件实现三层交换，所以交换速度能做到很高，但要想同时支持大量三层协议，如IP,IPX，AppleTalk,DECnet等等，这些协议的封包格式不一样，用软件实现起来容易，用硬件实现却非常困难，用硬件实现转发的协议太多，只会带来成本的急剧上升，因此三层交换机上一般只考虑支持较为常用的IP，IPX协议，IP多播。也有的三层交换机支持其它的，但那是用软件实现的，转发速率较低，例如 CISCO 的CATALYST 6000系列就在MSFC上用软件实现AppleTalk等，转发速率在10万－20万包/秒【4】。
三层交换机现在主要提供以太网接口。以太网技术简单，价格低廉，在企业网里应用最为普遍，三层交换机采用以太网接口，能为企业网提供廉价而高速交换的设备，替代价格高昂而性能却上不去的的路由器好肢。三层交换机的ASIC同时提供IP的二层和三层交换，把原来二层以太网交换机和路由器的功能熔为一体，极大的降低了用户的成本。随着宽带业务的兴起，三层交换机的应用范围不断拓展，尤其是GE和10G以太网技术的迅速发展，导致三层交换机从企业网已经逐步走向了城域网，而应用范围的拓展也促进了其设计的革新。例如原来在三层交换机广泛采用的是CACHE技术，在三层交换机往城域网和骨干网上应用时，业务流无规则性越来越强，网络拓扑变更也有增加，因为视频语言业务的增加，QOS等也有需求，采用这种技术的弊病越来越明显；三层交换机在向城域网和骨干网上发展时要求三层交换机需要支持的协议也越来越多，如有的厂家三层交换机已经支持OSPF, BGP，MPLS等协议，有的甚至采用可编程ASIC,支持IPV6。
三层交换机上支持的接口种类也越来越多，有的已经支持广域网口，例如CISCO 6000系列就提供广域网模块 flexWAN，可提供各种广域网接口。如ATM ，POS，帧中继,PPP等。但这部分也是和传统路由器一样，用软件来处理的, flexWAN上有两个263M的RM7000处理器来处理这些广域网接口协议，接口速度上不去，目前只支持到OC-3 ATM或OC-3 POS。这些广域网接口的适配器和CISCO 7200/7500系列兼容； 但可以肯定，如果你想在三层交换机上选用广域网接口，那和普通路由器上的广域网接口价格应该差不多，因为在接口上采用的技术是一样的。但这样一来，三层交换机导致了一向引以提供广域网接口而作为卖点的诸如CISCO 7000这类路由器就鲜有出路，有评论说这类路由器正在走向终结。
三层交换机一般不支持广域网口还有一个原因就是因为不同的广域网口，其MTU可能不一样，这样如果要达到线速转发的话，就必须在硬件上支持分片，这会导致设计很繁琐，目前的三层交换机都不支持分片，而交换机上全部采用以太网接口就不存在这一问题。 但这些厂家只是为了增强三层交换机的卖点而提供的多种广域网接口和协议模块，不能从硬件上就提供二层高速转发，而纯利用三层交换机的三层交换交换功能，不能充分发挥三层交换机的功能。增加广域网接口有个好处就是如果三层交换机需要和广域网相连上internet的话，就比较灵活，不一定在出口处非加一级路由器，而目前很多厂家三层交换机对广域网口不支持，结果在组网时上连internet都要增加一个路由器，当然这里不完全是因为接口的原因，还有这些三层交换机支持协议有限，例如不支持BGP协议，支持的路由表项不足，防火墙功能不完善有关系。
三层交换机根据应用场合分多种档次，性能和价格都不一样，不能一概而论。在城域网甚至骨干网上应用的三层交换机，要求在三层交换机上增加的功能也多，性能的提高伴随着设计复杂度的增大，必然带来价格的上升，特别高端的三层交换机实际就和GSR没有区别了。应该说，如果达到这个档次的三层交换机实际已经不能叫三层交换机，就象JUNIPER的高端路由器一样，它的主要部件都是以ASIC设计的，我们称之为三层交换机也不是不可以，但它的ASIC实现的功能太复杂，太强大，价格很高昂，还是称之为高端路由器更合适。通常的三层交换机之所以被称为交换机就是因为它的功能有限，主要以面向交换为目的，所以才称之为交换机。它的设计主要以面向企业网和城域网而设计的，在这个层面上需求的数量达，对这个层面上的用户而言，在达到满足主要性能的前提下，成本是最重要的考虑因素，它以够用为准则，不强调在三层交换机上实现过多的协议，提供过多根本用不上的功能【5】。例如，在三层交换机上实现很强大的QOS，支持BGP协议等，这些在绝大多数用户那儿实际并没有用处。在目前国内建设城域网时，它实际也不一定要考虑太多QOS，目前主要还是上NTERNET。这实际也符合中国的国情，就拿视频点播来说，在中国租一张盘片只需一两块钱甚至几角钱，VCD机在城市用户几乎普及，有多少人愿意去点播呢？
理解三层交换机的应用范围和要达到低成本的要求，就能理解为什么三层交换机在Cos,POLICY等方面功能较弱，主要提供以太网口，支持有限服务，有限协议，有限路由功能。三层交换机主要提供以太网接口，各种速率的以太网接口其帧格式都相似，很容易用硬件实现二层的高速转发，一般其二层转发功能远远超过三层功能，很多三层交换机二层转发能力都在100MPPS，而三层转发能力只有几个MPPS。GE和10GE以其低廉的价格，为三层交换机在广域网上的应用提供了很好的条件。
三层交换机在交换网上采用的技术和路由器都一样，没有什么差别。例如CISCO 6500系列就采用CROSS BAR技术。
❸ 宽度优先搜索策略中的open表具有什么特点
宽度优先搜索策略中的open表是一个队列，具有先进先出的特点。这意味着搜索的时候先将起点放入皮大链队燃孙首，然后把与起点相连的节点加入队尾。接着从队首取出一个节点，再将与该节点相连的未访问过的节点加入队尾，直到队列为空。这种特点有以下原因：如果使用宽度优先搜索算法，则应该先搜索起点旁边的节点，然后再搜索更远的节点。若队列是先进后出，则搜索起点时会先遍历较远的节点，这样不便于对搜索区域进行清晰的划分。而当队列是先进先出的时候，搜索时会先遍历距离起点最近的节点，这样搜索范围可以更加精确的缩小。因此开放表的先进先出的特性非常适合用于宽度优先搜索算法。仿袭此外，使用开放表队列也有利于空间的占用。如果使用堆这样的其他数据结构来维护开放队列，则可能需要存储额外的信息来保证节点能够进行有效的排序，增加了存储开销。而队列的实现相对简单，可以以低内存占用为代价，允许较高的运行时间，同时减少了排序过程中关于节点信息的存储和比较的复杂度。
❹ 消息队列之RabbitMQ-分布式部署
RabbitMQ分布式部署有3种方式：
Federation与Shovel都是以插件的形式来实现，复杂性相对高，而集群是RabbitMQ的自带属性，相对简单。
这三种方式并不是互斥的，可以根据需求选择相互组合来达到目的。
RabbitMQ本身是基于Erlang编写，Erlang语言天生具备分布式特性（通过同步Erlang集群各节点的magic cookie来实现）。
因此，RabbitMQ天然支持Clustering。这使得RabbitMQ本身不需要像ActiveMQ、Kafka那样通过ZooKeeper分别来实现HA方案和保存集群的元数据。集群是保证可靠性的一种方式，同时可以通过水平扩展以达到增加消息吞吐量能力的目的。
我们把部署RabbitMQ的机器称为节点，也就是broker。broker有2种类型节点： 磁盘节点 和 内存节点 。顾名思义，磁盘节点的broker把元数据存储在磁盘中，内存节点把元数据存储在内存中，很明显，磁盘节点的broker在重启后元数据可以通过读取磁盘进行重建，保证了元数据不丢失，内存节点的broker可以获得更高的性能，但在重启后元数据就都丢了。
元数据包含以下内容：
单节点系统必须是磁盘节点 ，否则每次你重启RabbitMQ之后所有的系统配置信息都会丢失。
集群中至少有一个磁盘节点 ，当节点加入和离开集群时，必须通知磁盘 节点。
如果集群中的唯一一个磁盘节点，结果这个磁盘节点还崩溃了，那会发生什么情况？集群依然可以继续路由消息（因为其他节点元数据在还存在），但无法做以下操作：
也就是说，如果唯一磁盘的磁盘节点崩溃， 集群是可以保持运行的，但不能更改任何东西 。为了增加可靠性，一般会在集群中设置两个磁盘节点，只要任何一个处于工作状态，就可以保障集群的正常服务。
RabbitMQ的集群模式分为两种： 普通模式 与 镜像模式 。
普通模式，也是默认的集群模式。
对于Queue来说， 消息实体只存在于其中一个节点 ，A、B两个节点仅有相同的元数据，即队列结构。当消息进入A节点的Queue中后，consumer从B节点拉取时，RabbitMQ会临时在A、B间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连A或B，出口总在A，会产生瓶颈。
队列所在的节点称为 宿主节点 。
队列创建时，只会在宿主节点创建队列的进程，宿主节点包含完整的队列信息，包括元数据、状态、内容等等。因此， 只有队列的宿主节点才能知道队列的所有信息 。
队列创建后，集群只会同步队列和交换器的元数据到集群中的其他节点，并不会同步队列本身，因此 非宿主节点就只知道队列的元数据和指向该队列宿主节点的指针 。
假如现在一个客户端需要对Queue A进行发布或者订阅，发起与集群的连接，有两种可能的场景：
由于节点之间存在路由转发的情况，对延迟非常敏感，应当只在本地局域网内使用，在广域网中不应该使用集群，而应该用Federation或者Shovel代替。
这样的设计，保证了不论从哪个broker中均可以消费所有队列的数据，并分担了负载，因此，增加broker可以线性提高服务的性能和吞吐量。
但该方案也有显着的缺陷，那就是 不能保证消息不会丢失 。当集群中某一节点崩溃时，崩溃节点所在的队列进程和关联的绑定都会消失，附加在那些队列上的消费者也会丢失其订阅信息，匹配该队列的新消息也会丢失。比如A为宿主节点，当A节点故障后，B节点无法取到A节点中还未消费的消息实体。如果做了消息持久化，那么得等A节点恢复，然后才可被消费；如果没有持久化的话，然后就没有然后了……
肯定有不少同学会问，想要实现HA方案，那将RabbitMQ集群中的所有Queue的完整数据在所有节点上都保存一份不就可以了吗？比如类似MySQL的主主模式，任何一个节点出现故障或者宕机不可用时，那么使用者的客户端只要能连接至其他节点，不就能够照常完成消息的发布和订阅吗？
RabbitMQ这么设计是基于性能和存储空间上来考虑：
引入 镜像队列 （Mirror Queue）的机制，可以将队列镜像到集群中的其他Broker节点之上，如果集群中的一个节点失效了，队列能够自动切换到镜像中的另一个节点上以保证服务的可用性。
一个镜像队列中包含有1个主节点master和若干个从节点slave。其主从节点包含如下几个特点：
该模式和普通模式不同之处在于，消息实体会主动在镜像节点间同步，而不是在consumer取数据时临时拉取。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用。
一个队列想做成镜像队列，需要先设置policy，然后客户端创建队列的时候，rabbitmq集群根据队列名称自动设置为普通队列还是镜像队列。
镜像队列的配置通过添加policy完成，policy添加的命令为：
例如，对队列名称以hello开头的所有队列进行镜像，并在集群的两个节点上完成镜像，policy的设置命令为：
rabbitmqctl set_policy hello-ha "^hello" '{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}'
通常队列由两部分组成：一部分是AMQQueue，负责AMQP协议相关的消息处理，即接收生产者发布的消息、向消费者投递消息、处理消息confirm、acknowledge等等；另一部分是BackingQueue，它提供了相关的接口供AMQQueue调用，完成消息的存储以及可能的持久化工作等。
镜像队列基本上就是一个特殊的BackingQueue，它内部包裹了一个普通的BackingQueue做本地消息持久化处理，在此基础上增加了将消息和ack复制到所有镜像的功能。所有对mirror_queue_master的操作，会通过组播GM（下面会讲到）的方式同步到各slave节点。GM负责消息的广播，mirror_queue_slave负责回调处理，而master上的回调处理是由coordinator负责完成。mirror_queue_slave中包含了普通的BackingQueue进行消息的存储，master节点中BackingQueue包含在mirror_queue_master中由AMQQueue进行调用。
消息的发布（除了Basic.Publish之外）与消费都是通过master节点完成。master节点对消息进行处理的同时将消息的处理动作通过GM广播给所有的slave节点，slave节点的GM收到消息后，通过回调交由mirror_queue_slave进行实际的处理。
GM(Guarenteed Multicast) 是一种可靠的组播通讯协议，该协议能够保证组播消息的原子性，即保证组中活着的节点要么都收到消息要么都收不到。它的实现大致如下：
将所有的节点形成一个循环链表，每个节点都会监控位于自己左右两边的节点，当有节点新增时，相邻的节点保证当前广播的消息会复制到新的节点上；当有节点失效时，相邻的节点会接管保证本次广播的消息会复制到所有的节点。在master节点和slave节点上的这些gm形成一个group，group（gm_group）的信息会记录在mnesia中。不同的镜像队列形成不同的group。消息从master节点对于的gm发出后，顺着链表依次传送到所有的节点，由于所有节点组成一个循环链表，master节点对应的gm最终会收到自己发送的消息，这个时候master节点就知道消息已经复制到所有的slave节点了。
slave节点先从gm_group中获取对应group的所有成员信息，然后随机选择一个节点并向这个节点发送请求，这个节点收到请求后，更新gm_group对应的信息，同时通知左右节点更新邻居信息（调整对左右节点的监控）及当前正在广播的消息，然后回复通知请求节点成功加入group。请求加入group的节点收到回复后再更新rabbit_queue中的相关信息，并根据需要进行消息的同步。
当slave节点失效时，仅仅是相邻节点感知，然后重新调整邻居节点信息、更新rabbit_queue、gm_group的记录等。如果是master节点失效，"资格最老"的slave节点被提升为master节点，slave节点会创建出新的coordinator，并告知gm修改回调处理为coordinator，原来的mirror_queue_slave充当amqqueue_process处理生产者发布的消息，向消费者投递消息等。
上面提到如果是slave节点失效，只有相邻的节点能感知到，那么master节点失效是不是也是只有相邻的节点能感知到？假如是这样的话，如果相邻的节点不是"资格最老"的节点，怎么通知"资格最老"的节点提升为新的master节点呢?
实际上，所有的slave节点在加入group时，mirror_queue_slave进程会对master节点的amqqueue_process进程（也可能是mirror_queue_slave进程）进行监控，如果master节点失效的话，mirror_queue_slave会感知，然后再通过gm进行广播，这样所有的节点最终都会知道master节点失效。当然，只有"资格最老"的节点会提升自己为新的master。
消息从master节点发出，顺着节点链表发送。在这期间，所有的slave节点都会对消息进行缓存，当master节点收到自己发送的消息后，会再次广播ack消息，同样ack消息会顺着节点链表经过所有的slave节点，其作用是通知slave节点可以清除缓存的消息，当ack消息回到master节点时对应广播消息的生命周期结束。
下图为一个简单的示意图，A节点为master节点，广播一条内容为"test"的消息。"1"表示消息为广播的第一条消息；"id=A"表示消息的发送者为节点A。右边是slave节点记录的状态信息。
为什么所有的节点都需要缓存一份发布的消息呢？
master发布的消息是依次经过所有slave节点，在这期间的任何时刻，有可能有节点失效，那么相邻的节点可能需要重新发送给新的节点。例如，A->B->C->D->A形成的循环链表，A为master节点，广播消息发送给节点B，B再发送给C，如果节点C收到B发送的消息还未发送给D时异常结束了，那么节点B感知后节点C失效后需要重新将消息发送给D。同样，如果B节点将消息发送给C后，B,C节点中新增了E节点，那么B节点需要再将消息发送给新增的E节点。
配置镜像队列的时候有个 ha-sync-mode 属性，这个有什么用呢?
新节点加入到group后，最多能从左边节点获取到当前正在广播的消息内容，加入group之前已经广播的消息则无法获取到。如果此时master节点不幸失效，而新节点有恰好成为了新的master，那么加入group之前已经广播的消息则会全部丢失。
注意：这里的消息具体是指新节点加入前已经发布并复制到所有slave节点的消息，并且这些消息还未被消费者消费或者未被消费者确认。如果新节点加入前，所有广播的消息被消费者消费并确认了，master节点删除消息的同时会通知slave节点完成相应动作。这种情况等同于新节点加入前没有发布任何消息。
避免这种问题的解决办法就是对新的slave节点进行消息同步。当 ha-sync-mode 配置为自动同步（automatic）时，新节点加入group时会自动进行消息的同步；如果配置为manually则需要手动操作完成同步。
Federation直译过来是联邦，它的设计目标是使 RabbitMQ 在不同的 Broker 节点之间进行消息传递而无须建
立集群。具有以下特点：
那么它到底有什么用呢？我们可以从一个实际场景入手：
有两个服务分别部署在国内和海外，它们之间需要通过消息队列来通讯。
很明显无论RabbitMQ部署在海外还是国内，另一方一定得忍受连接上的延迟。因此我们可以在海外和国内各部署一个MQ，这样一来海外连接海外的MQ,国内连接国内，就不会有连接上的延迟了。
但这样还会有问题，假设某生产者将消息存入海外MQ中的某个队列 queueB ， 在国内的服务想要消费 queueB 消息，消息的流转及确认必然要忍受较大的网络延迟 ，内部编码逻辑也会因这一因素变得更加复杂。
此外，服务可能得维护两个MQ的配置，比如国内服务在生产消息时得使用国内MQ，消费消息时得监听海外MQ的队列，降低了系统的维护性。
可能有人想到可以用集群，但是RabbitMQ的集群对延迟非常敏感，一般部署在局域网内，如果部署在广域网可能会产生网络分区等等问题。
这时候，Federation就派上用场了。它被设计成能够容忍不稳定的网络连接情况，完全能够满足这样的场景。
那使用Federation之后是怎样的业务流程呢?
首先我们在海外MQ上定义exchangeA，它通过路由键“rkA”绑定着queueA。然后用Federation在exchangeA上建立一条 单向 连接到国内RabbitMQ，Federation则自动会在国内RabbitMQ建立一个exchangeA交换器（默认同名）。
这时候，如果部署在国内的client C在国内MQ上publish了一条消息，这条消息会通过 Federation link 转发到海外MQ的交换器exchangeA中，最终消息会存入与 exchangeA 绑定的队列 queueA 中，而client C也能立即得到返回。
实际上，Federation插件还会在国内MQ建立一个内部的交换器：exchangeA→ broker3 B（broker3是集群名），并通过路由键 "rkA"将它和国内MQ的exchangeA绑定起来。接下来还会在国内MQ上建立一个内部队列federation: exchangeA->broker3 B，并与内部exchange绑定。这些操作都是内部的，对客户端来说是透明的。
值得一提的是，Federation的连接是单向的，如果是在海外MQ的exchangeA上发送消息是不会转到国内的。
这种在exchange上建立连接进行联邦的，就叫做 联邦交换器 。一个联邦交换器接收上游（upstream）的信息，这里的上游指的是其他的MQ节点。
对比前面举的例子，国内MQ就是上游，联邦交换器能够将原本发送给上游交换器的消息路由到本地的某个队列中。
有联邦交换器自然也有联播队列，联邦队列则允许一个本地消费者接收到来自上游队列的消息 。
如图，海外MQ有队列A，给其设置一条链接，Federation则自动会在国内RabbitMQ建立一个队列A（默认同名）。
当有消费者 ClinetA连接海外MQ并消费 queueA 中的消息时，如果队列 queueA中本身有若干消息堆积，那么 ClientA直接消费这些消息，此时海外MQ中的queueA并不会拉取国内中的 queueA 的消息；如果队列 queueA中没有消息堆积或者消息被消费完了，那么它会通过 Federation link 拉取上游队列 queueA 中的消息(如果有消息)，然后存储到本地，之后再被消费者 ClientA进行消费 。
首先开启Federation 功能：
值得注意的是，当需要在集群中使用 Federation 功能的时候，集群中所有的节点都应该开启 Federation 插件。
接下来我们要配置两个东西：upstreams和Policies。
每个 upstream 用于定义与其他 Broker 建立连接的信息。
通用参数如下：
然后定义一个 Policy， 用于匹配交换器：
^exchange 意思是将匹配所有以exchange名字开头的交换器，为它们在上游创建连接。这样就创建了一个 Federation link。
Shovel是RabbitMQ的一个插件， 能够可靠、持续地从一个Broker 中的队列（作为源端，即source ）拉取数据并转发至另一个Broker 中的交换器（作为目的端，即destination ）。作为源端的队列和作为目的端的交换器可以同时位于同一个 Broker 上，也可以位于不同的 Broker 上。
使用Shovel有以下优势：
使用Shovel时，通常源为队列，目的为交换器：
但是，也可以源为队列，目的为队列。实际也是由交换器转发，只不过这个交换器是默认交换器。配置交换器做为源也是可行的。实际上会在源端自动新建一个队列，消息先存在这个队列，再被Shovel移走。
使用Shovel插件命令：
Shovel 既可以部署在源端，也可以部署在目的端。有两种方式可以部署 Shovel：
其主要差异如下：
来看一个使用Shovel治理消息堆积的案例。
当某个队列中的消息堆积严重时，比如超过某个设定的阈值，就可以通过 Shovel 将队列中的消息移交给另一个集群。
❺ 网络层的阻塞控制
阻塞现象是指到达通信子网中某一部分的分组数量过多，使得该部分网络来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿，即出现死锁现象。这种现象跟公路网中通常所见的交通拥挤一样，当节假日公路网中车辆大量增加时，各种走向的车流
相互干扰，使每辆车到达目的地的时间都相对增加（即延迟增加），甚至有时在某段公路上车辆因堵塞而无法开动（局部死锁）。通信子网吞吐量和通信子网负荷之间一般有如图4.3 所示的关系。当通信子网负荷（即通信子网正在传输的分组数）比较小时，网络的吞吐量（单位为分组数/秒）随网络负荷（可用每个节点中分组的平均数表示）的增加而线性增加。当网络负荷增加到某一值后，若网络吞吐量反而下降，则表征网络中出现了阻塞现象。在一个出现阻塞现象的网络中，到达一个节点的分组将会遇到无缓冲区可用的情况，从而使这些分组不得不由前一节点重传，或者需要由源节点或源端系统重传。当阻塞比较严重时，通信子网中相当多的传输能力和节点缓冲器都用于这种无谓的重传，从而使通信子网的有效吞吐量下降，由此导致恶性循环，使通信子网的局部甚至全部处于死锁状态，网络有效吞吐量接近为零。在理想的情况下，整个网络的利用率为100%，但为了使网络在高负荷上能稳定运行，应控制网络节点的队列长度，以避免由于队列无限增长而产生通信量的崩溃。有控制的网络可以以接近于理想吞吐的状态稳定运行。 （1）缓冲区预分配法：这种方法用于采用虚电路的分组交换网。在建立虚电路时，让呼叫请求分组途经的节点为虚电路预先分配一个或多个数据缓冲区。若某个节点缓冲器已被占满，则呼叫请求分组另择路由，或者返回一个“忙”信号给呼叫者。这样，通过途经的各节点为每条虚电路开设的永久性缓冲区（直到虚电路拆除），就总能有空间来接纳并转送经过的分组。当节点收到一个分组并将它转发出去之后，该节点向发送节点返回一个确认信息，该确认一方面意味着接收节点已正确收到分肆银斗组，另一方面告诉发送节点，该节点已空出缓冲区以备接收下一分组。上面是“停－等”协议下的情况，若节点之间的协议允许多个未处理的分组存在，则为了完全消除阻塞的可能性，每个节点要为每条虚电路保留等价于窗口大小数量的缓冲区。这种方法不管有没有通信量，都有可观的资源（线路容量或存储空间）被某个连搏喊接永久地占有。由于为每条连接分配了专用资源因此不可能有效地利用网络资源。此时的分组交换跟电路交换很相似。 （2）分组丢弃法：这种方法不用预先保留缓冲区，而在缓冲区占满时，将到来的分组丢弃。若通信子网提供的是数据报服务，则用分组丢弃法来防止阻塞发生不会引起大的影响。但若通信子网提供的是虚电路服务，则必须在某处保存被丢弃分组的拷贝，以便阻塞解决后能重新传送。有两种解决被丢弃分组重发的方法，一种是让发送被丢弃的节点超时，并重新发送分组直至分组被收到；另一种是让发送被丢弃分组的节点在尝试一定次数后放弃发送，并迫使数据源节点超时而重新开始发送。但是不加分辩地随意丢弃分组也不妥，因为一个包含确认信息的分组可以释放节点的缓冲区，若因节点无空余缓冲区来接收含确认信息的分组，这便使节点缓冲区失去了一次释放的机会。解决这个问题的方法可以为每条输入链路永久地保留一块缓冲区，心用于接纳并检测所有进入的分组，对于捎带确认信息的分组，在利用了所捎带的确认释放了一个缓冲区后，再将该分组丢弃或将该捎带好消息的分组裂磨保存在刚空出的缓冲区中。
（3）定额控制法：这种方法直接对通信子网中分组的数量进行严格、精确的限制，以防止阻塞的发生。从图4.3网络吞吐量与负荷的关系曲线中可看出，为避免阻塞，可将通信子网中正在传输的分组数保持在某一负荷值Lc以下。因此，可以设计在通信子网中存在Lc个称“许可证”的特殊信息，这些许可证中的一部分在通信子网开始工作之前预先以某种策略分配给各个源节点，另一部分则在子网开始工作后在网中四处环游。当源节点要发送一个刚从源端系统送来的分组时，它必须首先拥有这种许可证，并且每发送一个分组要注销一张许可证。而在目的节点方，则每收到一个分组并将其递交给目的端系统后，便生成一张许可证。这样，便保证了子网中分组数量不会超过许可证的数量。
阻塞的极端后果是死锁。死锁是网络中容易发生的故障之一，即使在网络负荷不很重时也会发生。死锁发生时，一组节点由于没有空闲缓冲区而无法接收和转发分组，节点之间相互等待，即不能接收分组也不能转发分组，并永久保持这一状态，严重的甚至导致整个网络的瘫痪。此时，只能靠人工干预，重新启动网络解除死锁。但重新启动后并未消除引起死锁的隐患，所以可能再次发生死锁。死锁是由于控制技术方面的某些缺陷所引起的，起因通常难以难捉摸难以发现，即使发现，常常不能立即修复。因此，在各层协议中都必须考虑如何避免死锁的问题。 网络层图4-4
存储转发死锁及其防止： 最常见的死锁是发生在两个节点之间的直接存储转发死锁。此时，A节点的所有缓冲区全部用于输出到B节点的队列上，而B节点的所有缓冲区也全部用于输出到A节点的队列上，A节点不能从B节点接收分组，B节点也不能从A节点接收分组，如图4.4（a）所示。这种情况也可能发生在一组节点之间，每个节点都企图向相邻节点发送分组，但每个节点都无空闲缓冲区用于接收分组，这种情形称作间接存储转发死锁，如图4.4（b）所示。当一个节点处于死锁状态时，与之相连的所有链路都将被完全阻塞。
有一种防止存储转发死锁的方法。设一通信子网直径为M，即从任一源点到一目的节点的最大中间链路段数为M，每个节点需要M+1个缓冲区，以0到M编号。对于一个源节点，规定仅当其0号缓冲区空时才能接收源端系统来的分组，而此分组仅能转发给1号缓冲区空闲的相邻节点，再由该节点将分组转发给它的2号缓冲区空闲的相邻节点......。最后，该分组或者顺利到达目的节点，并被递交给目的端系统；或者到了某个节点编号为M的缓冲区中，再也转发不下去，此时，一定发生了循环，应该将该分组丢弃。由于每个分组都按照一定的顺序规则分配缓冲区，即分组所占用的缓冲区编号一直在递增，从而会使节点之间相互等待空闲缓冲区而发生死锁情况。
重装死锁及其防止：死锁中一种比较严重的情况是生装死锁。假设发给一个端系统的报文很长，被源节点拆成若干个分组发送，目的节点要将所有具有相同报文编号的分组重新装配成报文递交给目的端系统。由于目的节点用于重装报文的缓冲区空间有限，而且它无法知道在接收的报文究竟被拆成多少个分组，此时，就可能发生严重的问题：为了接收更多的分组，该目的节点用完了它的缓冲空间，但它又不能将尚未接收并拼装完整的报文递送给目的端系统。而邻节点仍在不断地向它传送分组，但它却无法接收。
这样，经过多次尝试后，邻节点就会绕道从其它途径再向该目的节点传送分组，但该目的节点已被牢牢锁死，其周围区域也由此发生了阻塞现象。下面几种方法可以用于免重装死锁的发生： 允许目的节点将不完整的报文递交给目的端系统。 一个不能完整重装的报文能被检测出来，并要求发送该报文的源端系统重新传送。 为每个节点配备一个后备缓冲空间，当重装死锁发生时，将不完整的报文暂移至后备缓冲区中。两种方法不能很满意地解决重装死锁，因为它们使端系统中的协议复杂化了。一般的设计中，网络层应该对端系统透明，也即端系统不该考虑诸如报文拆、装之类的事情。第三种方法虽然不涉及端系统，但每个点增加了开销，降低了可靠性。
❻ 什么是CPU卡呢
“CPU卡芯片通俗地讲就是指芯片内含空信有一个微处理器，它斗困轮的功能相当于一台微型计算机。人们经常使用的集成电路卡（IC卡）上的金属片就是尺岁CPU卡芯片。CPU卡可适用于金融、保险、交警、政府行业等多个领域，具有用户空间大、读取速度快、支持一卡多用等特点，并已经通过中国人民银行和国家商秘委的认证。CPU卡从外型上来说和普通IC卡，射频卡并无差异，但是性能上有巨大提升，安全性和普通IC卡比，提高很多，通常CPU卡内含有随机数发生器，硬件DES，3DES加密算法等，配合操作系统即片上OS，也称SoC，可以达到金融级别的安全等级。”
❼ 消息中间件TongLINKQ
公司地址：北京市海淀南路
32
号中信国安数码港
8
层
100080
电话：
（
010
）
82652228
传真：
（
010
）
82652226
17
连接分为常连接和按需连接：
常连接：在系统启动时创建，在系统运行期间，系统自动保持此连接，若连接中
断，系统会自动重新创建此连接。
按需连接：系统启动后，连接并不建立，而是在有用户数据需要传输时才创建；
在一定时间内，若没有用户数据需要传输，则断开连接。
2.
队列控制单元
队列控制单元，英文为
Queue Control Unit
，简称
QCU
。
QCU
为一个节点内相对独立运行单元，
功能主要是对一组队列以及队列内的消息进行
监控和管理的运行单元。
QCU
是队列和消息的管理单元，由数据缓冲清档区（发送
/
接收缓冲区）、队列组成，主
要包括监控模块、管理模块、网络发送和接收模块、瘦客户代理和发布订阅代理。管理模
块负责管理整个
QCU
的运行，包括：队列创建、恢复及消息在数据缓冲区和队列之间的
转移等；监控模块负责监控队列中消息的生命周期和应用读取消息的超时时间。
任何一个队列都必须属于某个
QCU
，并由此
QCU
进行管理。
一个节点可拥有多个
QCU
，每个
QCU
在运行上相互独立。
一个
QCU
可对应多个发送进程和接收进程。
3.
队列
队列是存储消息的数据结构，队列对于使用它们的应用程序来说是独立存在的。队列
存在于主存储器、磁盘或相似的辅助存储器（如果必须保留以备恢复的话）。每个队列都
属于一个
QCU
，由
QCU
负责维护队列。
公司地址：北京市海淀南路
32
号中信国安数码港
8
层
100080
电话：
（
010
）
82652228
传真：
（
010
）
82652226
18
队列可在本地系统上存在，这种情况下它们为本地队列或发送队列，也可在另一个节
点上存在，这种情况下它们为远程队列。
应用程序可发送消息至队列，
也可从队列中接收消息，
也可同时放入消息和接收消息。
应用既可向本地队列发送消息，也可从本地队列接收消息。
4.
消息
“消息”是在应用进程之间或一个应用的不同部分之间交换的数据单位，应用可分布
在多台相同或不同的平台上，也可分布在一台计算机上。消息可非常简单，例如只包含文
本字符串；也可更复杂，包含嵌入对象或者为一个文件。
5.
事答配乱件
事件指系统运行过程中发生的一些特定情况，在系统中被定义成不同的事件类型。可
以通过一定的方式获取需要的各种事件。可用于跟踪系统的运行状况。
6.
事务
事务是并发控制的基本单位。所谓事务，它是一个操作序列
,
这些操作要么都执行
,
要
么都不执行
,
它是一个不可分割的工作单位
,
例如
,
银行转账工作
,
从一个账号扣款并使另一
个账号增款
,
这两个操作要么都执行
,
要么都不执行
.
所以
,
应该把它们看成一个事务
.
事务是
消息中间件维护一致性的单位
,
在每个事务结束时
,
都能保持数据一致性。
7.
集群
集群是一种实现负载均衡的软件技术，用户可以利用低成本的服务器构造具有很高可
用性和可伸缩性的高性能集群系统。此技术扩展了单个节点的处理能力，把有可能拥塞于
公司地址：北京市海淀南路
32
号中信国安数码港
8
层
100080
电话：
（
010
）
82652228
传真：
（
010
）
82652226
19
一个节点的负载交给多个节点分担。在
C/S
应用结构中，通过使用集群功能，多个服务器
联合起来作为一个整体，可支持大量的客户应用。
8.
发布和订阅
发布
/
订阅功能为应用提供了一种透明的信息发布和信息消费卖枝的框架。
消息的发布者只
负责发布信息的收集并通过一个
“
主题
”
来表示这个消息，
消息的订阅者通过主题来订阅需
要的消息，当有相关
“
主题
”
的消息发布时，消息会自动发送给订阅者，发布者和订阅者无
需知道各自在网络中的位置。
❽ 评估网络的核心路由器性能时
需要考虑以下几个方面：
1、路由转发能冲弊竖力：路由器的转发能力是其最重要的性能指标之一。它表示路由器在单位时间内可以处理的数据包数量卜举或者带宽大小。这个指标可以用每秒钟处理的数据包数量（PPS）或每秒钟转发的比特数（BPS）来衡量。
2、缓散大存和队列管理：路由器中的缓存和队列管理对于网络性能也非常关键。缓存可以提高路由器的访问速度，而队列管理则可以有效地控制传输延迟和防止拥塞发生。
3、支持的协议和功能：核心路由器通常需要支持多种协议和功能。例如，在今天的互联网环境中，IPv4、IPv6、MPLS等多种协议都需要被支持。此外，核心路由器还需要支持各种安全性能、质量保证（QoS）、多路径路由选择（ECMP）等高级功能。
❾ 阿里云消息中间件（MQ）探秘
阅读字数： 2513 | 5分钟阅读
获取嘉宾演讲视频及PPT ，请点击： http://t.cn/RDVY4JN
阿里巴巴中间技术专家不铭从功能特性、技术架构、最佳实践、案例分析四个方面进行了《Aliware-MQ消息队列》的分享。
Aliware-MQ是阿里云提供的企业级互联网架构的核心产品，基于高可用分布式集群技术，支持海量高并发和万亿级消息流转，支持海量的消息堆积，支持高可靠/高可用方案，提供了运维、监控等一系列完整的配套服务。
如上图所示，从消息的维度来看分为普通消息、顺序消息、定时消息和事务消息等四种消息,无论是发送哪种消息客户端都支持熔断机制，即如果发现发送目标节点有性能问题，客户端会自动进行熔断，把有问题的节点排出去，保证消息发往可靠性最高的机器。管理方面已经支持消息的查询、消息回溯、消息全链路轨迹和监控报警机制。性能上MQ已经达到了百亿级的堆积能力，毫秒级的投递延迟，支持万级节点高并发，集群水平热扩缩。消息消费方面，支持失败后的消息重投机制，失败的消息会重新投递到队列中去，现在最多支持16次重投。
上图是Aliware-MQ的功能架构。左边是控制台的管理，可以在上面做发布首搏纯订阅管理。右边目前的接入方式是SDK支持TCP协议，同时也支持HTTP接口，以及面向手机终端的MQTT协议。
OpenAPI是MQ提供给用户的管控方式，用于实现一系列资源管理和运维功能，用户可以通过Open API查询所需要的任何东西。
上图中是我们今年推出的一个MQ移动物联网套件。之前的客户端，不管是上游还是下游收发都是用各自的服务器。但是今年我们有了移动物联网套件，可以直接面向终端设备。比如手机、汽车等移动设备利用移动物联网套件，通过一个网关就可以直接和消息系统打通。
Aliware-MQ的消息系银兆统是基于队列。队列要保证数据安全，是支持高并发和高性能读写的最基本元素。
如上图所示，Procer是消息发送集群，下游的Consumer是消费者集群，都依赖于MQ的SDK。Broker是消息服务器，所有的消息都发送到Broker上面；Name Server和ZK功能类似，用来做服务发现。Procer要从Name Server获取到Topic在哪个节点上，订阅Topic时需要知道Topic从哪里取，同样需要Name Server。Broker上的Topic信息会定时在Name Server上注册，Procer和Consumer在交互之前会从Name Server上获取目标。
图中的master是主机，slave是备机，主备之间会做数据同步，有异步和同步两种方式。一个master可以布多个节点，这个根据自己的成本来决定。如果扩容的话，只要直接布一台master即可，它会定时地将Topic注册到Name Server上，发送方和订阅方也会定时地感知这者咐个过程，整个扩容的过程对于用户来说大概30秒就能完成。
Aliware-MQ所有数据存储在Commit Log里，它在实现上就相当于一个文件夹，每次会生成一个1G的文件。不管哪个Topic写过来的消息都会直接写入这个文件中，这个文件写满后再直接写下一个。
针对每一个Topic，要在业务层面对它进行区分，所以我们做了一层索引。例如在上图中有5个队列，每个队列都会生成定长的索引文件，通过索引，可以找到这条消息当前处于哪个CommitLog文件的某个具体位置中。
这样存储结构，保证了无论多少个topic，CommitLog的写是顺序的，能较大的保证MQ的写入性能。
Aliware-MQ的负载均衡是按照队列维度来做的，消费的时候会把topic的队列平均分配给消费实例。比如有2个消费实例，topic队列是4个，那么每个消费实例就消费2个；而如果共有5个队列，那么就是是1个消费2个，另1个消费3个。一个队列同一时间只会被一个消费实例消费，所以当出现队列数量小于消费实例数量的情况时，就会有消费实例出现空闲，这个时候可以根据业务实际情况手动通过工具将队列数量调大。
消息写进来都是先放在Java堆里，然后再落盘。如果用户要消费的消息都在内存里，那么就可以很快的读取到。但是如果用户消息堆积比较久，消息已经不在内存里而是存储在了磁盘中，这个时候就需要去磁盘里取数据，然后加载到内存里面读取出来。
Aliware-MQ的刷盘策略有异步和同步两种。异步到内存就返回成功，同步写则一定是消息刷到磁盘中才会返回成功。这种刷盘方式可以根据业务的具体需求进行配置，从写入的性能来看，异步写的性能肯定是会比同步的好。
从发消息的角度来看，如果发送失败，会有补偿机制。MQ的客户端会做三次重发，一台机器发送失败之后会默认往另外两台机器再尝试，如果三次都失败了才会把最终的失败结果传回，这个时候用户需要自己对发送异常进行相关处理。
有幂等要求的业务，Consumer在使用的时候需要自己做去重操作，在一些场景下，如客户端本地等待超时等，是无法保证消息完全不重复的，因此用户在进行系统设计时需要考虑到这一点。
Aliware-MQ目前支持的消息最大是4M，消息越小，性能越高。定时消息是支持消息的定时投递，可以自行设置要投递的时间，最长是40天。事务消息通过两阶段的提交的方式，来解决分布式事务问题。顺序消息可以采用全局顺序、分区顺序，严格保证消息的顺序。
Aliware-MQ的使用场景主要有系统间异步解耦、分布式事务、异构数据复制与分发、双十一大促的削峰填谷、大规模机器的Cache同步、日志服务和IM实时通信以及实时计算分析。
MQ顺序消息分为全局有序和队列有序。全局有序是从指所有消息发出开始，下游的接收方都是按照顺序接收；队列有序则是将消息进行区块分区，同一个分区内的消息按照先入先出的顺序进行顺序消费，保证一个队列只会被一个进程消费。
当一个交易系统下单之后，会发一条消息到MQ，购物车接收消息把购物车里的状态清空。如果这时交易消息发送失败，购物车就无法清空，对于数据来说这就是一个脏数据。面对这种情况我们有事务消息可以解决这个问题，在交易开始时先发送一条半事务消息，然后交易系统开始下单，所有事情做完之后再提交半事务，这时只有主动提交成功，消息队列才会将这条消息实际发送给用户。如果交易下单过程失败，则可以主动回滚这条消息，购物车和交易系统之间可以做到没有脏数据。
双十一大促时，各个分会场会有玲琅满目的商品，每件商品的价格都会实时变化。使用缓存技术也无法满足对商品价格的访问需求，缓存服务器网卡跑满。访问较多次商品价格查询影响会场页面的打开速度。于是MQ提供了一种广播机制，本来一条消息只会被集群的一台机器消费。如果使用广播模式，那么这条消息会被集群下的所有节点消费一次，相当于把价格信息同步到需要的每台机器上，可以取代缓存的作用。
实时计算功能主要是做一个消息总线，业务系统自动采集数据，把消息分发达下游的实时计算系统里，根据实时计算结果来给业务方做服务。
我今天的分享就到这里，谢谢大家！
❿ RabbitMQ集群
如果有一个消息生产者或者消息消费者通过amqp-client的客户端连接至节点1进行消息的发布或者订阅，那么此时的集群中的消息收发只与节点1相关。
如果消息生产者所连接的是节点2或者节点3，此时队列1的完整数据不在该两个节点上，那么在发送消息过程中这两个节点主要起了一个路由转发作用，根据这两个节点上的元数据转发至节点1上，最终发送的消息还是会存储至节点1的队列1上。
RabbitMQ 集群是一个或多个节点的逻辑分组，每个节点共享用户、虚拟主机、队列、交换器、绑定、运行时参数和其他分布式状态。
一些分布式系统 有leader和follower节点。 对于 RabbitMQ 来说， RabbitMQ集群中的所有节点都是平等的。
RabbitMQ 集群可以通过多种方式组成：
RabbitMQ 节点绑定到端口以接锋拍受客户端和 CLI 工具连接。其他进程和工具（例如 SELinux）可能会阻止 RabbitMQ 绑定到端口。发生这种情况时，节点将无法启动。
CLI工具、客户端库和 RabbitMQ 节点也会打开连接（客户端 TCP 套接字）。防火墙会阻止节点和 CLI 工具相互通信。确保可以访问以下端口：
RabbitMQ节点和 CLI 工具（例如 rabbitmqctl）使用 cookie 来确定它们是否被允许相互通信。为了让两个节点能够通信，它们必须具有相同的共享密钥，称为 Erlang cookie。cookie 只是一串最多 255 个字符的字母数字字符。 它通常存储在本地文件中。该文件必须只能由所有者访问（例如具有 600 或类似的 UNIX 权限）。每个集群节点必须具有相同的 cookie。
在 UNIX 系统上，cookie通常是位于/var/lib/rabbitmq/.erlang.cookie（由服务器使用）和$HOME/.erlang.cookie（由 CLI 工具使用）。
RabbitMQ 节点使用主机名相互寻址
<!== 所有主机执行 ==>
<!== 所有主运滚机执行 ==>
<!== 所有主机执行 ==>
默认配置文件/usr/lib/rabbitmq/lib/rabbitmq_server-3.7.17/ebin/rabbit.app
<!== node01主机执行 ==>
<!== node02主机执行 ==>
<!== node03主机执行 ==>
<!== 所有主银悄羡机执行 ==>
因RabbitMQ 集群元数据同步基于 cookie 共享方案实现
文件路径/var/lib/rabbitmq/.erlang.cookie
<!== node02、node03主机执行 ==>
<!== 任意主机执行 ==>
节点分为：磁盘节点及内存节点
RAM节点是一种特殊情况，可用于提高具有高队列、交换或绑定搅动的集群的性能。RAM节点不提供更高的消息速率。 官方建议在绝大多数情况下，仅使用磁盘节点。
如果一个集群中都是RAM节点，那么集群停止，将无法再次启动，并将丢失所有数据
官方提示：经典队列镜像将在未来版本中删除，考虑改用仲裁队列或非复制经典队列
每个镜像队列由一个领导副本和一个或多个镜像副本，leader被托管的节点成为leader节点。首先应用给定队列的所有操作 在队列的leader节点上，然后传播到镜像。
如果承载队列的leader节点出现故障，则只要已同步，最旧的镜像将升级为新的leader。根据队列镜像参数，也可以升级未同步的镜像。
队列通过策略启用了镜像，策略模式的说明如下：
每当队列的策略发生变化时，它都保持其现有的镜像尽可能适用新策略。
设置的镜像队列可以通过开启的网页的管理端Admin->Policies，也可以通过命令。
管理端界面：
命令行：
为避免集群中的某个节点托管大多数leader队列，因此导致高负载，leader队列应合理均匀的分布在集群节点上。控制leader队列分布节点策略有三种，可以在rabbitmq.conf文件中定义queue_master_locator参数设置
修改节点策略可能会导致现有的leader队列没有在新的策略中，为了防止消息丢失，RabbitMQ会保留现有的leader直到至少另一个镜像已同步，一旦发生同步，消费者将与leader断开连接，需要重新连接。
如果leader故障，其他镜像升级为leader过程如下：
如果消费者使用 自动确认模式 ，那么消息可能会丢失。这与非镜像队列没有什么不同：代理认为消息一旦以自动确认模式发送给消费者，就会被确认。
如果客户端突然断开连接，则可能永远不会收到消息。在镜像队列的情况下，如果leader死亡，那些正在以 自动确认模式 发送给消费者的消息可能永远不会被这些客户端接收，并且不会被新leader重新排队。由于消费客户端连接到存活节点的可能性，消费者取消通知有助于识别此类事件何时发生。 当然，在实践中，如果数据安全性不如吞吐量重要，那么自动确认模式是可行的方法。
节点可以随时加入集群。 根据队列的配置，当节点加入集群时，队列可能会在新节点上添加镜像。 此时，新镜像将是空的：它不会包含队列中任何现有的内容。 这样的镜像将接收发布到队列的新消息，因此随着时间的推移将准确地表示镜像队列的尾部。 随着消息从镜像队列中排出，新镜像丢失消息的队列头部的大小将缩小，直到最终镜像的内容与leader的内容完全匹配。 在这一点上，镜像可以被认为是完全同步的。
新添加的镜像不提供添加镜像之前存在的队列内容的额外形式的冗余或可用性，除非队列已明确同步。 由于在发生明确同步时队列变得无响应，因此最好允许正在从中排出消息的活动队列自然同步，并且仅明确同步非活动队列。
启用自动队列镜像时，请考虑所涉及队列的预期磁盘数据集 。 具有庞大数据集（例如，数十 GB 或更多）的队列必须将其复制到新添加的镜像中，这会给集群资源（例如网络带宽和磁盘 I/O）带来很大的负载。
要查看镜像状态（是否同步）：
手动同步队列：
取消正在进行的同步：
如果你停止一个包含镜像队列leader的 RabbitMQ 节点，其他节点上的一些镜像将被提升为leader。 如果继续停止节点，那么将到达一个镜像队列不再有镜像的点：它仅存在于一个节点上，且该节点上它是leader。 如果它的最后一个剩余节点关闭，但是镜像队列被声明为持久的，那么队列中的持久消息将在该节点重新启动后继续存在。
然而，镜像目前无法知道它的队列内容是否已经偏离了它重新加入的leader。 因此，当一个镜像重新加入一个镜像队列时， 它会丢弃已经拥有的任何持久本地内容并开始为空 。
默认情况下，RabbitMQ 将拒绝leader节点在受控关闭（即明确停止 RabbitMQ 服务或关闭操作系统）时提升异步镜像，以避免消息丢失； 相反，整个队列将关闭，就好像未同步的镜像不存在一样。
leader节点不受控制的关闭（即服务器或节点崩溃，或网络中断）仍将触发未同步镜像的提升。
如果您希望在所有情况下都让leader队列移动到未同步的镜像（即，您会选择队列的可用性而不是避免由于未同步的镜像升级而导致的消息丢失），那么将 ha-promote-on-shutdown 策略键设置为 always 而不是比它的默认值 when-synced 。
如果 ha-promote-on-failure 策略键设置为 when-synced ，则即使 ha-promote-on-shutdown 键设置为 always ，也不会提升未同步的镜像。 这意味着如果leader节点发生故障，队列将变得不可用，直到leader恢复。 如果leader队列永久丢失，队列将不可用，除非它被删除（这也将删除其所有内容）并重新声明。
当队列的所有镜像都关闭时，可能会丢失队列的leader。 在正常操作中，队列关闭的最后一个节点将成为leader，该节点在再次启动时仍然是leader（因为它可能收到了其他镜像没有看到的消息）。
但是，当您调用 rabbitmqctl forget_cluster_node 时，RabbitMQ 将尝试为每个在我们忘记的节点上有其领导者的队列找到当前停止的镜像，并在它再次启动时“提升”该镜像成为新的领导者。 如果有多个候选者，将选择最近停止的镜像。
重要的是要理解 RabbitMQ 只能在 forget_cluster_node 期间提升停止的镜像，因为任何再次启动的镜像都会清除它们的内容，如上面“停止节点和同步”中所述。 因此在停止的集群中移除丢失的leader时，您必须在再次启动镜像之前调用 rabbitmqctl forget_cluster_node 。