https://blog.csdn.net/d_g_h/article/details/79643714

https://blog.csdn.net/tTU1EvLDeLFq5btqiK/article/details/80971792

目前對訊息佇列並不瞭解其原理，本篇文章主要是通過慕課網學習歸納的一些筆記，為後續學習打下基礎。

眾所周知在對網站設計的時候，會遇到給使用者“群發簡訊”，“訂單系統有大量的日誌”，“秒殺設計”等，伺服器沒法處理這種瞬間迸發的壓力，這種情況要保證系統正常有效的使用，就需要“訊息佇列”的幫助。本篇主要通過訊息佇列的思路進行學習。

主要了解如下知識：

　　1、佇列是個什麼東西，他能幹什麼？

　　2、對列的應用場景有哪些？

　　3、如何使用佇列對業務進行解偶？

　　4、如何使用Redis佇列來消除高壓力？

　　5、專業的對列系統RabbitMQ如何使用？

歸納如下主要內容

　　@訊息佇列的概念，原理和場景

　　@解耦案例：佇列處理訂單系統和配送系統

　　@流量削峰案例：Redis的List型別實現秒殺

　　@RabbitMQ：更專業的訊息系統實現方案

一、認識訊息佇列

1.1 訊息對列概念

　　從本質上說訊息對列就是一個佇列結構的中介軟體，也就是說訊息放入這個中介軟體之後就可以直接返回，並不需要系統立即處理，而另外會有一個程式讀取這些資料，並按順序進行逐次處理。

　　也就是說當你遇到一個併發特別大並且耗時特別長同時還不需要立即返回處理結果，使用訊息佇列可以解決這類問題。

1.2 核心結構

由一個業務系統進行入隊，把訊息逐次插入到訊息佇列中，插入成功之後直接返回成功的結果，後續會有一個訊息處理系統，這個系統會把訊息系統中的記錄逐次進行取出並進行處理，完成一個出隊的流程。

1.3 應用場景

　　資料冗餘：比如訂單系統，後續需要嚴格的進行資料轉換和記錄，訊息佇列可以把這些資料持久化的儲存在佇列中，然後有訂單，後續處理程式進行獲取，後續處理完之後在把這條記錄進行刪除來保證每一條記錄都能夠處理完成。

　　系統解耦：使用訊息系統之後，入隊系統和出隊系統是分開的，也就說只要一天崩潰了，不會影響另外一臺系統正常運轉。

　　流量削峰：例如秒殺和搶購，我們可以配合快取來使用訊息佇列，能夠有效的頂住瞬間訪問量，防止伺服器承受不住導致崩潰。

　　非同步通訊：訊息本身使用入隊之後可以直接返回。

　　擴充套件性：例如訂單佇列，不僅可以處理訂單，還可以給其他業務使用。

　　排序保證：有些場景需要按照產品的順序進行處理比如單進單出從而保證資料按照一定的順序處理，使用訊息佇列是可以的。

以上都是訊息佇列常見的使用場景，當然訊息佇列只是一箇中間件，可以配合其他產品進行使用。

1.4 常見佇列實現優缺點

　　佇列介質

　　　　1、資料庫，例如mysql（可靠性高，易實現，速度慢）

　　　　2、快取， 例如redis （速度快，單個訊息報包過大時效率低）

　　　　3、訊息系統，例如rabbitMq （專業性強，可靠，學習成本高）

　　訊息處理觸發機制

　　　　1、死迴圈方式讀取：易實現，故障時無法及時恢復；（比較適合做秒殺，比較集中，運維集中維護）

　　　　2、定時任務：壓力均分，有處理上限；目前比較流行的處理觸發機制。（唯一的缺點是間隔和資料需要注意，不要等上一個任務沒有完成下一個任務又開始了）

　　　　3、守護程序：類似於php-fpm 和php-cg,需要shell基礎

二、解藕案例：佇列處理“訂單系統”和“配送系統”

　　簡單說一下程式解耦：程式解耦就是避免出現你老婆和你媽同時掉到水裡先去救誰的問題（偷笑ing）

　　對於訂單流程，我們可以設計兩個系統，一個是“訂單系統” 另外一個是 “配送系統”， 在網購的時候我們應該都見過，當我提交了一個訂單之後，我在後臺可以看到我的貨物正在配送中。這個時候就要參與進來一個“配送系統”。

　　如果我們在做架構的時候把 “訂單系統” 和 “配送系統” 設計在一起的話就會出現一些問題，首先對於訂單系統來說，因為系統的壓力會比較大，但是 "配送系統" 沒必要為這些壓力做一些即時的反應。

　　第二個我們也不希望在訂單系統出現故障之後導致配送系統也出現故障，這個時候就會同時影響到兩個系統的正常運轉。所以我們希望把這兩個系統進行解耦。這兩系統分開之後我們可以通過一箇中間的 “隊列表” 進行這兩個系統的溝通。

2.1 架構設計

　　1、首先訂單系統會接收使用者的訂單，然後進行訂單的處理。

　　2、然後會把這些訂單資訊寫到隊列表中，這個隊列表是溝通這兩個系統的關鍵。

　　3、由配送系統定時執行的一個程式來讀取隊列表進行處理。

　　4、配送系統處理之後，會把已處理的記錄進行標記。

2.2 程式流程

三、流量削峰案例：Redis 的 list 型別實現秒殺

　　redis 基於記憶體，它的速度會非常快，redis 對資料庫有一個非常好的補充作用因為它是可持久化的，redis會週期性的把資料寫到硬盤裡，所以它不用擔心斷電的問題，從這方面說它比另一款快取 memcache 更有優勢些，另外 redis 提供五種資料型別（字串，雙向連結串列，雜湊，集合，有序集合）

　　一般情況下，做秒殺案例，搶購，瞬間高比你高發，需要排隊 的案例中 redis是一個很好的選擇。

3.1 redis資料型別中的 list 型別

　　redis 的list 是一個雙向連結串列，可以從頭部或者尾部追加資料。

　　* LPUSH/LPUSHX :將值插入到（/存在的）列表頭部

　　* RPUSH/RPUSHX: 將值插入到（/存在的）列表尾部

　　* LPOP : 移除並獲取列表的第一個元素

　　* RPOP: 移除並獲取列表的最後一個元素

　　* LTRIM: 保留指定區間內的元素

　　* LLEN: 獲取列表長度

　　* LSET: 通過索引設定列表元素的值

　　* LINDEX: 通過索引獲取列表中的元素

　　* LRANGE: 獲取列表指定範圍內的元素

3.2 架構設計

　　一個簡單結構秒殺的程式設計。

　　1、首先記錄是哪一個使用者參與了秒殺同時記錄他的時間。

　　2、將使用者的id存到redis列表中，讓它排隊。如果規定只有前10個使用者可以參與成功，如果列表中的個數已經夠了就不會讓它繼續追加資料。這樣redis的列表長度就只會是10個

　　3、最後在慢慢的將redis中的資料寫入到資料庫中，以減少資料的壓力

3.3 程式碼級設計

　　1、當用戶開始秒殺時，將秒殺程式的請求寫入Redis (uid, time_stamp)中。

　　2、假使規定只有10人可以秒殺成功，檢查 Redis 已經存放資料的長度，超出上限直接丟棄說明秒殺完成。

　　3、最後在死迴圈處理存入Redis中的10條資料，然後在慢慢的取資料並存入到mysql資料庫中。

在秒殺這一塊對於資料庫的壓力特別的大，如果我們沒有這樣的設計，會造成mysql的寫入瓶頸。我們通過Redis的一個對列list，然後把秒殺的請求放入到Redis裡面， 最後通過入庫程式，把資料慢慢的寫入到資料庫，這樣的話就可以實現流量的均衡，對mysql不會造成太大的壓力。　

四、RabbitMQ

　　這裡講解一些RabbitMQ的使用，首先我們之前講秒殺案例的時候提到了鎖的機制，防止其他程式處理同一條記錄，如果我們的系統架構非常的複雜，有多個程式實時的讀取一個佇列，或者我有多個傳送程式，同時來操作一個或多個佇列，甚至我還想這些程式分佈在不同的機器上，這種情況下用redis佇列就有些力不從心了。這種時候怎麼辦呢，我們就需要來引入一些更專業的訊息佇列系統，這些系統可以更好的來解決問題。

4.1 RabbitMQ的架構和原理

特點：完整的實現了AMQP,叢集簡化，持久化，跨平臺

　　RabbitMQS使用

　　　　1、RabbitMQ安裝 （rabbitmq-server, php-amqplib）

　　　　2、生產者向訊息通道傳送訊息

　　　　3、消費者處理訊息

　　工作佇列

　　　　思想：由生產者傳送給訊息系統，訊息系統把任務封裝成訊息佇列之後，然後供多個消費者使用同一個佇列

　　　　這不僅解決了生產者和消費者之間的解耦，還可以實現了消費者和任務的共享，減緩了伺服器的壓力。

五、總結

　　以上主要學習訊息佇列的概念，原理，場景。解耦案例以及削峰案例，以及瞭解RabbitMQ的簡單使用方法。

六、問題

　　redis 和訊息伺服器 選擇的最大區別是什麼。

　　　　我的理解是Redis 是一個一個處理請求，redis屬於單執行緒，它和訊息伺服器 IO 的實現方式不同，一個是同步一個是非同步，而redis使用的是同步阻塞，而訊息伺服器使用的是非同步非阻塞。

常見 佇列實現 的優缺點
佇列介質：

Mysql：可靠性高、易實現、速度慢
Redis：速度快，單條大訊息包時效率低
訊息系統：專業性強、可靠，學習成本高(比如：RabbtiMQ)
1
2
3
訊息處理的觸發機制：

死迴圈方式讀取：易實現，故障時無法及時恢復；
定時任務：壓力均分，有處理量上限。(最大的缺陷：定位任務時間的間隔和處理的資料需要精準把握，不能上一個任務還沒有處理完成，下一個認為就已經啟動了)

守護程序：類似於PHP-FPM和PHP-CGI，需要shell知識

---------------------
作者：D_G_H
來源：CSDN
原文：https://blog.csdn.net/d_g_h/article/details/79643714
版權宣告：本文為博主原創文章，轉載請附上博文連結！