❶ rabbitmq基礎配置中文說明文檔
本文為官方文檔翻譯版本 rabbitmq3.7.5版本，原地址： https://github.com/rabbitmq/rabbitmq-server/blob/master/docs/rabbitmq.conf.example 。以#開頭的行為配置，key和等號以及value之間盡量保持有一個空格。以下的"默認"指的為在沒有添加配置文件或者該key沒有配置。
rabbitmq是使用基於tcp的amqp協議通信(如果需要ssl，可參考 這里 )，所以這里都是監聽的tcp的埠。rabbitmq支持監聽多埠，並支持指定網卡的ipv4和ipv6。格式為listeners.tcp.${name} = ${value}，name可以是任意不重復的值，如：defaul、local、local_v6等。value的格式有：
(1)包括了(2)和(3)，(2)包括了(4)和(6)，(3)包括了(5)和(7)。下面對應的為其中情況的配置，按需求進行配置，不需要都配，大部分情況只配置(1)。默認的配置為listeners.tcp.default = 5672
例:
接受TCP偵聽器連接的Erlang進程數。一旦打開了一個使用tcp連接的套接字，它就始終保持打開狀態，直至任何一方關閉它或因為一個錯誤而終止。在建立一個連接時，一般為每一次請求產生一個新進程，num_acceptors就是控制產生新進程的個數。假設有一個監聽進程，其任務是等待傳入的tcp請求。只要一個請求到達，響應該連接請求的進程就變成了接收進程。默認的配置為num_acceptors.tcp = 10。
例:
AMQP 0-9-1握手（socket連接和TLS握手之後）的最大時間，以毫秒為單位。
默認的配置為handshake_timeout = 10000。
例:
設置為'true'以在接受一個連接時執行反DNS反查詢。 在rabbitmqctl中和web管理中將顯示主機名稱而不是IP地址。默認的配置為reverse_dns_lookups = true。
例:
開啟後的效果
僅允許通過本地（即localhost）連接到代理的用戶列表。如果您希望允許guest用戶遠程連接，則需要將其更改為 loopback_users = none。
要將其他用戶限制為僅限localhost的連接，請像這樣執行（monitoring是用戶的名稱）： loopback_users.monitoring = true。默認的配置為loopback_users.guest = true。推薦設置loopback_users.guest = false。
例:
關於ssl的配置，內容比較多，參考 官網 。默認不配置。
選擇要使用的認證/授權後端。可以配置ldap相關的設置。具體可以參考 access-control 。internal為由rabbitmq內部處理，默認的配置為 auth_backends.1 = internal。
例:
RabbitMQ具有對各種SASL認證機制的可插拔支持。伺服器內置了三種這樣的機制：PLAIN，AMQPLAIN和RABBIT-CR-DEMO，以及EXTERNAL 可作為 插件使用 。您還可以通過 在插件中實現rabbit_auth_mechanism行為來實現自己的身份驗證機制。有關常規插件開發的更多信息，請參閱 插件開發指南 。默認的配置為PLAIN和AMQPLAIN。
內置的機制：
例:
有關rabbitmq-auth-mechanism-ssl插件的配置，查看: https://github.com/rabbitmq/rabbitmq-auth-mechanism-ssl
SSL handshake超時時間,毫秒為單位。默認的配置為ssl_handshake_timeout = 5000
。
例:
rabbitmq的用戶的密碼加密演算法。修改該值只會影響新創建的用戶，對應老用戶需要重置密碼進行更新。一般情況下不更改。默認的配置為password_hashing_mole = rabbit_password_hashing_sha256。要使用SHA-512，請設置為rabbit_password_hashing_sha512。
例:
和web端的Import definitions、Export definitions有關。好像沒啥用==。
默認的用戶及其許可權和vhost。如果一個connect沒有配置以下的配置，則使用默認值進行連接。
默認用戶的tag。默認的配置default_user_tags.administrator = true。一般不需要改。
例:
heartbeat通常用來檢測通信的對端是否存活（未正常關閉socket連接而異常crash）。其基本原理是檢測對應的socket連接上數據的收發是否正常，如果一段時間內沒有收發數據，則向對端發送一個心跳檢測包，如果一段時間內沒有回應則認為心跳超時，即認為對端可能異常crash了。
rabbitmq也不例外，heatbeat在客戶端和服務端之間用於檢測對端是否正常，即客戶端與服務端之間的tcp鏈接是否正常。
heartbeat檢測時間間隔的設置：
這里要注意的是：如果時間間隔配置為0，則表示不啟用heartbeat檢測。
例:
設置amqp協議最大允許的位元組數。默認的配置為frame_max = 131072(單位為位元組，也就是128k)，注意該值不要設置過大，如果一條消息比較大(如傳輸文件)，可以通過Publish Confirm和Consumer Acknowledgement機制，如設置過大，那麼broker內存會容易被占完。也不要設置過小，保持在128k-1m之間。 引用:使用RabbitMQ傳輸大文件，保證其完整性
例:
初始化時的最大位元組，不知道哪裡使用的。原文：Set the max frame size the server will accept before connection tuning occurs。
例:
設置每個連接的最大允許通道數量。 0表示「沒有限制」。默認的配置為channel_max = 128。
例:
tcp連接相關的配置。盡量不要改。以下為默認的配置
例:
設置rabbitmq使用內存的閾值。有相對和絕對兩種閾值。默認為vm_memory_high_watermark.relative = 0.4。
隊列開始將消息導出到光碟來釋放內存的高水位限制的值。
例如，當vm_memory_high_watermark被設置為0.4並且該值被設置為0.5時，
可以在節點使用總可用RAM的20％時開始分頁。大於1.0的值可能很危險，應謹慎使用。
一種替代方法是使用持久隊列並發布消息，作為持久性。 有了這個組合隊列將消息更快地移動到磁碟。
另一種方法是配置隊列來分頁所有消息（都是持久和瞬態）到磁碟。
盡可能參閱 http://rabbitmq.com/lazy-queues.html 。
例:
內存使用情況報告策略。可以是以下之一，默認的配置為rss：
allocated：使用Erlang內存分配器統計信息
rss：使用操作系統RSS內存報告。這使用特定於操作系統的手段，並可能啟動短暫的子進程。
legacy：使用legacy內存報告（運行時考慮使用多少內存）。這個策略相當不準確。
erlang：與legacy相同，為了向後兼容而保留
例:
根據 watermarks檢查內存級別。沒發現具體作用。
例:
可用內存總量，不使用特定於操作系統的方式從環境中推斷內存。 只有當節點可用的實際最大RAM數量與節點將要推斷的值不匹配時，才應使用這種方法。 該值可以設置為整數個位元組，或者可以以信息單位（例如「8GB」）設置。 例如，當該值設置為4 GB時，該節點會認為它在具有4 GB RAM的計算機上運行。默認不設置該值。
例:
和vm_memory_high_watermark類似，disk_free_limit是控制硬碟的使用閾值。RabbitMQ正在存儲數據的分區的磁碟可用空間限制。當可用磁碟空間低於此限制時，將觸發流量控制。該值可以相對於RAM的總量或以位元組或以信息單位表示的絕對值（例如"50MB"或"5GB"或"5KB"）來設置，或者，我們可以設置相對於可用RAM總量的限制。低於1.0的值可能很危險，應謹慎使用。默認為disk_free_limit.absolute = 50MB。
例:
網路分裂。一種在系統的任何兩個組之間的所有網路連接同時發生故障後所出現的情況。發生這種情況時，分裂的系統雙方都會從對方一側重新啟動應用程序，進而導致重復服務或裂腦。由網路分裂造成的最為嚴重的問題是它會影響共享磁碟上的數據。默認為ignore模式。如何處理網路分裂？詳細的文檔可以參考 官網文檔
可用的模式是：
在消息中鏡像同步批量大小。增加這將加快同步，但批量總大小（以位元組為單位）不得超過2 GiB。該設置可用於RabbitMQ 3.6.0或更高版本。默認的配置為 mirroring_sync_batch_size = 4096(4k)。
例:
集群相關的配置，為了形成一個集群，新的（「空白」）節點需要能夠發現他們的同伴。這可以使用各種機制（後端）來完成。有些機制假定所有集群成員都提前知道（例如，在配置文件中列出），其他機制是動態的（節點可以動態增刪）。
內置的發現機制如下:
cluster_formation.node_type：節點類型。默認為disc。
cluster_keepalive_interval：像集群里的其他子節點發送存活消息的間隔(毫秒)。默認為cluster_keepalive_interval = 10000
統計相關，與web管理插件顯示有關。可配置的值如下：
例:
設置為true，以便使用HiPE預編譯RabbitMQ的部分，這是Erlang的即時編譯器。 這會以增加啟動時間為代價來提高伺服器吞吐量。
您可能會看到啟動時延遲幾分鍾的成本提高20-50％。 這些數據非常依賴於工作負載和硬體。
HiPE支持可能不會編譯到您的Erlang安裝中。 如果不是，啟用此選項只會導致顯示一條警告消息，啟動將按正常進行。 例如，Debian / Ubuntu用戶需要安裝erlang-base-hipe軟體包。
HiPE在某些平台上完全不可用，特別包括Windows。
HiPE在17.5之前的Erlang / OTP版本中存在已知問題。 HiPE強烈建議使用最新的Erlang / OTP版本。默認的配置為hipe_compile = false。
等待集群中的Mnesia tables變得可用時使用的超時。默認的配置mnesia_table_loading_retry_timeout = 30000。
在等待集群中的Mnesia tables可用時，需要重試的次數。默認的配置mnesia_table_loading_retry_limit = 10。
在消息的位元組數中，消息將被直接嵌入到隊列索引中。詳情請看 persister tuning 。默認的配置queue_index_embed_msgs_below = 4096。
是否啟用後台定期強制GC為「等待」狀態運行節點上的所有Erlang進程。
禁用後台GC可以減少客戶端操作的延遲，保持啟用狀態可以減少二進制堆的RAM使用量（請參閱 https://www.erlang-solutions.com/blog/erlang-garbage-collector.html ）。
在嘗試此選項之前，請查看內存（ http://www.rabbitmq.com/memory-use.html ）。
默認的配置background_gc_enabled = false，當配置為true時，可以設置gc的間隔，默認的配置為background_gc_target_interval = 60000(毫秒)。
設置是否啟用代理，啟用後不能直連到broker。默認的配置proxy_protocol = false。
未知
有關web管理後台的配置。
查看 http://www.rabbitmq.com/stomp.html 。
http://www.rabbitmq.com/mqtt.html
查看 https://github.com/rabbitmq/rabbitmq-amqp1.0
查看 http://rabbitmq.com/ldap.html 。
❷ rabbitmq服務怎樣配置調用本地
AMQP(高級消息隊列協議) 是一個非同步消息傳遞所使用的應用層協議規范，作為線路層協議，而不是API（例如JMS），AMQP 客戶端能夠無視消息的來源任意發送和接受信息。AMQP的原始用途只是為金融界提供一個可以彼此協作的消息協議，而現在的目標則是為通用消息隊列架構提供通用構建工具。因此，面向消息的中間件 （MOM）系統，例如發布/訂閱隊列，沒有作為基本元素實現。反而通過發送簡化的AMQ實體，用戶被賦予了構建例如這些實體的能力。這些實體也是規范的一 部分，形成了在線路層協議頂端的一個層級：AMQP模型。這個模型統一了消息模式，諸如之前提到的發布/訂閱，隊列，事務以及流數據，並且添加了額外的特性，例如更易於擴展，基於內容的路由。
AMQP當中有四個概念非常重要
virtual host，虛擬主機
exchange，交換機
queue，隊列
binding，綁定
一個虛擬主機持有一組交換機、隊列和綁定。
為什麼需要多個虛擬主機呢？因為RabbitMQ當中，用戶只能在虛擬主機的粒度進行許可權控制。因此，如果需要禁止A組訪問B組的交換機/隊列/綁定，必須為A和B分別創建一個虛擬主機。每一個RabbitMQ伺服器都有一個默認的虛擬主機/。
何謂虛擬主機（virtual host），交換機（exchange），隊列（queue）和綁定（binding）
隊列（Queues）是你的消息（messages）的終點，可以理解成裝消息的容器。消息就一直在裡面，直到有客戶端（也就是消費者，Consumer）連接到這個隊列並且將其取走為止。不過，也可以將一個隊列配置成這樣的：一旦消息進入這個隊列，此消息就被刪除。
隊列是由消費者（Consumer）通過程序建立的，不是通過配置文件或者命令行工具。這沒什麼問題，如果一個消費者試圖創建一個已經存在的隊列，RabbitMQ會直接忽略這個請求。因此我們可以將消息隊列的配置寫在應用程序的代碼裡面。
而要把一個消息放進隊列前，需要有一個交換機（Exchange）。
交換機（Exchange）可以理解成具有路由表的路由程序。每個消息都有一個稱為路由鍵（routing key）的屬性，就是一個簡單的字元串。交換機當中有一系列的綁定（binding），即路由規則（routes）。（例如，指明具有路由鍵 「X」 的消息要到名為timbuku的隊列當中去。）
消費者程序（Consumer）要負責創建你的交換機。交換機可以存在多個，每個交換機在自己獨立的進程當中執行，因此增加多個交換機就是增加多個進程，可以充分利用伺服器上的CPU核以便達到更高的效率。例如，在一個8核的伺服器上，可以創建5個交換機來用5個核，另外3個核留下來做消息處理。類似的，在RabbitMQ的集群當中，你可以用類似的思路來擴展交換機一邊獲取更高的吞吐量。
交換機如何判斷要把消息送到哪個隊列？你需要路由規則，即綁定（binding）。一個綁定就是一個類似這樣的規則：將交換機「desert（沙漠）」當中具有路由鍵「阿里巴巴」的消息送到隊列「hideout（山洞）」裡面去。換句話說，一個綁定就是一個基於路由鍵將交換機和隊列連接起來的路由規則。例如，具有路由鍵「audit」的消息需要被送到兩個隊列，「log-forever」和「alert-the-big-de」。要做到這個，就需要創建兩個綁定，每個都連接一個交換機和一個隊列，兩者都是由「audit」路由鍵觸發。在這種情況下，交換機會復制一份消息並且把它們分別發送到兩個隊列當中。交換機不過就是一個由綁定構成的路由表。
交換機有多種類型。他們都是做路由的，但是它們接受不同類型的綁定。為什麼不創建一種交換機來處理所有類型的路由規則呢？因為每種規則用來做匹配分子的CPU開銷是不同的。例如，一個「topic」類型的交換機試圖將消息的路由鍵與類似「dogs.*」的模式進行匹配。匹配這種末端的通配符比直接將路由鍵與「dogs」比較（「direct」類型的交換機）要消耗更多的CPU。如果你不需要「topic」類型的交換機帶來的靈活性，你可以通過使用「direct」類型的交換機獲取更高的處理效率。
❸ Ubuntu16.04搭建rabbitmq集群
1.1、什麼是RabbitMQ？
RabbitMQ 是由 LShift 提供的一個 Advanced Message Queuing Protocol (AMQP) 的開源實現，由以高性能、健壯以及可伸縮性出名的 Erlang 寫成，因此也是繼承了這些優點。
1.2、什麼是AMQP?
AMQP，即Advanced Message Queuing Protocol，高級消息隊列協議，是應用層協議的一個開放標准，為面向消息的中間件設計。它從生產者接收消息並遞送給消費者，在這個過程中，根據規則進行路由，緩存與持久化。
AMQP的主要特徵是面向消息、隊列、路由（包括點對點和發布/訂閱）、可靠性、安全。
RabbitMQ是一個開源的AMQP實現，伺服器端用Erlang語言編寫，支持多種客戶端，如： Python 、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。
1.3、RabbitMQ的基礎概念
1.4、RabbitMQ的特性
2.1、環境：兩台Ubuntu16.04主機
10.27.0.53 rabbitmq-1
10.27.0.130 rabbitmq-2
必須保證各個主機名之間可以ping通
2.2、安裝Erlang
2.3、安裝rabbitmq
2.4、安裝完成後，驗證一下服務是否正常
搭建好的rabbitmq默認是沒有配置文件的，需要我們來手動添加
Rabbitmq的一些運行腳本存放在 /usr/sbin 下面
2.5、開啟web管理插件
2.5.1、創建一個用戶nova，並設置密碼為123456
2.5.2、查看現有用戶表
這個時候nova用戶是不能訪問web管理插件的，需要配置用戶角色，用戶角色可分為五類，超級管理員, 監控者, 策略制定者, 普通管理者以及其他。
可登陸管理控制台(啟用management plugin的情況下)，可查看所有的信息，並且可以對用戶，策略(policy)進行操作。
可登陸管理控制台(啟用management plugin的情況下)，同時可以查看rabbitmq節點的相關信息(進程數，內存使用情況，磁碟使用情況等)
可登陸管理控制台(啟用management plugin的情況下), 同時可以對policy進行管理。但無法查看節點的相關信息。
僅可登陸管理控制台(啟用management plugin的情況下)，無法看到節點信息，也無法對策略進行管理。
無法登陸管理控制台，通常就是普通的生產者和消費者。
將nova添加到administrator用戶組
此時的nova用戶只能通過本地來登錄其他的IP無法直接使用這個賬號。所以需要對他進行授權，使用戶nova /(可以訪問虛擬主機) 中所有資源的配置、寫、讀許可權以便管理其中的資源
查看用戶授權
2.5.3、開啟web管理插件並重啟rabbitmq服務
以下為關閉插件命令
通過瀏覽器訪問 [http://10.27.0.53:15672]輸入用戶名nova 密碼123456就可以看到後台了
3.1、從管理界面可以看到，此時只有一個節點rabbitmq-1，我們需要把rabbitmq-2加進來，rabbitmq-2按照步驟2進行一系列安裝就可以。此處不再細說。
3.2、添加節點
兩台主機上安裝的 RabbitMQ 都保證都可以正常啟動,才可以進行以下操作
3.2.1、設置不同節點間統一認證的Erlang Cookie
這里將 rabbitmq-1 的該文件復制到 rabbitmq-2由於這個文件許可權是 400為方便傳輸，先修改許可權，非必須操作，所以需要先修改rabbitmq-2中的該文件許可權為 777
然後將rabbitmq-1中的該文件拷貝的rabbitmq-2中
最後將許可權和所屬用戶/組修改回來
此時rabbitmq-2節點需要重啟一下服務
注意事項
cookie在所有節點上必須完全一樣，同步時一定要注意。
erlang是通過主機名來連接服務，必須保證各個主機名之間可以ping通。可以通過編輯/etc/hosts來手工添加主機名和IP對應關系。如果主機名ping不通，rabbitmq服務啟動會失敗。
3.2.2、通過rabbitmqctl cluster_status命令，可以查看和個節點的狀態，節點的名稱是rabbit@shorthostname，
rabbitmq-1
rabbitmq-2
3.2.3
將兩個節點組成集群
因為rabbitmq-server啟動時，會一起啟動節點和應用，它預先設置RabbitMQ應用為standalone模式。要將一個節點加入到現有的集群中，你需要停止這個應用並將節點設置為原始狀態，然後就為加入集群准備好了。使用rabbitmqctl stop_app僅僅關閉應用。
將2加入1中
啟動節點2的應用
如果要使用內存節點，則可以使用以下命令：其中–ram指的是作為內存節點,要是想做為磁碟節點的話,就不用加–ram這個參數了
集群配置好後，可以在 RabbitMQ 任意節點上執行 rabbitmqctl cluster_status 來查看是否集群配置成功。
Rabbitmq-1
Rabbitmq-2
同時在Web管理工具中也可以看到效果
上面配置RabbitMQ默認集群模式，但並不保證隊列的高可用性，盡管交換機、綁定這些可以復制到集群里的任何一個節點，但是隊列內容不會復制，雖然該模式解決一部分節點壓力，但隊列節點宕機直接導致該隊列無法使用，只能等待重啟，所以要想在隊列節點宕機或故障也能正常使用，就要復制隊列內容到集群里的每個節點，需要創建鏡像隊列。
鏡像隊列概念：鏡像隊列可以同步queue和message，當主queue掛掉，從queue中會有一個變為主queue來接替工作。鏡像隊列是基於普通的集群模式的,所以你還是得先配置普通集群,然後才能設置鏡像隊列。鏡像隊列設置後，會分一個主節點和多個從節點，如果主節點宕機，從節點會有一個選為主節點，原先的主節點起來後會變為從節點。queue和message雖然會存在所有鏡像隊列中，但客戶端讀取時不論物理面連接的主節點還是從節點，都是從主節點讀取數據，然後主節點再將queue和message的狀態同步給從節點，因此多個客戶端連接不同的鏡像隊列不會產生同一message被多次接受的情況。
設置鏡像隊列策略
在普通集群的中任意節點啟用策略，策略會自動同步到集群節點
命令格式
在任意一個節點上執行
集群重啟
集群重啟時，最後一個掛掉的節點應該第一個重啟，如果因特殊原因（比如同時斷電），而不知道哪個節點最後一個掛掉。可用以下方法重啟：
先在一個節點上執行
在其他節點上執行
查看cluster狀態是否正常（要在所有節點上查詢）。
添加用戶
處於安全的考慮，guest這個默認的用戶只能通過 http://localhost:15672 來登錄，其他的IP無法直接使用這個賬號。所以我們需要添加一個其他用戶。
命令格式
刪除用戶
命令格式
修改密碼
命令格式
用戶授權
命令格式
該命令使用戶nova /(可以訪問虛擬主機) 中所有資源的配置、寫、讀許可權以便管理其中的資源
查看用戶授權
命令格式
查看當前用戶列表
可以看到添加用戶成功了，但不是administrator角色
添加角色
這里我們也將nova用戶設置為administrator角色
命令格式
再次查看許可權
清除許可權信息
命令格式
下一篇為測試文章 https://www.jianshu.com/p/f4153f72e4c1