以下文章来源于小姐姐味道 ,作者小姐姐养的狗
不羡鸳鸯不羡仙,一行代码调半天
文章来源:【公众号:小姐姐味道】
前言
Redis 很强
Redis Can up
还有好处
总结
前言
Kafka 多牛啊,老少通吃,风光无限,从业务服务到大数据,无所不能。
但,即使它这么牛 x,在不少项目中,依然能看到很多的替代品,比如 RabbitMQ、RocketMQ、Pulsar 等。
是他们傻?还是单纯的水平不够?
Redis 很强
因为 Kafka 的对手是 Redis!
Redis 很强,满身的肌肉,几乎是万能的。如果你的内存足够大,你甚至可以把所有的数据放到内存中。
除了常见的 5 种常见的数据结构,Redis 还支持非常多的扩展数据结构,其中就有“借鉴”Kafka 所实现的 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 用在正确的项目,正确的地方的人,根本就不傻,他们大智若愚,堪负重任!
------------- END ------------- 扫码免费获取600+页石杉老师原创精品文章汇总PDF
原创技术文章汇总
点个在看你最好看
网友评论已有0条评论, 我也要评论