前言：
學習收獲：
Redis消息隊列：
消息隊列（Message Queue），字面意思就是存放消息的隊列。最簡單的消息隊列包括3個角色：
- 消息隊列：存儲和管理消息，也被稱為消息代理
- 生產者：發送消息到消息隊列
- 消費者：從消息隊列獲取消息并處理消息
通過消息隊列解除耦合，提高工作效率。使秒殺搶單的業務和寫入數據庫業務分離，解除里耦合。提高了并發能力。
消息隊列是一個獨立與JVM的服務，不受JVM的內存影響，解決了內存限制問題。并且消息隊列不僅僅是做一個數據存儲的問題，還有一個數據安全的問題，存進消息隊列的所有消息會做持久化操作，并且還會確保每個消息至少執行一次。
Redis通過了三種不同的方式來實現消息隊列：
- list結構：基于List結構模擬消息隊列
- PubSub：基本的點對點消息模型
- Stream：比較完善的消息隊列模型
List模擬消息隊列：
Redis的list數據結構是一個雙向鏈表，很容易模擬出隊列效果。隊列時入口和出口不在一邊，因此我們可以利用：LPUSH結合RPOP、或者RPUSH結合LPOP來實現。不過要注意的是，當隊列中沒有消息時RPOP或LPOP操作會返回null，并不像JVM的阻塞隊列那樣會阻塞并等待消息。不過可以通過使用BRPOP或者BLPOP來實現阻塞效果。
與阻塞隊列相比，它是在JVM以外的獨立的存儲，不用依賴內存，不用擔心存儲上限的問題。并且Redis支持數據持久化，如果宕機了，數據也還存在。?
基于List消息隊列的優缺點：
優點：
- 利用Redis存儲，不受限于JVM內存上限
- 基于Redis的持久化機制，數據安全性有保證
- 可以滿足消息有序性
缺點：
- 無法避免消息丟失
- 只支持單消費者：無法實現一條消息被很多消費者消費的需求
基于PubSub（發布訂閱）的消息隊列：
PubSub（發布訂閱）是Redis2.0版本引入的消息傳遞模型。顧名思義，消費者可以訂閱一個或多個channel，生產者向對于channel發送消息后，所有訂閱者都能收到相關消息。
- SUBSCRIBE channel [channel]：訂閱一個或多個頻道
- PUBLISH channel msg：向一個頻道發送消息
- PSUBSCRIBE pattern [pattern]：訂閱于pattern格式匹配的所有頻道
并且基于PubSub的消息隊列天生就是堵塞的。?
基于PubSub消息隊列的優缺點：
優點：
- 采用發布訂閱模型，支持多生產、多消費
缺點：
- 不支持數據持久化
- 無法避免消息丟失
- 消息堆積有上限，超出時數據丟失?
?List有數據持久化，是應為他本來就是做數據存儲的，只是我們把他當作消息隊列來用了。而Redis用來做數據存儲的都支持數據持久化。而PubSub他本來就是做消息發送的，因此當我們發送一條消息是，如果這個頻道沒有被任務消費者訂閱時，那么這條消息就可能丟失。
基于Stream的消息隊列：
Stream是Redis5.0引入的一種新的數據類型，可以實現一個功能非常完善的消息隊列。他是一種以數據流為核心設計理念的消息中間件，它將消息視為連續的數據流進行處理，具備高吞吐量、低延遲、持久化存儲和實時流處理等特性。
- 發送消息的命令：
- 讀消息的方式之一：
在業務開發中，我們可以循環的調用XREAD阻塞方式來查詢最新消息，從而實現持續監聽隊列的效果，偽代碼如下：
?基于Stream類型消息隊列的XREAD命令特點：
- 消息可回溯
- 一個消息可以被多個消費者讀取
- 可以阻塞讀取
- 有消息漏讀的風險?
上面我們介紹的消費方式都是單消費方式，容易發生消息堆積導致消息丟失，所以我們需要改用消費者組的模式。
消費者組：將多個消費者劃分到一個組中，監聽同一個隊列。
- 消息分流：隊列中的消息會分流給組內的不同消費者，而不是重復消費，從而加快消息處理速度
- 消息標示：消費者會維護一個標示，記錄最后一個被處理的消息，哪怕消費者宕機重啟，還會從標示之后讀取消息。確保每一個消息都會被消費
- 消息確認：消費者獲取消息后，消息處于pending狀態，并存入一個pending-list。當處理完成后需要通過XACK來確認消息，標記消息為已處理，才會從pending-list移除。
這里的消息確認會確保所有消息至少會被消費一次，就不會有出現獲取到消息，但是沒有消費的情況。
常見命令：
# 創建消費者組
XGROUP CREATE key groupName ID
# 刪除指定的消費者組
XGROUP DESTORY key groupName
# 給指定的消費者組添加消費者
XGROUP CREATECONSUMER key groupName consumerName
# 刪除消費者組中指定消費者
XGROUP DELCONSUMER key groupName consumerName
# 從消費者組中讀取消息
XREADGROUP GROUP
?
stream類型消息隊列的XREADGROUP命令特點：
-
消息可回溯
-
可以多消費者爭搶消息，加快消費速度
-
可以阻塞讀取
-
沒有消息漏讀的風險
-
有消息確認機制，保證消息至少被消費一次
消除了漏讀的風險，會標記上一次消費 消費到哪里了，然后從此處繼續消費。
總結：
Stream的消息確認僅支持消費者的確認機制，不支持生產者的確認機制（如果生產者再發消息使，消息丟失）。?
基于Redis的Stream實現異步秒殺下單：
1. 創建一個Stream的消息隊列，名為stream.orders
2.?之前是在java代碼中取調用lua腳本，僅僅判斷有沒有資格，然后取利用java代碼去王阻塞隊列里添加。但現在使發消息，就是redis的命令，直接lua腳本里發送，減少了java代碼，和與redis的交互。
?
?在VoucherOrderServiceImpl中編寫Java代碼：
/*** 搶購秒殺券** @param voucherId* @return*/@Transactional@Overridepublic Result seckillVoucher(Long voucherId) {Long userId = ThreadLocalUtls.getUser().getId();long orderId = redisIdWorker.nextId(SECKILL_VOUCHER_ORDER);// 1、執行Lua腳本，判斷用戶是否具有秒殺資格Long result = null;try {result = stringRedisTemplate.execute(SECKILL_SCRIPT,Collections.emptyList(),voucherId.toString(),userId.toString(),String.valueOf(orderId));} catch (Exception e) {log.error("Lua腳本執行失敗");throw new RuntimeException(e);}if (result != null && !result.equals(0L)) {// result為1表示庫存不足，result為2表示用戶已下單int r = result.intValue();return Result.fail(r == 2 ? "不能重復下單" : "庫存不足");}// 2、result為0，下單成功，直接返回ok// 索取鎖成功，創建代理對象，使用代理對象調用第三方事務方法， 防止事務失效IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();this.proxy = proxy;return Result.ok();}
————————————————該文章版權屬于知識汲取者，未經允許請勿轉載原文鏈接：https://blog.csdn.net/qq_66345100/article/details/1319867133.
- 獲取消息隊列中的訂單信息
- 判斷消息獲取是否成功
- 如果獲取失敗，說明沒有消息，繼續下一次循環
- 如果獲取成功，則可以下單
- ACK確認
?qps1000、平均值889、異常率0%、吞吐量474.2，可以看到stream實現的消息隊列并沒有比Java的BlockingQueue實現的消息隊列高多少性能，但是stream實現的信息隊列比BlockingQueue實現的消息隊列的可靠性和靈活性要高一大截。
－IDEA集成調試配置)
)
