『软件』讲真，应该选择RabbitMQ还是Kafka？ |Apache|Azure|技术|

作为一个有丰富经验的微服务系统架构师，经常有人问我，应该选择 RabbitMQ 还是 Kafka?

本文插图
【『软件』讲真，应该选择RabbitMQ还是Kafka？】
图片来自 Pexels
基于某些原因，许多开发者会把这两种技术当做等价的来看待。的确，在一些案例场景下选择 RabbitMQ 还是 Kafka 没什么差别，但是这两种技术在底层实现方面是有许多差异的。
不同的场景需要不同的解决方案，选错一个方案能够严重的影响你对软件的设计，开发和维护的能力。
这篇文章会先介绍一下基本的异步消息模式，然后再介绍一下 RabbitMQ 和 Kafka 以及他们的内部结构信息。第二部分(未完成)主要介绍这两种技术的主要不同点以及他们各自的优缺点，最后我们会说明一下怎样选择这两种技术。
异步消息模式
异步消息可以作为解耦消息的生产和处理的一种解决方案。提到消息系统，我们通常会想到两种主要的消息模式——消息队列和发布/订阅模式。
消息队列
利用消息队列可以解耦生产者和消费者。多个生产者可以向同一个消息队列发送消息。
但是，一个消息在被一个消息者处理的时候，这个消息在队列上会被锁住或者被移除并且其他消费者无法处理该消息。也就是说一个具体的消息只能由一个消费者消费。

本文插图
消息队列
需要额外注意的是，如果消费者处理一个消息失败了，消息系统一般会把这个消息放回队列，这样其他消费者可以继续处理。
消息队列除了提供解耦功能之外，它还能够对生产者和消费者进行独立的伸缩(scale) ，以及提供对错误处理的容错能力。
发布/订阅
发布/订阅(pub/sub)模式中，单个消息可以被多个订阅者并发的获取和处理。

本文插图
发布/订阅
例如，一个系统中产生的事件可以通过这种模式让发布者通知所有订阅者。在许多队列系统中常常用主题(topics)这个术语指代发布/订阅模式。
在 RabbitMQ 中，主题就是发布/订阅模式的一种具体实现(更准确点说是交换器(exchange)的一种) ，但是在这篇文章中，我会把主题和发布/订阅当做等价来看待。
一般来说，订阅有两种类型：

临时(ephemeral)订阅，这种订阅只有在消费者启动并且运行的时候才存在。一旦消费者退出，相应的订阅以及尚未处理的消息就会丢失。
持久(durable)订阅，这种订阅会一直存在，除非主动去删除。消费者退出后，消息系统会继续维护该订阅，并且后续消息可以被继续处理。

RabbitMQ
RabbitMQ 作为消息中间件的一种实现，常常被当作一种服务总线来使用。 RabbitMQ 原生就支持上面提到的两种消息模式。
其他一些流行的消息中间件的实现有 ActiveMQ ， ZeroMQ ， Azure Service Bus 以及 Amazon Simple Queue Service(SQS) 。
这些消息中间件的实现有许多共通的地方；这边文章中提到的许多概念大部分都适用于这些中间件。
队列
RabbitMQ 支持典型的开箱即用的消息队列。开发者可以定义一个命名队列，然后发布者可以向这个命名队列中发送消息。最后消费者可以通过这个命名队列获取待处理的消息。
消息交换器
RabbitMQ 使用消息交换器来实现发布/订阅模式。发布者可以把消息发布到消息交换器上而不用知道这些消息都有哪些订阅者。
每一个订阅了交换器的消费者都会创建一个队列;然后消息交换器会把生产的消息放入队列以供消费者消费。消息交换器也可以基于各种路由规则为一些订阅者过滤消息。