选 Redis 做 MQ 的人，是水平欠缺么？-优快云博客

点击上方“芋道源码”，选择“设为星标”

管她前浪，还是后浪？

能浪的浪，才是好浪！

每天 10:33 更新文章，每天掉亿点点头发...

源码精品专栏

Kafka 多牛啊，老少通吃，风光无限，从业务服务到大数据，无所不能。

但即使它这么牛，在不少项目中依然能看到很多的替代品，比如 RabbitMQ、RocketMQ、Pulsar 等。

等等，先不说这些同质的竞争品。在我见到的很多项目里，经常有一只乱入的消息队列，那就是 Redis。还别说，使用还挺广泛的。

是他们傻？还是单纯的水平不够？

Redis 很强

因为 Kafka 的对手是 Redis！

Redis很强，满身的肌肉，几乎是万能的。如果你的内存足够大，你甚至可以把所有的数据放到内存中。

除了常见的 5 种常见的数据结构，Redis 还支持非常多的扩展数据结构，其中就有“借鉴” Kafka 所实现的 Stream 类型。

Stream 就是低配版的 Kafka，有 Kafka 经验的，玩起它来自然不在话下。相对于比较老旧的 LPUSH/BRPOP、PUB/SUB 模式，Stream 在这个场景中完胜。

可以看到，Stream 的生产消费模式，几乎和 Kafka 是一个模子出来的，竟然还有消费组的概念。但 Stream 并没有 Partition 的概念，所以它是个低配版的 Kafka。

我们来看看官网的说明。

Consumer groups were initially introduced by the popular messaging system Kafka (TM). Redis reimplements a similar idea in completely different terms, but the goal is the same: to allow a group of clients to cooperate in consuming a different portion of the same stream of messages.

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能。

项目地址：https://github.com/YunaiV/ruoyi-vue-pro

Redis Can up

在很多软件开发中，尤其是把软件部署到甲方的机器上引入一个新的组件，成本是巨大的。这方面，众多外包和 OD 们应该比较清楚它的凶残。

对于这类系统，甚至是发展势头还不错的中小公司来说，对于消息的需求并没有那么大的要求。与其引入一个新的 Kafka 组件，不如直接用项目中所存在的Redis组件来完成工作。

我们还是来回顾一下消息队列的作用：

削峰：用于承接超出业务系统处理能力的请求，使业务平稳运行。这能够大量节约成本，比如某些秒杀活动，并不是针对峰值设计容量；
缓冲：在服务层和缓慢的落地层作为缓冲层存在，作用与削峰类似，但主要用于服务内数据流转。比如批量短信发送；
解耦：项目尹始，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力；
冗余：消息数据能够采用一对多的方式，供多个毫无关联的业务使用；
健壮性 ：消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。

不好意思，除了内存容量小一点，上面说的这些需求，Redis 的 Stream 全部能够完成。包括对于缓存系统来说比较难得的持久化，它一样支持。

那还犹豫什么，怎么简单怎么玩！

基于微服务的思想，构建在 B2C 电商场景下的项目实战。核心技术栈，是 Spring Boot + Dubbo 。未来，会重构成 Spring Cloud Alibaba 。

项目地址：https://github.com/YunaiV/onemall

还有好处

Kafka 为了增加吞吐量，可以说用尽了心思。比如，

使用 Filesystem Cache、 PageCache 缓存来减少与磁盘的交互；
使用顺序写来增加写入的吞吐量；
使用 Zero-copy 和 MMAP 来减少内存交换；
使用批量，以流的方式进行交互，直顶网卡上限；
使用拉模式进行消息的获取消费，与消费端处理能力相符。

这么一优化下来，虽然功能很强大，但同时膨胀的还有代码加上软件的体积。

对于 Redis 来说，领域就在内存里玩，不需要这么多花架子就可以达到比 Kafka 更高的速度。就连 Partition 这个特性，也可以使用不同的 Key 划分来实现，性能自然是比 Kafka 高的。

再一个，就是使用简单。比如 XADD 指令、XLEN、XRANGE、XREAD 等，指令少且好理解，远比 Kafka 使用简单。

这些优点一汇聚，就不能抵挡它成为 MQ 中的香馍馍。

总结

简单、够用好维护，这么多优点，为什么不选 Redis 呢？给客户上个又笨又重的 Kafka、Pulsar，来给自己添麻烦，何必呢？

当然，以上的评价是对于外包、项目类公司来说的。如果你的公司产品是持续迭代的，持续优化的，又有量，一次性到位选择成熟的额消息队列才是正确的选择。

所以，把 Redis 的 Stream 用在正确的项目、正确的地方的人根本就不傻，他们大智若愚，堪负重任！

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：

已在知识星球更新源码解析如下：

最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。

获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）