1. MQ的應用場景

1.1 異步處理

場景說明：使用者注冊後，需要發注冊郵件和注冊短信,傳統的做法有兩種 1.串行的方式 2.并行的方式

串行方式: 将注冊資訊寫入資料庫後,發送注冊郵件,再發送注冊短信,以上三個任務全部完成後才傳回給用戶端。這有一個問題是,郵件,短信并不是必須的,它隻是一個通知,而這種做法讓用戶端等待沒有必要等待的東西.

并行方式:将注冊資訊寫入資料庫後,發送郵件的同時,發送短信,以上三個任務完成後,傳回給用戶端,并行的方式能提高處理的時間。

消息隊列:假設三個業務節點分别使用50ms,串行方式使用時間150ms,并行使用時間100ms。雖然并行已經提高的處理時間,但是,前面說過,郵件和短信對我正常的使用網站沒有任何影響，用戶端沒有必要等着其發送完成才顯示注冊成功,應該是寫入資料庫後就傳回. 消息隊列: 引入消息隊列後，把發送郵件,短信不是必須的業務邏輯異步處理

由此可以看出,引入消息隊列後，使用者的響應時間就等于寫入資料庫的時間+寫入消息隊列的時間(可以忽略不計),引入消息隊列後處理後,響應時間是串行的3倍,是并行的2倍。

1.2 應用解耦

場景：雙11是購物狂節,使用者下單後,訂單系統需要通知庫存系統,傳統的做法就是訂單系統調用庫存系統的接口.

這種做法有一個缺點:

當庫存系統出現故障時,訂單就會失敗。訂單系統和庫存系統高耦合. 引入消息隊列

訂單系統:使用者下單後,訂單系統完成持久化處理,将消息寫入消息隊列,傳回使用者訂單下單成功。
庫存系統:訂閱下單的消息,擷取下單消息,進行庫操作。就算庫存系統出現故障,消息隊列也能保證消息的可靠投遞,不會導緻消息丢失.

1.3 流量削峰

場景: 秒殺活動，一般會因為流量過大，導緻應用挂掉,為了解決這個問題，一般在應用前端加入消息隊列。

作用:

1.可以控制活動人數，超過此一定閥值的訂單直接丢棄(我為什麼秒殺一次都沒有成功過呢^^)

2.可以緩解短時間的高流量壓垮應用(應用程式按自己的最大處理能力擷取訂單)

1.使用者的請求,伺服器收到之後,首先寫入消息隊列,加入消息隊列長度超過最大值,則直接抛棄使用者請求或跳轉到錯誤頁面.

2.秒殺業務根據消息隊列中的請求資訊，再做後續處理。

2、RabbitMQ叢集搭建

2.1 普通叢集(副本叢集)

預設情況下:RabbitMQ代理操作所需的所有資料/狀态都将跨所有節點複制。這方面的一個例外是消息隊列，預設情況下，消息隊列位于一個節點上，盡管它們可以從所有節點看到和通路

2.1.1 架構圖

2.1.2 叢集搭建

1、叢集規劃：這裡用三台虛拟機測試

複制代碼 192.168.159.111 mq1
 192.168.159.39 mq2
 192.168.159.40 mq3

2、克隆三台機器主機名和ip映射

在三台機器中追加如下操作：

bash複制代碼 vim /etc/hosts

添加如下配置：

複制代碼 192.168.159.111 mq1
 192.168.159.39 mq2
 192.168.159.40 mq3

三台節點分别修改主機名

bash複制代碼 node1: vim /etc/hostname 加入:  mq1
 node2: vim /etc/hostname 加入:  mq2
 node3: vim /etc/hostname 加入:  mq3

3 在其他兩台節點上安裝rabbitmq

這個就大概說一下，網上教程太多了

(1).将rabbitmq安裝包上傳到linux系統中

(2).安裝Erlang依賴包

複制代碼 rpm -ivh erlang-22.0.7-1.el7.x86_64.rpm

(3).安裝rabbitmq

vbscript複制代碼 rpm -ivh rabbitmq-server-3.7.18-1.el7.noarch.rpm

注意:預設安裝完成後配置檔案模闆在:/usr/share/doc/rabbitmq-server-3.7.18/rabbitmq.config.example目錄中,需要将配置檔案複制到/etc/rabbitmq/目錄中,并修改名稱為rabbitmq.config

(4).複制配置檔案

bash複制代碼 cp /usr/share/doc/rabbitmq-server3.7.18/rabbitmq.config.example /etc/rabbitmq/rabbitmq.config

(5).檢視配置檔案位置

bash複制代碼 ls /etc/rabbitmq/rabbitmq.config

(6).修改配置檔案

arduino複制代碼vim /etc/rabbitmq/rabbitmq.config

将上圖中配置檔案中%%去掉,以及最後的,逗号修改為下圖:

(7).啟動rabbitmq中的插件管理

bash複制代碼rabbitmq-plugins enable rabbitmq_management

常用指令：

vbscript複制代碼systemctl start rabbitmq-server
systemctl restart rabbitmq-server
systemctl stop rabbitmq-server

4.背景啟動rabbitmq所有節點執行如下指令,啟動成功通路管理界面:

vbscript複制代碼rabbitmq-server -detached

警告是因為沒有PID檔案的寫入權限，先不用管。

5.在node2和node3執行加入叢集指令:

(1)先将node2和node3節點關閉，

複制代碼rabbitmqctl stop_app

(2)将node2和node3加入叢集

css複制代碼rabbitmqctl join_cluster rabbit@mq1

(3)啟動服務

啟動mq2和mq3

複制代碼rabbitmqctl start_app

6.檢視叢集狀态,任意節點執行:

複制代碼rabbitmqctl cluster_status

此時叢集已經搭建成功，登入管理界面檢視：

7、測試在node1上添加交換機

檢視node2和node3結點是否同步

8、測試在node1上添加隊列

此時node2和node3結點也可以看到該隊列，但是一旦主節點當機，node2和node3是不能對外提供服務的。

2.2 鏡像隊列

鏡像隊列機制就是将隊列在三個節點之間設定主從關系，消息會在三個節點之間進行自動同步，且如果其中一個節點不可用，并不會導緻消息丢失或服務不可用的情況，提升MQ叢集的整體高可用性。

2.2.1 架構圖

2.2.2 配置

剛開始的時候隻有個持久化，沒有其他政策

(1)添加政策(在任意一台節點上執行)

css複制代碼rabbitmqctl set_policy ha-all '^hello' '{"ha-mode":"all","ha-sync-mode":"automatic"}'

(2)生産者測試發一條消息

(3)将主節點node1當機

(4)檢視從節點狀态

node2:

node3:

(5)此時測試消息是否能被消費

直接去連接配接從節點，假設連接配接node2

可以看到，從節點的消息是能否被消費掉的

隊列中的消息也沒有了。

(6)此時恢複node1

可以看到，此時node2變成了主節點

(6)删除政策

css複制代碼rabbitmqctl clear_policy ha-all

隊列也不再是鏡像隊列了。

RabbitMQ應用場景和叢集搭建