⑴ 如何讓rabbitmq在命令行快速啟動
首先保證軟體包正確，然後解壓後依次按下面步驟執行： 打開一個終端，su -成root用戶 1>su root 正確切換到root用戶，然後進入軟體包解壓路徑 2>cd 軟體解壓包路徑 執行軟體解壓包路徑里的軟體安裝腳本 3> ./安裝腳本
⑵ 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 。
⑶ ubuntu怎麼安裝rabbitmq
安裝RabbitMQ服務軟體包
輸入以下命令進行安裝
#apt install rabbitmq-server
安裝完成後在rabbitMQ中添加openstack用戶，為後續安裝openstack提取做好准備
命令：#rabbitmqctl add_user openstack dick
其中dick為openstack用戶登錄rabbitMQ服務的密碼
同時為openstack用戶設置讀寫等許可權
命令：#rabbitmqctl set_permissions openstack ".*" ".*" ".*"
安裝RabbitMQ監控管理插件進行RabbitMQ的管理
命令：#rabbitmq-plugins enable rabbitmq_management
插件rabbitmq_management啟動成功後就可以通過web頁面進行RabbitMQ的監控和管理
使用rabbitmq_management插件進行監控和管理
使用firefox瀏覽器登錄：http://localhost:15672
在登錄頁面使用 guest/guest用戶名和密碼登錄RabbitMQ管理系統，在系統中可以對RabbitMQ服務進行channel,queue,用戶等的管理
安裝pika開發RabbitMQ客戶端
命令: # pip install pika
⑷ win 7 rabbitmq 需要安裝哪些
安裝
1、Rabbit MQ 是建立在強大的Erlang OTP平台上，因此安裝RabbitMQ之前要先安裝Erlang。
注意：
1.現在先別裝最新的 3.6.3 ，本人在安裝完最新的版本，queue 隊列有問題，降到了 3.6.2 就解決了。
2.默認安裝的Rabbit MQ 監聽埠是：5672
配置
1、安裝完以後erlang需要手動設置ERLANG_HOME 的系統變數。
輸入：set ERLANG_HOME=C:\Program Files\erl8.0
如下圖所示：
2、激活Rabbit MQ's Management Plugin
使用Rabbit MQ 管理插件，可以更好的可視化方式查看Rabbit MQ 伺服器實例的狀態，你可以在命令行中使用下面的命令激活。
輸入：rabbitmq-plugins.bat enable rabbitmq_management
如下圖所示：
同時，我們也使用rabbitmqctl控制台命令（位於 rabbitmq_server-3.6.3\sbin>）來創建用戶，密碼，綁定許可權等。
3、創建管理用戶
輸入：rabbitmqctl.bat add_user zhangweizhong weizhong1988
如下圖所示：
4、設置管理員
輸入：rabbitmqctl.bat set_user_tags zhangweizhong administrator
5、設置許可權
輸入：rabbitmqctl.bat set_permissions -p / zhangweizhong ".*" ".*" ".*"
如下圖所示：
6、其他命令
查詢用戶： rabbitmqctl.bat list_users
查詢vhosts： rabbitmqctl.bat list_vhosts
啟動RabbitMQ服務: net stop RabbitMQ && net start RabbitMQ
以上這些，賬號、vhost、許可權、作用域等基本就設置完了。
Rabbit MQ管理後台
使用瀏覽器打開http://localhost:15672 訪問Rabbit Mq的管理控制台，使用剛才創建的賬號登陸系統即可。
Rabbit MQ 管理後台，可以更好的可視化方式查看RabbitMQ伺服器實例的狀態，
創建vhosts
1、創建vhosts, 在admin頁面，點擊右側Virtual Hosts ，
2、 將剛創建的OrderQueue分配給相關用戶。
3、其他創建exchange ，queue 大家自己在後台創建吧，這里不再贅述。
⑸ rabbitmq需要開哪些埠
假設讀者在Windows系列的操作系統中安裝好了Rabbit MQ後，請找到安裝路徑下的etc文件夾下，將rabbitmq.config.example備份一份，並修改為config類型的文件，即為rabbitmq.config，
然後，打開rabbitmq.config，找到tcp_listeners這個key,將其前面的注釋%%去掉，然後將後面的整數值5672改為你想要的埠號，如下圖所示，那麼你的埠號就修改好了
接著，找到heartbeat,去掉注釋，將後面的心跳時間改為你想要的值，並記得去掉後面的逗號！！！
接下來需要編輯環境變數，在系統環境變數中新增變數名"RABBITMQ_CONFIG_FILE",值為你Rabbit MQ安裝目錄下的etcrabbitmq(注意，不要加;),詳見下圖。
最後，用命令對Rabbitmq服務停止、更新、啟動。
登陸web管理界面，在Connections下的Timeout中看到的值是你所修改的，那麼恭喜你，成功了！不是的話，請認真看本博文，再不行，可以找我。
⑹ 如何創建rabbitmq.config文件
1、安裝
在Mac下安裝RabbitMQ是非常簡單的，一般默認RabbitMQ伺服器依賴的Erlang已經安裝，只需要用下面兩個命令就可以完成RabbitMQ的安裝（前提是homebrew已經被安裝）：
?
brew update
brew install rabbitmq
安裝完成後需要將/usr/local/sbin添加到$PATH，可以將下面這兩行加到~/.bash_profile或者~/.profile：
# RabbitMQ Config
export PATH=$PATH:/usr/local/sbin
在Windows下安裝稍微麻煩些，需要先安裝ErLang，然後下載RabbitMQ可執行文件安裝。
2、啟動RabbitMQ服務
上面配置完成後，需要關閉終端窗口，重新打開，然後輸入下面命令即可啟動RabbitMQ服務：
rabbitmq-server！
可以在後面加-detatched選項參數表示以守護進程方式啟動。
⑺ RabbitMQ 鏡像集群 宕機恢復、負載均衡、跨機房多活
起因：在實際項目開發過程中，需要使用RabbitMQ來實現消息隊列的功能，但僅僅實現功能之後並不能對自己滿足，既然學一次，就要更深的了解她，吃一吃架構方面的相關內容，提升自己。
RabbitMQ在鏡像集群中，機器其實是平行關系，所有的節點都是互相復制的
場景描述：
A是Master
B是Slave
A正常運行，B宕機了，只需要啟動B即可，B就會自動加入集群
A和B都宕機了，只要A在B之前啟動就可以了
A和B都宕機了，A啟動不起來了，即便是B啟動了，有可以B直接啟動不了啦
B和C都加入了A為Master的集群，這個時候都需要將B和C從A的集群中forget，B和C啟動不起來了
RabbitMQv3.2版本以後提供了一個離線清除集群節點的命令參數，也就是節點無法啟動狀態下
HAProxy是一款提供高可用的負載均衡器（之前大家都是使用的Nginx居多，upstream反向代理實現負載均衡非常容易），HAProxy可以基於TCP四層（Lvs也是TCP四層的），HTTP七層（Nginx是HTTP七層）的負載均衡應用代理軟體，免費高速可靠的一種LBS解決方案
HAProxy的並發連接完全可以支持以萬為單位的
Nginx
優點：
1、工作在網路7層之上，可針對http應用做一些分流的策略，如針對域名、目錄結構，它的正規規則比HAProxy更為強大和靈活，所以，目前為止廣泛流行。
2、Nginx對網路穩定性的依賴非常小，理論上能ping通就能進行負載功能。
3、Nginx安裝與配置比較簡單，測試也比較方便，基本能把錯誤日誌列印出來。
4、可以承擔高負載壓力且穩定，硬體不差的情況下一般能支撐幾萬次的並發量。
5、Nginx可以通過埠檢測到伺服器內部的故障，如根據伺服器處理網頁返回的狀態碼、超時等，並會把返回錯誤的請求重新提交到另一個節點。
6、不僅僅是優秀的負載均衡器/反向代理軟體，同時也是強大的Web應用伺服器。可作為靜態網頁和圖片伺服器，在高流量環境中穩定性也很好。
7、可作為中層反向代理使用。
缺點：
1、適應范圍較小，僅能支持http、https、Email協議。
2、對後端伺服器的健康檢查，只支持通過埠檢測，不支持url來檢測
3、負載均衡策略比較少：輪詢、權重、IP_hash、url_hash
HAProxy
優點：
1、HAProxy是支持虛擬主機的，可以工作在4、7層(支持多網段)
2、HAProxy的優點能夠補充Nginx的一些缺點，比如支持Session的保持，Cookie的引導；同時支持通過獲取指定的url來檢測後端伺服器的狀態。
3、HAProxy跟LVS類似，本身就只是一款負載均衡軟體；單純從效率上來講HAProxy會比Nginx有更出色的負載均衡速度，在並發處理上也是優於Nginx的。
4、HAProxy支持TCP協議的負載均衡轉發，可以對MySQL讀進行負載均衡，對後端的MySQL節點進行檢測和負載均衡。
5、HAProxy負載均衡策略非常多，HAProxy的負載均衡演算法現在具體有如下8種
缺點：
1、不支持POP/SMTP協議
2、不支持SPDY協議
3、不支持HTTP cache功能。現在不少開源的lb項目，都或多或少具備HTTP cache功能。
4、重載配置的功能需要重啟進程，雖然也是soft restart，但沒有Nginx的reaload更為平滑和友好。
5、多進程模式支持不夠好
HAProxy+Keepalived（負載均衡節點的高可用）
將上面的配置文件內容放入 /etc/haproxy/haproxy.cfg中
啟動HAProxy
啟用成功後可以到控制台進行驗證
通過federation的配置來進行數據通道搭建
這個時候你需要自己定義一個上游節點upstream(166節點)，一個下游節點downstream(167節點)，federation是單向發送的，相當於消息發送到upstream的一個exchange上，然後轉發到downstream的queue上
1、 在下游節點創建一個exchage和一個queue和binding的routingkey，用來進行數據接收
2、 在下游節點建立federation upstream規則和上游節點進行數據同步
3、 進入下游節點的federation status沒有任何數據，需要建立策略來保證通道連通
4、 進入下游節點的Policy菜單，Pattern是個正則表達式，這里表示以down開頭的exchange和queue都匹配
5、 這個時候看exchange和queue，規則就應用上了
6、 這個時候去federation status看，發現上游連接已經連接上了
7、 這個時候我們先去看上游的overview
8、 再看上游的exchange和queue就已經根據下游配置的upstream和policy規則將exchange和queue創建好了
灰色的這個重定向exchange不能發送消息，如果要發送則在down-exchange上進行發送
9、 我們在上游的down-exchange發送一條消息，進行測試
可以在下游查看這條消息
10、 因為上游及節點只是一個中轉，如果上游及誒單也要消息down-exchange里的消息怎麼辦？
只需要在本地建立一個binding關系就好
不要以為每天把功能完成了就行了，這種思想是要不得的，互勉~！
⑻ RabbitMQ啟動失敗
你在發送的時候指定exchange即可 這里用pika做例 channel.basic_publish(exchange=test_exchange, routing_key='', body=message, properties=pika.BasicProperties(delivery_mode = 2) ) 然後在接收的時候聲明你的隊列綁定這個exchange