白话 IT 之要不要从 rabbitMQ 转 kafka?

嘀嗒嘀嗒 2016-01-20


前几天有朋友问我有没有用过 kafka,他们在用 rabbitMQ,想考察下要不要转。


本想找个文档文章可以比较好的回答这个问题,没找到特别合适的。自己用 kafka 做过 ElasticSearch 的 ETL 和 service 间的 transaction 同步。也找了一些资料读一读。干脆就这个机会整理下一些心得体会,写写吧。


两年前的时候,kafka 的技术还很不成熟,很多很重要的问题都没有解决。举个例子,kafka 早于 0.8 的版本都不能保证每条 message 至少发送一次。而那个时候,rabbitMQ 已经相对很成熟了,所以很多应该用 kafka 的场景,大家也只能用 rabbitMQ,或者类似的机制。近一年来,kafka 技术日趋成熟,炙手可热,不仅很多应用开始逐步由 rabbitMQ 转 kafka,甚至一些 rabbitMQ 更合适的场景,有人也考虑用 kafka。


那么到底什么情况下用哪一个呢?


其实这两个系统最初的设计理念是很不一样的。RabbitMQ 是正儿八经的基于 Advanced Message Queuing Protocol (AMQP) 的 message broker。而 kafka 是设计成一个更通用的 message system,很大程度上还反映了基于 log 服务的一些思想。还是用一些场景来说明它们的侧重点吧。


一:消息量的大小


如果在网上搜 rabbitMQ 和 kafka 的比较,Google 给的比较靠前面的链接,有一些是从性能来比较的,也就是比它们每秒钟能处理的消息量。例如:


(以下链接请复制后粘贴到浏览器打开)

链接 1:http://mungeol-heo.blogspot.com/2015/01/kafka-vs-rabbitmq-vs-activemq.html

链接 2:http://blog.x-aeon.com/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/


这个比法可以看出,如果你的消息量很大,比如 100k+/sec,那么 rabbitMQ 几乎不能有效处理,大量的消息会滞留在这个 broker 上。但是很多时候,我们的应用如果消息量在一个较小的数量级,这个就不会给 kafka 太大的优势了。要注意的是 kafka 是分布式的消息系统,它的高 throughput,也是部分取决于你是不是有一个比较大的服务器群,如果只是一个很小规模的系统,kafka 可能也没法完全施展它的优势。


二:consumer 的多样性


Kafka 是 producer 为中心的,因此他不会对 consumer 是不是能按需方便的拿到消息,人家才不管你。而 rabbitMQ 是 broker 为中心的,因此它会很大程度上考虑到 consumer 的接受能力等。这就意味着,如果你的 consumer 是各种各样不用的机器或者服务器端,kafka 有着绝对优势。而 rabbitMQ 只能处理相对比较 homogeneous 的 consumer 服务器群。


三:关于 message 的顺序


Kafka 的消息说白了就是一个 log。它会保证所有的消息是 in order 的。但是它也不允许你对消息的顺序有任何改动。与之相反,rabbitMQ 从某种意义上来说,它在每个 queue 上都维护了消息的一个逻辑拷贝。什么意思呢?两个方面。第一,kafka 的消息永远按顺序来,rabbitMQ 的消息投放基本上是不保证顺序的(AMQP 0.9.1 model 中的原话:“one producer channel, one exchange, one queue, one consumer channel" is required for in-order delivery“)。第二,上面说的保证顺序,很多时候是一个优势,但是在一些特定的情况下其实是一个劣势。举个例子。如果在处理一个消息的过程中,一个consumer 突然挂了。kafka 是不管的,怎么善后,由 consumer 客户端自行解决。而对于 rabbitMQ,它可以对消息进行重新排序或重组,这样相对的 queue 就可以重试。换句话说,rabbitMQ 的 broker 帮你在 failure 的时候保存你的状态。而 kafka 的用户,正是因为它允许任意的consumer,所以它其实有一个未知的 consumer 组,那么它的 queue 所有的逻辑都必须是独立于 consumer 的,因此也就没有办法很好的干涉消息的顺序。


四:关于单条 message 的处理


kafka 中每一条消息其实都是没有 id 的。因为全是字节流,消息是通过一个 offset 来标示的。而 rabbitMQ 其实每个 message 有类型,也有标示。这样,一些 fail 的消息就可以被放到未来的一个时间来重新投送和处理。这个消息就叫做 “dead letter” , 然后rabbitMQ 中你可以指定一个 exchange 来专门处理这些消息的重新发送。这个 exchange 就是 dead letter exchange。它可以处理失败消息的重发以及多次失败后的 expiration。


五:小结


总的说来,kafka 支持高流量,但是消息就被当作简单有序的 log,侧重于消息共享,不能做太多的基于逐条消息的处理。而rabbitMQ 支持中小流量,但是在消息处理上有很大的灵活性。最后简单看一下消息的 routing 图示,就能大概明白我说的是什么了:


rabbitMQ routing:



kafka routing:






嘀嗒嘀嗒:白话技术白话硅谷。 偶尔穿插着八八程序员的那些子事儿。 有想听的主题,欢迎留言!长按二维码关注。


本站仅按申请收录文章,版权归原作者所有
如若侵权,请联系本站删除
觉得不错,分享给更多人看到
嘀嗒嘀嗒 热门文章:

亲身参与“引力波”项目之体验    阅读/点赞 : 55310/363

说说 Code Review    阅读/点赞 : 29680/314

我的编程之路    阅读/点赞 : 17059/314

迷茫和进步    阅读/点赞 : 14860/361

说说跳槽这件事    阅读/点赞 : 14005/307

从一条读者留言说起    阅读/点赞 : 13835/411

10%,和那背后的 90%    阅读/点赞 : 13518/351

我的博士生导师    阅读/点赞 : 11227/298

程序媛的碎碎念    阅读/点赞 : 9766/370

嘀嗒嘀嗒:我和微信公众号这一年    阅读/点赞 : 7328/354

嘀嗒嘀嗒 微信二维码

嘀嗒嘀嗒 微信二维码