最近做了些基於redis stream做消息隊列的工作，有人會問，為什么要用redis，而不是專用消息隊列中間件來做呢？
好吧，一個是資源不足問題，另一個也是不想增加依賴項，最終導致了不用ons、rocketmq、rabbitmq來做。
曾經的概念里，用redis做消息隊列都是不正統的，很脆弱的選擇，一般是看不上的，直到最近的redis5 stream特性出來后，就另眼相看了。
stream特性是模仿kafka設計的，有消費組、有ACK機制、能查看已下發但未收到ACK消息列表，確實強大了一個檔次。
這個消費組，需要說下，有了消費組，就代表可以做1對N的事件處理、也可以做1對1的消息處理
消費組中還有consumer，如果某個消費組消息處理不過來，就可以通過增加多個consumer來加快消費速率
發消息、很容易，沒啥說的
由於是框架層面的中間件產，因此consumer收到消息還需要自動觸發業務開發人員編寫的業務處理消息方法，也是個靈活的地方，但是屬於spring bean invoke方面的了，這里略過，總體來說也沒多少技術含量
另外比較重要的地方是監控以及消息轉移部分，比如上線后過段時間后consumer的變動、或者進程、或者docker宕機導致出現了未ack的消息，此時怎樣處理？怎樣監控有這樣的消息存在了？
假設內存不多時，消息隊列消息太多導致占用內存過大，想釋放一部分內存又需要怎樣操作？
這些問題直接用x系列命令操作的話還挺麻煩，最好是寫個程序定時監控上報，然后通過webapi方式來轉移消息等就會好很多。
還好，上面說的這些基礎層面的api redission都提供了，只是要成為半成品的框架，考慮易用性，則還需要自己開發。