動態

詳情 返回 返回

消息隊列, 一種取捨的選擇 Redis Stream - 動態 詳情

人多公司方便多個業務方解耦, 常用一些成熟的消息隊列. 會有專門部門幫你維護好.

但在小公司, 看成本靠個人. 

有的簡單可能就是 redis list or mysql 存一些狀態, 有問題了就自己手工去補償, 也未嘗不可.

這裏帶來一種新的取捨方案. redis stream 來做這類解耦業務. 原理非常簡單如下圖

Producer --> [XADD mystream] --> Redis Stream
                                         |
Consumer Group (mygroup)  <----> [XREADGROUP, XACK, XPENDING]
       |                      (auto-dispatch to consumer-1 / consumer-2 ...)
       V
"consumer-1" / "consumer-2" 處理數據

Stream XADD Push 消息, 然後 XReadGroup 消費, XAck 應答, XDel 刪除 .

具體細節多運用大模型, 大模型很好彌補了人類大腦不善於存儲短板.

 

當然 Redis 取捨也有自身痛點, 成熟性便利性性能都存在差距,

Stream 是 單 Key, 哪怕 Redis Cluster 也是單點 Key Hash 分散在 slot 中.

雖然可以升級, 但幾萬 QPS 足夠普通公司去使用了. 

優勢簡單方便重複利用, 不用增加額外成本花錢買組件. 

 

注: 口語消息隊列, 分帶訂閲消息隊列, 還有簡單跑任務的任務隊列,

這裏簡單任務隊列代碼, 其中積木原理相通的.

sbp/helper/rediser/stream.go at master · wangzhione/sbp

sbp/helper/rediser/queue.go at master · wangzhione/sbp

看使用工程師能力了, 一道菜不會因為食材簡單丟分, 也許會因為猛料太多少了點原味. 

 

nosql , nosql
點贊

Add a new 評論

Some HTML is okay.