RabbitMQ的簡介，關鍵詞，以及是如果運行的，其運作模式有哪一些，在使用的時候需要註意一些什麼。帶著這一些問題，一起進入到文章中去。 ...

聊聊RabbitMQ那一些事兒之一基礎應用

　　Hi,各位熱愛技術的小伙伴您們好，今年的疫情害人啊，真心祝願您和您的家人大家都平平安安，健健康康。年前到現在一直沒有總結點東西，寫點東西，不然久了自己感覺自己都要被廢啦。這個周末花了一些時間來梳理了一下RabbitMQ的相關知識點。先來一個基礎篇，先用起來。我也是一個邊學習邊梳理的過程，如果有什麼梳理的不妥之處，多多指點，相互學習，謝謝！

　　在使用前，我們首先第一件事情就是環境搭建。至於RabbitMQ的環境搭建，我就不在此啰嗦了，網上一搜一大堆，還沒有搭建環境的小伙伴，可以網上找度娘哈，嘿嘿。

一、什麼是MQ

　　MQ簡單的說就是隊列，隊列的特性就是先進先出。我們其實可以把隊列理解為一個消息管道，通過消息管道實現消息傳遞。最終達到不同的進程間、不同服務間的通訊需要。

　　在一個程式中，我們可以通過MQ實現不同進程間的通訊。在不同程式/服務間，我們同樣可以通過MQ來實現相互通訊，這也是本文的重點，這個時候就該今天的主角登場了。

二、RabbitMQ介紹

　　RabbitMQ是一個開源的，在AMQP基礎完整的，可復用的企業消息系統。我個人的簡單的理解就是，實現消息的接收、存儲、管理、分發。在操作系統支持上，支持主流的操作系統（Linux、Windows）；在開發語言介面支持上，支持所有的主流開發語言；在性能上，支持消息持久化、集群化、高併發等等。

三、RabbitMQ關鍵詞介紹

　　Broker（Server）：接受客戶端連接，實現AMQP消息隊列和路由功能的進程，我們可以把Broker叫做RabbitMQ伺服器。

　　Virtual Host：一個虛擬概念，其實簡單的理解你可以認為是在邏輯上對MQ進行分區隔離，這樣避免不同業務的MQ直接交叉感染。一個Virtual Host裡面可以有若幹個Exchange和Queue，主要用於許可權控制，隔離應用。如應用程式A使用VhostA，應用程式B使用VhostB，那麼我們在VhostA中只存放應用程式A的exchange，queue和消息，應用程式A的用戶只能訪問VhostA，不能訪問VhostB中的數據。

　　Exchange：接受生產者發送的消息，並根據Binding規則將消息路由給伺服器中的隊列。ExchangeType決定了Exchange路由消息的行為，例如，在RabbitMQ中，ExchangeType有Direct、Fanout、Topic和Header四種，不同類型的Exchange路由規則是不一樣的（這些以後會詳細介紹）。

　　Queue：消息隊列，用於存儲還未被消費者消費的消息，隊列是先進先出的，預設情況下先存儲的消息先被處理。

　　Message：就是消息，由Header和Body組成，Header是由生產者添加的各種屬性的集合，包括Message是否被持久化、由哪個Message Queue接受、優先順序是多少等，Body是真正傳輸的數據，內容格式為byte[]。

　　Connection：連接，對於RabbitMQ而言，其實就是一個位於客戶端和Broker之間的TCP連接。

　　Channel：信道，僅僅創建了客戶端到Broker之間的連接Connection後，客戶端還是不能發送消息的。需要在Connection的基礎上創建Channel，AMQP協議規定只有通過Channel才能執行AMQP的命令，一個Connection可以包含多個Channel。之所以需要Channel，是因為TCP連接的建立和釋放都是十分昂貴的。

四、RabbitMQ三大角色介紹

　　通過上面的一些簡單介紹，我相信你對MQ有了一個初步的印象。也許你會雲里霧裡的，到底是怎麼運行起來的啊，來一個實際點的。哈哈，不急，下麵馬上進入RabbitMQ跑起來階段。其實要跑起來，我們還要簡單介紹一下RabbitMQ重要的三個角色：生產者、伺服器、消費者。

　　生產者：也就是消息生產方，通過RabbitMQ提高的API，將消息推送到RabbitMQ伺服器。

　　伺服器：RabbitMQ的服務中心，接收生產者生產的消息，並根據分發規則，將消息推送到對應的消費者。

　　消費者：顧名思義，就是消息的最終接收處理者。

　　這樣一來，我相信大家腦海裡面已經有一個畫面了，生產者--生成消息-->伺服器--轉發-->消費者（最終處理消息）。這就是一個消息的整體流程和生命周期。

五、RabbitMQ跑起來

　　通過上面的介紹，我們應該知道MQ的簡單的消息交互的流程。有了這個基礎，下麵我們就分類來介紹一下三大角色的數據交付方式。整體上來說，數據交互方式上有以下5種方式（5種工作模式），在網上找了一張圖，很方便的供大家參考。

　　其實通過上面的圖，我們會發現，前兩種情況，消費者和生成者之間都是直接通過連接，後面三種情況，消費者和生產者直接有一層交換機（Exchange）。這樣一來，我們可以從整體上分為兩個大類：其一、消息直推隊列；其二、消息推送給交換機，交換機根據路由規則轉發至隊列。

　　其實在實際的工作中，第一大類，我們是不會使用到的，都是採用的第二大類來實現實際的項目開發需求。但是第一大類，能夠很好的將我們先領我們入門，先簡單的把程式跑起來。由於時間原因，今天我們也就先實現第一大類的兩種情況，第二大類的，明後天在專門的文章來詳細介紹。

簡單模式：

簡單模式就是只有一個生產者，一個消費者。這個很簡單，下麵用一個實際例子來說明。直接貼代碼：

生產者代碼：

/// <summary>
 /// 消息生成者
 /// </summary>
public class Program
{
    static void Main(string[] args)
    {
        // rabbitMQ鏈接對象
        var factory = new ConnectionFactory();
        // RabbitMQ服務在本地運行
        factory.HostName = "192.168.1.1";
        // RabbitMQ服務埠
        factory.Port = 5672;
        // 用戶名
        factory.UserName = "guest";
        // 密碼
        factory.Password = "guest";
        // 虛擬主機名稱
        factory.VirtualHost = "/";

        // 隊列名稱
        string queueName = "hello";

        // 創建鏈接
        using (var connection = factory.CreateConnection())
        {
            // 創建通道
            using (var channel = connection.CreateModel())
            {
                // 創建一個名稱為hello的消息隊列--當然一步也可以通過RabbitMQ管理後臺添加
                // 當已經存在該隊列時，不會重覆添加，但是如果已存在的隊列和新建的隊列存在屬性差異時，會創建失敗，會拋異常，所以在實際使用時，如果要通過程式創建隊列，最好要捕捉異常，避免因為這樣的問題而導致程式崩潰。
                channel.QueueDeclare(queueName, false, false, false, null);
                Console.WriteLine("我是生成者");

                while (true)
                {
                    Console.WriteLine("請輸入你要發送的消息,並按Enter鍵結束");

                    // 接收用戶輸入的消息
                    string message = Console.ReadLine();
                    // 消息編碼
                    var body = Encoding.UTF8.GetBytes(message);
                    // 向消息伺服器推送消息
                    channel.BasicPublish("", queueName, null, body);

                    Console.WriteLine($"已發送 {System.DateTime.Now.ToString("HH:mm:ss")}： {message}");
                }
            }
        }
    }
}

　　消費者代碼：

 /// <summary>
 /// 消息消費者
 /// </summary>
 public class Program
 {
     static void Main(string[] args)
     {
         // rabbitMQ鏈接對象
         var factory = new ConnectionFactory();
         // RabbitMQ服務在本地運行
         factory.HostName = "192.168.1.1";
         // RabbitMQ服務埠
         factory.Port = 5672;
         // 用戶名
         factory.UserName = "guest";
         // 密碼
         factory.Password = "guest";
         // 虛擬主機名稱
         factory.VirtualHost = "/";

         // 隊列名稱
         string queueName = "hello";

         // 創建鏈接
         using (var connection = factory.CreateConnection())
         {
             // 創建通道
             using (var channel = connection.CreateModel())
             {

                 // 創建一個名稱為hello的消息隊列--當然一步也可以通過RabbitMQ管理後臺添加
                 // 當已經存在該隊列時，不會重覆添加，但是如果已存在的隊列和新建的隊列存在屬性差異時，會創建失敗，會拋異常，所以在實際使用時，如果要通過程式創建隊列，最好要捕捉異常，避免因為這樣的問題而導致程式崩潰。
                 channel.QueueDeclare(queueName, false, false, false, null);
                 Console.WriteLine("我是消費者");

                 // 創建一個消費者
                 var consumer = new EventingBasicConsumer(channel);
                 // 訂閱對應的消息 autoAck:是否自動確認
                 channel.BasicConsume(queueName, autoAck:false, consumer);

                 consumer.Received += (model, ea) =>
                 {
                     var body = ea.Body;
                     var message = Encoding.UTF8.GetString(body);
                     Console.WriteLine($"已接收 {System.DateTime.Now.ToString("HH:mm:ss")}： {message}");

                     // 為了模擬推送過程，在此程式休息1分鐘
                     Thread.Sleep(6000);
                     // 確認消費
                     channel.BasicAck(ea.DeliveryTag, false);
                 };
                 Console.ReadLine();
             }
         }
     }
 }

運行結果：

　　通過實際的運行結果圖，我們很清楚的知道，生產者的消息發生順序，和消費者消費的順序是一直的，這也就MQ的基本原理所在。

上面介紹了簡單模式，下麵我在來介紹一下比簡單模式複雜一點的工作模式。

工作模式：

　　我理解的簡單模式，只是帶我們入門，讓我們明白MQ的運行效果是咋樣的。但是在實際工作中，不可能只會有一個消費者，在實際的生產環境中生產者、消費者都可能會有多個存在，這也就是我們說的工作模式。那麼，有多個生成的者的時候，不同的生產者之間又是怎麼來消費消息的呢?下麵我們先通過實踐的例子來說明：

　　具體的代碼和上面的代碼是一樣的，我們可以直接開兩個消費者就可以實現數據模擬，直接看運行結果：

　　同上面的實際運行結果我們可以簡單的得出以下結論：

　　當一個隊列有多個消費者時，在生成的實時消息時，消息隊列伺服器會輪詢的均勻的分發給每一個消費者。

　　哈哈哈，註意了，上面的結論我說的是實時消息哦，這裡面就包含了一個坑，在實際的使用過程中要特別註意。那就是歷史消息處理上，在實際項目使用過程中，我們經常會遇到，當消費者打開時，隊列中已經有很多消息待消費，這個時候又該如何保證多個消費均勻分配消息呢?避免忙綠的消費者累死現象。其實很簡單，只需在消費端加上如下一個配置即可：

 // 通過Qos設置每次接收消息的條數
 // 三個參數說明
 // prefetchSize：為預取的長度，一般設置為0即可，表示長度不限
 // prefetchCount：表示預取的條數，即發送的最大消息條數
 // global表示是否在Connection中全局設置，true表示Connetion下的所有channel都設置為這個配置。
 channel.BasicQos(prefetchSize: 0,
                  prefetchCount: 1,
                  global: false);

　　上面的配置中，最關鍵的一個參數就是prefetchCount，當我們設置為1時，就是能夠實現均勻的分發。下麵分別對prefetchCount設置不同的值，來看看不同的效果：
　　實例一：將prefetchCount設置為10，並生成3條歷史消息，然後同時打開兩個消費者，看看3條消息的分發消費情況：

　　通過圖，我們得出，3條歷史消息全部推送給了一個消費者，這樣就導致了一個消費者累死，一個消費者閑的慌。
　　實例二：將prefetchCount設置為1，並生成4條歷史消息，然後同時打開兩個消費者，看看3條消息的分發消費情況：

　　通過圖，我們得出，4條歷史消息平均的分發給了兩個消費者，這也是我們想要的效果。
　　所以在實際工作中，一定要註意這一個細節，不然有可能導致在伺服器重啟時，有的伺服器直接卡死現象。
　　好了，時間不早了，今天就先寫到這，明天我們繼續分享後面的幾種模式。在分析完每一種模式後，我還好結合實際，封裝一個dll出來，供大家參考，到時候也會直接把源碼提出來。歡迎大家關註，持續交流。疫情無情，我們學習不能停。加油吧，每一個小伙伴！

END
為了更高的交流，歡迎大家關註我的公眾號，掃描下麵二維碼即可關註，謝謝：