一、前言
消息隊列（Message Queue）是分佈式系統必不可少的中間件，大部分消息隊列產品（如RocketMQ/RabbitMQ/Kafka等）要求團隊有比較強的技術實力，不適用於中小團隊，並且對.NET技術的支持力度不夠。而Redis實現的輕量級消息隊列很簡單，僅有Redis常規操作，幾乎不需要開發團隊掌握額外的知識！
說到Redis不得不推薦我基於新生命研發的高性能Redis組件 NewLife.Redis 二次封裝的組件庫Shiny.Redis,支持.net core3,.net5,.net6。該組件在原來的基礎上封裝成了單例模式，只需一句話即可完成組件註冊，通過構造函數直接注入就行。
寫這篇文檔的目的，是因爲在最近開發過程中，需要用到多端訂閱的功能，之前設計的時候用的是rockemq，最近又重新整理了一遍項目架構，把orm替換成了二次封裝的shinysqlsugar,redis也替換成了shiny.redis，正好看到newlife.redis已經實現了多端消費的redis隊列，所以試着把rockemq改成redis隊列，但是在使用過程中，發現官方的文檔還是比較難懂的，有些地方沒寫明白，還好方法又註釋，連蒙帶猜終於弄懂了，覺得還是有必要把這部分寫成文檔以供後面新人學習使用。
二、什麼是消息隊列
消息隊列就是消息在傳輸過程中保存消息的容器，其核心功用是削峯和解耦！
早高峯，快遞公司的貨車前來各驛站卸貨，多名站點工作人員使用PDA掃描到站，大量信息進入系統（1000tps），而通知快遞公司的接口只有400tps的處理能力。
通過增加MQ來保存消息，讓超過系統處理能力的消息滯留下來，等早高峯過後，系統即可完成處理。此爲削峯！
在快遞櫃業務流程中，快遞員投櫃後需要經歷扣減系統費、短信通知用戶和推送通知快遞公司三個業務動作。傳統做法需要依次執行這些業務東西，如果其中某一步異常（例如用戶手機未開機或者快遞公司接口故障），將會延遲甚至中斷整個投櫃流程，嚴重影響用戶體驗。
如果接口層收到投櫃數據後，寫入消息到MQ，後續三個子系統各自消費處理，將可以完美解決該問題，並且子系統故障不影響上游系統！此爲解耦！