[51CTO传媒TB]注意了！Kafka与RabbitMQ千万不要乱用… 作为一个有丰富经验的微服务系统架构师

【[51CTO传媒TB]注意了！Kafka与RabbitMQ千万不要乱用…】作为一个有丰富经验的微服务系统架构师，经常有人问我，应该选择RabbitMQ还是Kafka?

文章图片
图片来自Pexels
基于某些原因，许多开发者会把这两种技术当做等价的来看待。的确，在一些案例场景下选择RabbitMQ还是Kafka没什么差别，但是这两种技术在底层实现方面是有许多差异的。
不同的场景需要不同的解决方案，选错一个方案能够严重的影响你对软件的设计，开发和维护的能力。
第一篇文章介绍了RabbitMQ和ApacheKafka内部实现的相关概念。本篇文章会从两个方面探讨这两种技术之间的差异，一个是这两种技术之间的显著差异，另一个是对于软件架构师和开发者需要注意的差异。
我们先来说说架构模式，也就是我们尝试着利用这两种技术来实现的架构模式，并且评估什么时候该使用哪一个。
注意1：如果你对RabbitMQ和Kafka的内部结构还不熟悉，我强烈推荐你阅读我之前的第一篇文章《讲真，应该选择RabbitMQ还是Kafka?》。
如果你不确定，那么可以简要的看一下里面的标题和图表，至少对这些差异有个大概的了解。
注意2：上一篇文章发表之后，有些读者问我对于ApachePulsar的看法。 Pulsar是另一种类型的消息系统，它旨在提供RabbitMQ和Kafka都有的一些优点。
作为一个现代的消息系统，它看上去很有前途;但是像其他平台系统一样，都有各自的优缺点。
这边文章主要是比较RabbitMQ和Kafka ，之后我会尝试针对ApachePulsar做一个比较。
RabbitMQ和Kafka的显著差异
RabbitMQ是一个消息代理，但是ApacheKafka是一个分布式流式系统。好像从语义上就可以看出差异，但是它们内部的一些特性会影响到我们是否能够很好的设计各种用例。
例如， Kafka最适用于数据的流式处理，但是RabbitMQ对流式中的消息就很难保持它们的顺序。
另一方面， RabbitMQ内置重试逻辑和死信(dead-letter)交换器，但是Kafka只是把这些实现逻辑交给用户来处理。
这部分主要强调在不同系统之间它们的主要差异。
消息顺序
对于发送到队列或者交换器上的消息， RabbitMQ不保证它们的顺序。尽管消费者按照顺序处理生产者发来的消息看上去很符合逻辑，但是这有很大误导性。
RabbitMQ文档中有关于消息顺序保证的说明：
“发布到一个通道(channel)上的消息，用一个交换器和一个队列以及一个出口通道来传递，那么最终会按照它们发送的顺序接收到。 ”
——RabbitMQ代理语义(BrokerSemantics)
换话句话说，只要我们是单个消费者，那么接收到的消息就是有序的。然而，一旦有多个消费者从同一个队列中读取消息，那么消息的处理顺序就没法保证了。
由于消费者读取消息之后可能会把消息放回(或者重传)到队列中(例如，处理失败的情况) ，这样就会导致消息的顺序无法保证。
一旦一个消息被重新放回队列，另一个消费者可以继续处理它，即使这个消费者已经处理到了放回消息之后的消息。
因此，消费者组处理消息是无序的，如下表所示：

文章图片
使用RabbitMQ丢失消息顺序的例子
当然，我们可以通过限制消费者的并发数等于1来保证RabbitMQ中的消息有序性。
更准确点说，限制单个消费者中的线程数为1 ，因为任何的并行消息处理都会导致无序问题。
不过，随着系统规模增长，单线程消费者模式会严重影响消息处理能力。所以，我们不要轻易的选择这种方案。