Kafka又笨又重，为啥不选Redis？-技术圈

往期热门文章：

1、IDEA公司再发新神器！超越 VS Code 骚操作!
2、我怀疑这是 IDEA 的 BUG，但是我翻遍全网没找到证据！
3、Spring MVC 中的 Controller 是线程安全的吗？
4、Gitee 倒下了？？？
5、再见付费的 TeamViewer，这款国产轻量级远程控制软件是绝佳的替代品！

文章来源：【公众号：小姐姐味道】

前言
Redis 很强
Redis Can up
还有好处
总结

前言

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

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

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

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

Redis 很强

因为 Kafka 的对手是 Redis！

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

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

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

可以看到，Streamn 的生产消费模式，几乎和 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.

Redis Can up

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

对于这类系统，甚至是发展势头还不错的中小公司来说，对于消息的需求并没有那么大的要求。

与其引入一个新的 Kafka 组件，不如直接用项目中所存在的 Redis 组件来完成工作。

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

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

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

那还犹豫个毛！怎么简单怎么玩！

还有好处

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

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

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

对于 Redis 来说，领域就在内存里玩，不需要这么多花架子就可以达到比 Kafka 更高的速度。

就连 partition 这个特性，也可以使用不同的 Key 划分来实现，性能自然是比 Kafka 高的。

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

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

总结

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

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

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

往期热门文章：
1、Mybatis-Plus官方发布分库分表神器，一个依赖轻松搞定！
2、Java 中的 BigDecimal，80% 的人竟然都用错了。。。
3、从5秒优化到1秒，系统飞起来了...
4、Java/Spring/Dubbo三种SPI机制，谁更好？
5、我用Java几分钟处理完30亿个数据...
6、炸了！Java多线程批量操作，居然有人不做事务控制
7、Spring Boot 中实现跨域的 5 种方式，你一定要知道！
8、终于用上分库分表了！
9、腾讯可视化, 低代码生成器，正式开源！
10、一行代码解决缓存击穿的问题