RabbitMQ和Kafka面试

RabbitMQ：

采用AMQP高级消息队列协议的一种消息队列技术,最大的特点就是消费并不需要确保提供方存在,实现了服务之间的高度解耦

当master queue 所在节点宕机后，其正在被消费的消息的相关信息全部丢失，即服务端不知道消费者对那一瞬间消费的消息是否进行了ACK，所以在mirror queue被提升为master queue时，会把宕机前正在进行消费的的消息全部重新发送一遍，即客户端重连后，消息可能被重复消费，这个时候就必须依靠应用层逻辑来判断来避免重复消费。

在持久化方面，RabbitMQ的master queue每次收到新消息后，都会立刻写入磁盘，并把消息同步给mirror queue。假设在master queue 收到消息后，消息未同步到mirror queue 之前master queue 宕机，则此时mirror queue中就没有刚刚master queue收到的那条消息，当这个mirror queue被提升为master queue时，消费者连接到新的master queue上进行消费时就丢了一条消息。所以，RabbitMQ也会丢消息，只不过这个丢消息的概率非常低。

Rabbitmq 不承诺消息的顺序性，因此可以并发多线程处理。在队列中不必排队。如果对处理的顺序没有要求，就可以用Rabbitmq较容易的实现并发。

Rabbitmq具有阅后即焚的特性，具有消息确认机制

如何确保消息正确地发送至RabbitMQ？ 如何确保消息接收方消费了消息？

发送方确认模式：
将信道设置成confirm模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID。
一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。
如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。
发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。

接收方确认机制：
接收方消息确认机制：消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。
这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性；

rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不一样，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操作；

rabbitMQ的负载均衡需要单独的loadbalancer进行支持。

 

Kafka:

 Kafka是一种高吞吐量的分布式发布订阅消息系统

 

1.Topic：特指Kafka处理的消息源（feeds of messages）的不同分类。

2.Partition：Topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset

3.Message：消息，是通信的基本单位，每个producer可以向一个topic（主题）发布一些消息。

4.Producers:  数据生产者.Producer将消息发布到指定的Topic中,同时Producer也能决定将此消息归属于哪个partition;比如基于"round-robin"方式或者通过其他的一些算法等.

5.Consumers: 数据消费者.每个consumer属于一个consumer group;反过来说,每个group中可以有多个consumer.发送到Topic的消息,只会被订阅此Topic的 每个group中的一个consumer消费.我们可以认为一个group是一个"订阅"者,一个Topic中的每个partions,只会被一个"订阅者"中的一个consumer消费,不过一个consumer可以消费多个partitions中的消息.

6. Broker：缓存代理，Kafka集群中的一台或多台服务器统称为broker。

 

优势：

快速:单一的Kafka代理可以处理成千上万的客户端，每秒处理数兆字节的读写操作。

可伸缩:在一组机器上对数据进行分区和简化，以支持更大的数据

持久:消息是持久性的，并在集群中进行复制，以防止数据丢失。

解释Kafka的Zookeeper是什么?我们可以在没有Zookeeper的情况下使用Kafka吗?

Zookeeper是一个开放源码的、高性能的协调服务，它用于Kafka的分布式应用。

不，不可能越过Zookeeper，直接联系Kafka broker。一旦Zookeeper停止工作，它就不能服务客户端请求。

Kafka同样有主从同步，所以也必定存在与RabbitMQ同样丢消息的问题。但是Kafka的每个客户端保存了读取消息的偏移信息，故当一个主分片宕机后，Kafka客户端可以从副分片相应位移后继续消费，不会有重复消费的情况。

持久化方面，Kafka默认把消息直接写文件，但是由于操作系统的cache原因，消息可能不会立马写到磁盘上，这个时候就需要刷新文件到磁盘。由于刷新文件到磁盘是一个比较耗时的操作，故Kafka提供了两种不同的刷新配置：

#每接收多少条消息刷一下磁盘
log.flush.interval.messages=10000
#每隔多少ms刷一下磁盘
log.flush.interval.ms=1000

我们完全可以把log.flush.interval.messages设置为1，这样Kafka就能在持久化方面达到和RabbitMQ同样的安全级别。

Kafka是严格保证了消息队列的顺序，就是一个topic下面的一个分区partition内只能给一个消费者消费，对于一个分区来说，kafka是不支持并发，但是可以通过扩大分区实现并发

Kafka的性能和数据大小无关，可以设置数据保留时间, 不具有消息确认机制；消费者的增加和减少，对集群或者其他消费者没有多大的影响

在集群负载均衡方面，kafka采用zookeeper对集群中的broker、consumer进行管理，可以注册topic到zookeeper上；通过zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；并且producer可以基于语义指定分片，消息发送到broker的某分片上。

 Kafka具有较高的吞吐量，表现在顺序读写、零拷贝、分片、批量发送、数据压缩

消息队列好处：

1.解耦

使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。

 

2.异步

A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms

 

如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中， BCD 三个系统从MQ读取数据，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了，爽！网站做得真好，真快！

消息队列缺点：

1.需要考虑可用性（RabbitMQ用mirror queue同步master queue 预防宕机问题；Kafka副分片备份主分片）

2.需要考虑重复消费问题（RabbitMQ依靠应用层逻辑，即java代码来判断来避免重复消费；Kafka使用消息偏移量）

 

转载于:https://www.cnblogs.com/jing-ma/p/10496697.html