消息队列, 一种取舍的选择 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看使用工程师能力了, 一道菜不会因为食材简单丢分, 也许会因为猛料太多少了点原味.