The following article is from 小姐姐味道 Author 小姐姐养的狗
不羡鸳鸯不羡仙,一行代码调半天
Kafka 多牛啊,老少通吃,风光无限,从业务服务到大数据,无所不能。
但即使它这么牛,在不少项目中依然能看到很多的替代品,比如 RabbitMQ、RocketMQ、Pulsar 等。
等等,先不说这些同质的竞争品。在我见到的很多项目里,经常有一只乱入的消息队列,那就是 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.
在很多软件开发中,尤其是把软件部署到甲方的机器上引入一个新的组件,成本是巨大的。这方面,众多外包和 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 用在正确的项目、正确的地方的人根本就不傻,他们大智若愚,堪负重任!
- EOF -
看完本文有收获?请转发分享给更多人
关注「ImportNew」,提升Java技能
点赞和在看就是最大的支持❤️