面试--RabbitMQ、Kafka、ActiveMQ

1 信息传递模式

RabbitMQ和ActiveMQ都支持JMS API，这意味着它们遵循传统的消息模型，其中消息发送到队列或主题，并由一个或多个消费者消耗。
另一方面，Kafka使用发布/订阅消息模型，其中消息发布到主题并由一个或多个订阅者消耗。
RabbitMQ和ActiveMQ使用的传统消息模型非常适合需要严格排序和可靠交付消息的应用程序。
另一方面，Kafka使用的发布/订阅消息模型更适合流数据场景，其中需要实时处理数据。

2 可扩展性

可扩展性是消息系统的重要要求，特别是在处理大量数据时。RabbitMQ和ActiveMQ都被设计为可扩展的，但它们在实现可扩展性方面采用了不同的方法。
RabbitMQ使用集群方法来实现可扩展性，其中多个RabbitMQ代理连接在一起形成一个集群。消息分布在整个集群中，消费者可以连接到集群中的任何代理以消费消息。RabbitMQ还支持联邦，允许将多个RabbitMQ集群连接在一起。
ActiveMQ使用代理网络方法来实现可扩展性，其中多个ActiveMQ代理连接在一起形成一个网络。消息分布在整个网络中，消费者可以连接到网络中的任何代理以消费消息。ActiveMQ还支持主/从复制，为消息代理提供高可用性。
另一方面，Kafka被设计为开箱即用的高度可扩展。Kafka使用分区方法来实现可扩展性，其中消息被分区到多个Kafka代理上。每个分区都在多个代理上进行了复制以实现容错性。这种方法允许Kafka处理大量数据同时保持低延迟和高吞吐量。

3 性能

性能是选择消息系统时要考虑的另一个关键因素。RabbitMQ、Kafka和ActiveMQ都具有不同的性能特征。
RabbitMQ被设计为可靠的消息系统，这意味着它优先考虑消息传递而不是性能。RabbitMQ可以处理中等消息速率，适用于需要严格排序和可靠传递消息的应用程序。
另一方面，Kafka被设计为高性能系统，可以处理大量数据并具有低延迟。Kafka通过使用分布式架构和优化顺序I/O来实现这种性能。
ActiveMQ也被设计为高性能系统，可以处理高消息速率。ActiveMQ通过使用异步架构和优化消息批处理来实现这种性能。

4 数据持久性

数据持久性是消息传递系统的重要特征，它使消息即使在消息系统崩溃时也能够被存储和检索。RabbitMQ、Kafka和ActiveMQ都有不同的数据持久性方法。
RabbitMQ 默认将消息存储在磁盘上，这使消息即使在代理宕机时也能被持久化。RabbitMQ 还支持不同的存储后端，包括内存存储，这提供了更好的性能，但会降低数据可靠性。
Kafka默认将消息存储在磁盘上，并使用基于日志的架构来实现高耐久性和可靠性。Kafka保留消息的时间是可配置的，这使得消息可以在必要时进行重播。
ActiveMQ也默认将消息存储在磁盘上，并支持不同的存储后端，包括JDBC和基于文件的存储。ActiveMQ可以将消息存储在数据库中，这提供了更好的数据可靠性，但会牺牲性能。

5 与其他系统的集成

在选择消息系统时，与其他系统的集成是一个重要的考虑因素。RabbitMQ、Kafka和ActiveMQ都具有不同的集成能力。
RabbitMQ 与不同的编程语言集成良好，包括 Java、Python、Ruby 和 .NET。RabbitMQ还有插件，允许它与不同的系统集成，包括数据库、Web服务器和消息代理。
Kafka与不同的数据处理系统集成良好，包括Apache Spark、Apache Storm和Apache Flink。Kafka也有一个连接器框架，允许它与不同的数据库和数据源集成。
ActiveMQ与不同的JMS客户端集成良好，包括Java、.NET和C++。ActiveMQ还有一些插件，允许它与不同的系统集成，包括Apache Camel和Apache CXF。

RabbitMQ如何保证消息顺序消费

①一个 queue 对应一个 consumer，然后这个 consumer 内部用内存队列做排队，然后分发给底层不同的 worker 来处理。这种做法就是在consumer那里再做一层逻辑处理，按照新增-查询-删除的一组消息为一个单位。
②通过一个顺序id来分组实现 。大概的思路就是，消息体里边带上这个消息的顺序，然后消费者在消费的时候按照消息体里的顺序id去消费。

RabbitMQ生产者事务与确认机制

当消息的生产者将消息发送出去之后，消息到底有没有正确地到达服务器呢?如果不进行特殊配置，默认情况下发送消息的操作是不会返回任何信息给生产者的，也就是默认情况下生产者是不知道消息有没有正确地到达服务器。

RabbitMQ针对这个问题，提供了两种解决方式：
1.通过事务机制实现。这是AMQP协议层面提供的解决方案
2.通过发送方确认（publisher confirm）机制实现

1.事务机制

RabbitMQ客户端中与事务机制相关的方法有三个: channel. txSelect、channel. txCommit和channel. txRollback。
channel.txSelect用于将当前的信道设置成事务模式
channel.txCommit用于提交事务
channel.txRollback用于事务回滚。

在通过channel. txSelect方法开启事务之后，我们便可以发布消息给RabbitMQ了，如果事务提交成功，则消息一定到达了RabbitMQ中，如果在事务提交执行之前由RabbitMQ异常崩溃或者其他原因抛出异常，这个时候我们便可以将其捕获，进而通过执行channel. txRollback方法来实现事务回滚。注意这里的RabbitMQ中的事务机制与大多数数据库中的事务概念并不相同，需要注意区分。

可以发现开启事务机制与不开启相比多了四个步骤：
客户端发送Tx.Select，将信道置为事务模式;
Broker 回复Tx.Select-Ok，确认已将信道置为事务模式;
在发送完消息之后，客户端发送Tx.Commit提交事务;
Broker 回复Tx.Commit-Ok，确认事务提交。

事务确实能够解决消息发送方和RabbitMQ 之间消息确认的问题，只有消息成功被RabbitMQ接收，事务才能提交成功，否则便可在捕获异常之后进行事务回滚，与此同时可以进行消息重发。
但是使用事务机制会“吸干”RabbitMQ的性能，事务机制在一条消息发送之后会使发送端阻塞，以等待RabbitMQ 的回应，之后才能继续发送下一条消息。
那么有没有更好的方法既能保证消息发送方确认消息已经正确送达，又能基本上不带来性能上的损失呢?从AMQP协议层面来看并没有更好的办法，但是RabbitMQ提供了一个改进方案，即发送方确认机制,详情请看下一节的介绍。

2.发送方确认机制

生产者将信道设置成confirm(确认)模式，一旦信道进入confirm模式，所有在该信道上面发布的消息都会被指派一个唯一的ID(从1开始),一旦消息被投递到所有匹配的队列之后，RabbitMQ就会发送一个确认(Basic.Ack) 给生产者(包含消息的唯一ID),这就使得生产者知晓消息已经正确到达了目的地了。如果消息和队列是可持久化的，那么确认消息会在消息写入磁盘之后发出。

RabbitMQ回传给生产者的确认消息中的deliveryTag 包含了确认消息的序号，此外RabbitMQ也可以设置channel .basicAck方法中的multiple参数，表示到这个序号之前的所有消息都已经得到了处理，可以参考下图。注意辨别这里的确认和消费时候的确认之间的异同。

相比之下，发送方确认机制最大的好处在于它是异步的，一旦发布一条消息，生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用程序便可以通过回调方法来处理该确认消息，如果RabbitMQ因为自身内部错误导致消息丢失，就会发送一条nack (Basic.Nack) 命令，生产者应用程序同样可以在回调方法中处理该nack命令。

生产者通过调用channel. confirmSelect方法( 即Confirm.Select命令)将信道设置为confirm模式，之后RabbitMQ会返回Confirm.Select-Ok命令表示同意生产者将当前信道设置为confirm模式。所有被发送的后续消息都被ack或者nack一次，不会出现一条消息既被ack又被nack的情况，并且RabbitMQ也并没有对消息被confirm的快慢做任何保证。
如果信道没有开启publisher confirm模式，则调用任何wai tForConfirms方法都会报出java.lang.IllegalStateException。

(1) boolean waitForConfirms() throws InterruptedException;

(2) boolean waitForConfirms(long timeout) throws InterruptedException, TimeoutException;

(3) void waitForConfirmsOrDie() throws IOException, InterruptedException;

(4) void waitForConfirmsOrDie(long timeout) throws IOException, InterruptedException, TimeoutException;

对于没有参数的waitForConfirms方法来说，其返回的条件是客户端收到了相应的Basic. Ack/ . Nack或者被中断。

参数timeout表示超时时间，一旦等待RabbitMQ 回应超时就会抛出java.util. concurrent .TimeoutException的异常。

两个waitForConfirmsOrDie方法在接收到RabbitMQ返回的Basic.Nack之后会抛出java. io. IOException。业务代码可以根据自身的特性灵活地运用这四种方法来保障消息的可靠发送。

注意：
(1)事务机制和publisher confirm机制两者是互斥的，不能共存。如果企图将已开启事务模式的信道再设置为publisher confirm 模式，RabbitMQ 会报错: {amqp_ error, precondition_failed，"cannot switch from tx to confirm mode", 'confirm.select'}; 或者如果企图将已开启publisher confirm 模式的信道再设置为事务模式，RabbitMQ 也会报错:{amqp_ error, precondition_ failed, "cannot switch from confirm to txmode",' tx.select ' } 。
(2)事务机制和publisherconfirm机制确保的是消息能够正确地发送至RabbitMQ，这里的“发送至RabbitMQ”的含义是指消息被正确地发往至RabbitMQ的交换器，如果此交换器没有匹配的队列，那么消息也会丢失。所以在使用这两种机制的时候要确保所涉及的交换器能够有匹配的队列。更进一步地讲，发送方要配合mandatory参数或者备份交换器一起使用来提高消息传输的可靠性。

publisher confirm的优势在于并不一定需要同步确认。这里我们改进了一下使用方式，总结有如下两种:
批量confirm方法:每发送一批消息后，调用channel . waitForConfirms方法，等待服务器的确认返回。
异步confirm方法:提供一个回调方法，服务端确认了一条或者多条消息后客户端会回调这个方法进行处理。

在批量confirm方法中，客户端程序需要定期或者定量(达到多少条)，亦或者两者结合起来调用channel. waitForConfirms来等待RabbitMQ的确认返回。相比于前面示例中的普通confirm方法，批量极大地提升了confirm 的效率，但是问题在于出现返回Basic.Nack或者超时情况时，客户端需要将这一批次的消息全部重发，这会带来明显的重复消息数量，并且当消息经常丢失时，批量confirm的性能应该是不升反降的。

异步 confirm 方法的编程实现最为复杂。在客户端Channel接口中提供的addConfirmListener 方法可以添加ConfirmListener这个回调接口，这个ConfirmListener接口包含两个方法: handleAck 和handleNack， 分别用来处理RabbitMQ回传的Basic.Ack 和Basic.Nack。 在这两个方法中都包含有一个参数deliveryTag (在publisher confirm 模式下用来标记消息的唯一有序序号)。 我们需要为每一个信道维护一个“unconfirm”的消息序号集合，每发送一条消息， 集合中的元素加1。

每当调用ConfirmListener 中的handleAck方法时，“unconfirm”集合中删掉相应的一条(multiple设置为false)或者多条(multiple 设置为true)记录。从程序运行效率.上来看，这个“unconfirm”集合最好采用有序集合SortedSet的存储结构。事实上，Java 客户端SDK中的waitForConfirms方法也是通过SortedSet维护消息序号的。下列代码为我们演示了异步confirm的编码实现，其中的confirmSet就是一个SortedSet类型的集合。

批量confirm和异步confirm这两种方式所呈现的性能要比其余两种好得多。事务机制和普通confirm 的方式吐吞量很低，但是编程方式简单，不需要在客户端维护状态(这里指的是维护deliveryTag及缓存未确认的消息)。批量confirm方式的问题在于遇到RabbitMQ服务端返回Basic. Nack需要重发批量消息而导致的性能降低。异步confirm方式编程模型最为复杂，而且和批量confirm 方式一样需要在客户端维护状态。在实际生产环境中采用何种方式，这里就仁者见仁智者见智了，不过强烈建议使用异步confirm的方式。