RabbitMQ和Kafka面试

RabbitMQ：

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

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

 

Kafka:

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下面的一个分区内只能给一个消费者消费，对于一个分区来说，kafka是不支持并发，但是可以通过扩大分区实现并发

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

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

 

消息队列好处：

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使用消息偏移量）