kafka和mq的区别 Kafka、ActiveMQ、RabbitMQ、RocketMQ 区别以及高可用原理

为什么使用消息队列

其实就是问你消息队列中使用了什么场景，然后你的项目中具体是什么场景，你在这个场景中使用的消息队列是什么？

面试官问你这个问题的时候，预期的答案之一是，你的公司有什么商业场景，这个商业场景有什么技术挑战？如果你不使用MQ，可能会很麻烦，但是现在你用了MQ之后给你带来了很多好处。

先说消息队列的常见使用场景。其实场景很多，但核心有三个:解耦、异步、削峰。

退耦

看看这一幕。一个系统向BCD三个系统发送数据，通过接口调用和发送。如果e系统也要这个数据呢？如果不再需要C系统怎么办？一个系统领导差点崩溃......

没有人使用单机模式进行生产。

正常集群模式(无高可用性)

通用集群模式意味着在多台机器上启动多个RabbitMQ实例，每台机器一个。您创建的队列只会放在一个RabbitMQ实例上，但是每个实例都会同步队列的元数据(元数据可以看作是队列的一些配置信息，通过元数据可以找到队列所在的实例)。事实上，当您使用时，如果您连接到另一个实例，该实例将从队列所在的实例中提取数据。

这个方法真的很麻烦，不太好。如果不是分布式的，只是一个普通的集群。因为这将导致您一次随机连接一个实例，然后提取数据，或者固定连接队列所在的实例来使用数据。前者有数据拉取的开销，后者导致单个实例的性能瓶颈。

此外，如果放置队列的实例发生故障，将导致其他实例无法从该实例中拉出。如果打开消息持久化，让RabbitMQ在地面存储消息，消息不一定会丢失。只有当此实例恢复后，您才能继续从此队列中提取数据。

所以这个事情比较尴尬，不存在高可用性这种东西。该方案主要提高吞吐量，即集群中的多个节点服务于一个队列的读写操作。

镜像集群模式(高可用性)

这种模式就是所谓的RabbitMQ的高可用性模式。与常见的集群模式不同，在镜像集群模式中，您创建的队列，无论队列中的元数据或消息如何，都会存在于多个实例中，也就是说，每个RabbitMQ节点都有一个完整的队列镜像，其中包含队列的所有数据。然后每次向队列中写入消息时，都会自动将消息同步到多个实例的队列中。

那么如何开启这个镜像集群模式呢？其实很简单。RabbitMQ有一个很好的管理控制台，就是在后台增加了一个新的策略。该策略是镜像集群模式的策略。当您指定它时，您可以要求数据同步到所有节点或指定数量的节点。当您再次创建队列时，您将通过应用此策略自动将数据同步到其他节点。

在这种情况下，优点是您的任何一台机器都停机了，这很好。其他机器(节点)也包含这个队列的完整数据，其他消费者可以去其他节点消费数据。缺点是:一是性能开销太大。消息需要同步到所有机器，导致网络带宽压力大，消耗大。第二，这样玩，如果不分布式，就没有扩展性。如果一个队列负载很重，你添加机器，新添加的机器也包含这个队列的所有数据，没有办法线性扩展你的队列。你觉得，如果这个队列的数据量大到这个机器的容量容纳不下，这个时候该怎么办？

卡夫卡的高可用性

卡夫卡最基本的架构理解:它由多个经纪人组成，每个经纪人都是一个节点；你创建一个主题，可以分为多个分区，每个分区可以存在于不同的代理上，每个分区都会放一部分数据。

这就是自然分布式消息队列，也就是说一个话题的数据分散在多台机器上，每台机器放一部分数据。

其实Rabbtmq不是分布式的消息队列，而是传统的消息队列，它只提供了一些集群和HA(High available)机制，因为不管你怎么玩，Rabbtmq的队列的数据都放在一个节点里，镜像集群下，每个节点也放这个队列的完整数据。

在卡夫卡0.8之前，没有HA机制，也就是说，如果任何一个代理宕机了，那个代理上的分区就会被浪费掉，无法读写，所以根本没有高可用性。

例如，让我们假设创建了一个主题，指定分区的数量为三个，在三台机器上。但是如果第二台机器停机，这个题目的1/3数据会丢失，所以这个不能是高可用的。

卡夫卡0.8之后，提供了HA机制，就是副本机制。每个分区的数据将与其他机器同步，以形成自己的多个副本。所有复制品将选出一个领导者，然后生产和消费将处理这个领导者，然后其他复制品将成为追随者。写的时候领导会负责同步数据给所有跟随者，读的时候直接读取领导身上的数据。只读写领导？很简单，如果可以随意读写每个跟随者，就要关心数据的一致性。系统复杂度太高，容易出错。卡夫卡会将一个分区的所有副本均匀分布在不同的机器上，从而提高容错性。