消息队列, 一种取舍的选择 Redis Stream

人多公司方便多个业务方解耦, 常用一些成熟的消息队列. 会有专门部门帮你维护好.
但在小公司, 看成本靠个人. 
有的简单可能就是 redis list or mysql 存一些状态, 有问题了就自己手工去补偿, 也未尝不可.
这里带来一种新的取舍方案. redis stream 来做这类解耦业务. 原理非常简单如下图

1. Producer --> [XADD mystream] --> Redis Stream
2.                                          |
3. Consumer Group (mygroup)  <----> [XREADGROUP, XACK, XPENDING]
4.        |                      (auto-dispatch to consumer-1 / consumer-2 ...)
5.        V
6. "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看使用工程师本领了, 一道菜不会由于食材简单丢分, 也许会由于猛料太多少了点原味. 
 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。