文章标题：Redis Stream：消息队列的策略选择
文章内容：在人员规模较大的企业中，通常会有专门的部门来维护成熟的消息队列，以此方便多个业务方实现解耦。而在小型公司里，则需考量成本因素，多依靠个人来处理相关事宜。
有的简易场景下，可能仅仅是借助 Redis list 或者 MySQL 来存储一些状态，若出现问题时自行进行手工补偿，也并非不可行。
当下呈现一种新的取舍方案，运用 Redis Stream 来开展这类业务解耦。其原理十分简洁，如下图示：
生产者 --> [XADD mystream] --> Redis Stream
|
消费者组（mygroup） <----> [XREADGROUP, XACK, XPENDING]
| （自动分派给 consumer-1 / consumer-2 ...）
V
“consumer-1” / “consumer-2” 处理数据
Stream 通过 XADD 推送消息，然后利用 XReadGroup 进行消费，借助 XAck 进行应答，还能使用 XDel 进行删除。
具体细节可大量运用大模型，大模型能够很好地弥补人类大脑在存储方面不擅长的短板。
当然，Redis 的选择也存在自身的痛点，在成熟度、便利性以及性能等方面都存在差距。Stream 是单 Key 结构，即便在 Redis Cluster 中也是基于单点 Key 的哈希分散在不同 slot 之中。虽然可以进行升级，但几万 QPS 对于普通公司而言已足够使用。其优势在于简单便捷，可重复利用，无需额外增添成本去购买组件。
需注意，消息队列有口语化消息队列、带订阅的消息队列以及简单跑任务的任务队列等类型，这里有简单任务队列的代码示例，其中的基本原理是相通的。
sbp/helper/rediser/stream.go at master · wangzhione/sbp
[sbp/helper/rediser/queue.go at master · wangzhione/sbp
](https://github.com/wangzhione/sbp/blob/master/helper/rediser/queue.go)这取决于使用工程师的能力，就如同一道菜肴不会因为食材简单而失分，或许会因为添加过多重料而失去原本的风味。
文章整理自互联网，只做测试使用。发布者：Lomu，转转请注明出处：https://www.it1024doc.com/12595.html
