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

Posted 2021-04-24 嘀嗒嘀嗒

前几天有朋友问我有没有用过 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：

---

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