讲真，应该选择RabbitMQ还是Kafka？
作为一个有丰富经验的微服务系统架构师，经常有人问我，应该选择 RabbitMQ 还是 Kafka？。
图片来自 Pexels
基于某些原因， 许多开发者会把这两种技术当做等价的来看待。的确，在一些案例场景下选择 RabbitMQ 还是 Kafka 没什么差别，但是这两种技术在底层实现方面是有许多差异的。
不同的场景需要不同的解决方案，选错一个方案能够严重的影响你对软件的设计，开发和维护的能力。
这篇文章会先介绍一下基本的异步消息模式，然后再介绍一下 RabbitMQ 和 Kafka 以及他们的内部结构信息。第二部分（未完成）主要介绍这两种技术的主要不同点以及他们各自的优缺点，最后我们会说明一下怎样选择这两种技术。
异步消息模式
异步消息可以作为解耦消息的生产和处理的一种解决方案。提到消息系统，我们通常会想到两种主要的消息模式——消息队列和发布/订阅模式。
消息队列
利用消息队列可以解耦生产者和消费者。多个生产者可以向同一个消息队列发送消息。
但是，一个消息在被一个消息者处理的时候，这个消息在队列上会被锁住或者被移除并且其他消费者无法处理该消息。也就是说一个具体的消息只能由一个消费者消费。
消息队列
需要额外注意的是，如果消费者处理一个消息失败了，消息系统一般会把这个消息放回队列，这样其他消费者可以继续处理。
消息队列除了提供解耦功能之外，它还能够对生产者和消费者进行独立的伸缩（scale），以及提供对错误处理的容错能力。
发布/订阅
发布/订阅
例如，一个系统中产生的事件可以通过这种模式让发布者通知所有订阅者。在许多队列系统中常常用主题（topics）这个术语指代发布/订阅模式。
在 RabbitMQ 中，主题就是发布/订阅模式的一种具体实现（更准确点说是交换器（exchange）的一种），但是在这篇文章中，我会把主题和发布/订阅当做等价来看待。
一般来说，订阅有两种类型：
临时（ephemeral）订阅，这种订阅只有在消费者启动并且运行的时候才存在。一旦消费者退出，相应的订阅以及尚未处理的消息就会丢失。
持久（durable）订阅，这种订阅会一直存在，除非主动去删除。消费者退出后，消息系统会继续维护该订阅，并且后续消息可以被继续处理。
RabbitMQ
队列
消息交换器
每一个订阅了交换器的消费者都会创建一个队列；然后消息交换器会把生产的消息放入队列以供消费者消费。消息交换器也可以基于各种路由规则为一些订阅者过滤消息。
按照这种方式，我们实现了发布/订阅模式，同时也能够很好的伸缩（scale-up）订阅者去处理收到的消息。
Apache Kafka
主题
确保来自相同逻辑流上的消息映射到相同分区上，这就保证了消息能够按照顺序提供给消费者。
通过 Kafka 提供的 API 可以处理同一消费者组中多个消费者之间的分区平衡以及消费者当前分区偏移的存储。
Kafka 实现的消息模式
结束语
编辑：陶家龙
原文：https://medium.com/better-programming/rabbitmq-vs-kafka-1ef22a041793
精彩文章推荐：