vlambda博客
学习文章列表

基于某些原因， 许多开发者会把这两种技术当做等价的来看待。的确，在一些案例场景下选择 RabbitMQ 还是 Kafka 没什么差别，但是这两种技术在底层实现方面是有许多差异的。

不同的场景需要不同的解决方案，选错一个方案能够严重的影响你对软件的设计，开发和维护的能力。

介绍了 内部实现的相关概念。本篇文章会从两个方面探讨这两种技术之间的差异，一个是这两种技术之间的显著差异，另一个是对于软件架构师和开发者需要注意的差异。

我们先来说说架构模式，也就是我们尝试着利用这两种技术来实现的架构模式，并且评估什么时候该使用哪一个。

注意 1：如果你对 RabbitMQ 和 Kafka 的内部结构还不熟悉，我强烈推荐你阅读我之前的第一篇文章《》。

如果你不确定，那么可以简要的看一下里面的标题和图表，至少对这些差异有个大概的了解。

注意 2：上一篇文章发表之后，有些读者问我对于 Apache Pulsar 的看法。Pulsar 是另一种类型的消息系统，它旨在提供 RabbitMQ 和 Kafka 都有的一些优点。

作为一个现代的消息系统，它看上去很有前途；但是像其他平台系统一样，都有各自的优缺点。

这边文章主要是比较 RabbitMQ 和 Kafka，之后我会尝试针对 Apache Pulsar 做一个比较。

RabbitMQ 是一个消息代理，但是 Apache Kafka 是一个分布式流式系统。好像从语义上就可以看出差异，但是它们内部的一些特性会影响到我们是否能够很好的设计各种用例。

例如，Kafka 最适用于数据的流式处理，但是 RabbitMQ 对流式中的消息就很难保持它们的顺序。

另一方面，RabbitMQ 内置重试逻辑和死信（dead-letter）交换器，但是 Kafka 只是把这些实现逻辑交给用户来处理。

这部分主要强调在不同系统之间它们的主要差异。

对于发送到队列或者交换器上的消息，RabbitMQ 不保证它们的顺序。尽管消费者按照顺序处理生产者发来的消息看上去很符合逻辑，但是这有很大误导性。

换话句话说，只要我们是单个消费者，那么接收到的消息就是有序的。然而，一旦有多个消费者从同一个队列中读取消息，那么消息的处理顺序就没法保证了。

由于消费者读取消息之后可能会把消息放回（或者重传）到队列中（例如，处理失败的情况），这样就会导致消息的顺序无法保证。

一旦一个消息被重新放回队列，另一个消费者可以继续处理它，即使这个消费者已经处理到了放回消息之后的消息。

因此，消费者组处理消息是无序的，如下表所示：

使用 RabbitMQ 丢失消息顺序的例子

当然，我们可以通过限制消费者的并发数等于 1 来保证 RabbitMQ 中的消息有序性。

更准确点说，限制单个消费者中的线程数为 1，因为任何的并行消息处理都会导致无序问题。

不过，随着系统规模增长，单线程消费者模式会严重影响消息处理能力。所以，我们不要轻易的选择这种方案。

另一方面，对于 Kafka 来说，它在消息处理方面提供了可靠的顺序保证。Kafka 能够保证发送到相同主题分区的所有消息都能够按照顺序处理。

回顾介绍，默认情况下，Kafka 会使用循环分区器（round-robin partitioner）把消息放到相应的分区上。

不过，生产者可以给每个消息设置分区键（key）来创建数据逻辑流（比如来自同一个设备的消息，或者属于同一租户的消息）。

所有来自相同流的消息都会被放到相同的分区中，这样消费者组就可以按照顺序处理它们。

但是，我们也应该注意到，在同一个消费者组中，每个分区都是由一个消费者的一个线程来处理。结果就是我们没法伸缩（scale）单个分区的处理能力。

不过，在 Kafka 中，我们可以伸缩一个主题中的分区数量，这样可以让每个分区分担更少的消息，然后增加更多的消费者来处理额外的分区。

获胜者：显而易见，Kafka 是获胜者，因为它可以保证按顺序处理消息。RabbitMQ 在这块就相对比较弱。

RabbitMQ 可以基于定义的订阅者路由规则路由消息给一个消息交换器上的订阅者。一个主题交换器可以通过一个叫做 routing_key 的特定头来路由消息。

或者，一个头部（headers）交换器可以基于任意的消息头来路由消息。这两种交换器都能够有效地让消费者设置他们感兴趣的消息类型，因此可以给解决方案架构师提供很好的灵活性。

另一方面，Kafka 在处理消息之前是不允许消费者过滤一个主题中的消息。一个订阅的消费者在没有异常情况下会接受一个分区中的所有消息。

作为一个开发者，你可能使用 Kafka 流式作业（job），它会从主题中读取消息，然后过滤，最后再把过滤的消息推送到另一个消费者可以订阅的主题。但是，这需要更多的工作量和维护，并且还涉及到更多的移动操作。

获胜者：在消息路由和过滤方面，RabbitMQ 提供了更好的支持。

在测定发送到一个队列的消息时间方面，RabbitMQ 提供了多种能力：

①消息存活时间（TTL）

发送到 RabbitMQ 的每条消息都可以关联一个 TTL 属性。发布者可以直接设置 TTL 或者根据队列的策略来设置。

系统可以根据设置的 TTL 来限制消息的有效期。如果消费者在预期时间内没有处理该消息，那么这条消息会自动的从队列上被移除（并且会被移到死信交换器上，同时在这之后的消息都会这样处理）。

TTL 对于那些有时效性的命令特别有用，因为一段时间内没有处理的话，这些命令就没有什么意义了。

②延迟/预定的消息

RabbitMQ 可以通过插件的方式来支持延迟或者预定的消息。当这个插件在消息交换器上启用的时候，生产者可以发送消息到 RabbitMQ 上，然后这个生产者可以延迟 RabbitMQ 路由这个消息到消费者队列的时间。

这个功能允许开发者调度将来（future）的命令，也就是在那之前不应该被处理的命令。

例如，当生产者遇到限流规则时，我们可能会把这些特定的命令延迟到之后的一个时间执行。

Kafka 没有提供这些功能。它在消息到达的时候就把它们写入分区中，这样消费者就可以立即获取到消息去处理。

Kafka 也没用为消息提供 TTL 的机制，不过我们可以在应用层实现。

不过，我们必须要记住的一点是 Kafka 分区是一种追加模式的事务日志。所以，它是不能处理消息时间（或者分区中的位置）。

获胜者：毫无疑问，RabbitMQ 是获胜者，因为这种实现天然的就限制 Kafka。

当消费者成功消费消息之后，RabbitMQ 就会把对应的消息从存储中删除。这种行为没法修改。它几乎是所有消息代理设计的必备部分。

相反，Kafka 会给每个主题配置超时时间，只要没有达到超时时间的消息都会保留下来。

在消息留存方面，Kafka 仅仅把它当做消息日志来看待，并不关心消费者的消费状态。

消费者可以不限次数的消费每条消息，并且他们可以操作分区偏移来“及时”往返的处理这些消息。

Kafka 会周期的检查分区中消息的留存时间，一旦消息超过设定保留的时长，就会被删除。

Kafka 的性能不依赖于存储大小。所以，理论上，它存储消息几乎不会影响性能（只要你的节点有足够多的空间保存这些分区）。

获胜者：Kafka 设计之初就是保存消息的，但是 RabbitMQ 并不是。所以这块没有可比性，Kafka 是获胜者。

当处理消息，队列和事件时，开发者常常认为消息处理总是成功的。毕竟，生产者把每条消息放入队列或者主题后，即使消费者处理消息失败了，它仅仅需要做的就是重新尝试，直到成功为止。

尽管表面上看这种方法是没错的，但是我们应该对这种处理方式多思考一下。首先我们应该承认，在某些场景下，消息处理会失败。

所以，即使在解决方案部分需要人为干预的情况下，我们也要妥善地处理这些情况。

消息处理存在两种可能的故障：

• 瞬时故障：故障产生是由于临时问题导致，比如网络连接，CPU 负载，或者服务崩溃。我们可以通过一遍又一遍的尝试来减轻这种故障。

• 持久故障：故障产生是由于永久的问题导致的，并且这种问题不能通过额外的重试来解决。比如常见的原因有软件 Bug 或者无效的消息格式（例如，损坏（poison）的消息）

所以，一个消费者可以同步地去重试处理一条消息，不管花费多长时间都不会影响整个系统的运行。

根据 RabbitMQ 结构的设计，当负载增加的时候，一个队列上的消费者组可以有效的从仅仅一个消费者扩展到多个消费者，并且不需要对系统做任何的改变。

尽管这样，但是正如我们上面提到过，Kafka SDK 已经帮我们做了这个额外的工作。

• 高级灵活的路由规则

• 消息时序控制（控制消息过期或者消息延迟）

• 高级的容错处理能力，在消费者更有可能处理消息不成功的情景中（瞬时或者持久）

• 更简单的消费者实现

• 严格的消息顺序

• 延长消息留存时间，包括过去消息重放的可能

• 传统解决方案无法满足的高伸缩能力

• 当前开发者对这两个消息平台的了解

• 托管云解决方案的可用性（如果适用）

• 每种解决方案的运营成本

• 适用于我们目标栈的 SDK 的可用性

• https://engineering.nanit.com/rabbitmq-retries-the-full-story-ca4cc6c5b493

• https://content.pivotal.io/blog/rabbitmq-hits-one-million-messages-per-second-on-google-compute-engine