❶ 全面分析核心路由器性能指標_思科路由器性能指標
全面分析核心路由器性能指標 副標題：
作者：佚名 文章來源：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 。