Redis Stream 实现 MQ 的可行性

早在 4 年前，当我发现 Redis5 中增加了 Stream 类型后我就觉得它的这些特性完全可以实现一个完整的 MQ 中间件功能，当时我还在交控工作，当时的项目刚好涉及到大量数据入库的一个需求，当时这个项目不算很大，所以我就想把这个新的技术引入到项目中，实现一个轻量级的基于 Redis 的消息队列。

最终基本上实现了这个功能，当时也做了一个基于 SpringBoot 的 Demo ，后来又改了一版基于 Jedis 版本的，因为可以自己定义和操作多线程，更加灵活自由的实现一些细节。

最近提离职后正在交接期，自己的时间比较多，又翻出这个早起的 Demo ，想改造一下，用到我的心情记录员项目中，如果精力和时间有的话我更想将它完善为一个完整的、可复用的项目。

心情记录员小程序为什么要用到这个？以及为什么不用其他成熟的 RabbitMQ ，首先不用其他成熟的原因是我不想搞太多中间件，一个项目中 Redis 安装是大多数情况，因此我想在保持单体应用的基础上实现一个 MQ ，另外的一个原因就是折腾，这也是我本人的一个“缺点”，什么都喜欢自己折腾一下，验证可行性。接下来说说应用场景吧，心情记录员这款小程序目前调用的 AI 是 Kimi 的平台，目前因为是前期，因此是免费版本，并发数限制到了 1 ，这就会导致一个问题，如果同时有两个或者多个（意淫一下，哈哈哈）同时点了记录的时候，这时候有一个肯定会报错，这时候就可以用到消息队列了，将请求的数据先放入队列，等前一个 AI 生成结束后再次调用，就这？……，一个队列不就搞定了吗？当然还有场景了，那就是目前 AI 生成我采用的是 Stream 流式返回，而我是在点击记录后就开始生成，点击记录后会跳转到结果页面，为了使用户跳过去立马就感觉到在生成，因此我就将调用 AI 接口的动作提前到跳转页面前点击记录按钮后，然后给一定到 Loading 延迟在跳转，跳转到结果页后建立 WebSocket 连接，根据 openId 标识接收消息，这时候这个消息其实已经在上一步中在生成了，这里就可以用到消息队列了，根据对应的 openId 到消息队列中取内容，服务端的 WebSocket 只需要根据标识从消息队列中缓存的生成结果进行返回即可，提升了响应速度。

大概流程就像下图这样：

4 年前这个项目的库和博客：

Gitee-redismq （原谅我以前使用 Gitee 的行为，哈哈哈）

CSDN 博客（如果对 CSDN 排斥可以访问下面我自己网站的文章）

个人网站文章地址