消息队列kafka的面试问题汇总

1.为什么要使用消息队列MQ？

kafka的作用：解耦，异步，削峰（解决高峰期瘫痪）

2.架构中引入MQ之后可能存在的问题？

系统的可用性降低了，因为一旦MQ遇到故障，整个系统就歇菜了

系统的复杂性变高，因为多加了一个环节

一致性问题

3.消息队列的比较

activeMQ:吞吐量万级，但社区维护慢

RabbitMQ:吞吐量万级，社区好性能可以，有后台管理界面，但是erlang语言开发，源码不好解读（中小型公司推荐）

RocketMQ:10万级吞吐量，阿里开源，分布式扩展方便，java源码（大型公司推荐）

kafka：单机10万级吞吐量，大数据实时计算，日志采集，功能简单，易于扩展（大数据领域）

4.消息队列怎么保证高可用？

（非分布式）RabbitMQ：镜像集群模式，每个节点上都有一个完整的queue的数据

kafka：leader和follower

5.为什么在消息队列里面消费到了重复的数据？

kafka：消费者在消费完数据，正要向zk提交offset的时候，消费者进程挂了，已消费的数据offset没有被提交，下次重启就会产生重复消费。（因为消费者是定期向zk提交offset的，而不是消费一条数据提交一条）

6.MQ重复消费的时候如何保证系统的幂等性？

结合具体业务分析，基于数据库的唯一键来保证数据不会重复插入；

若数据写入Redis中，保存为set格式，天然幂等；

亦或给每条数据加一条全局唯一id，每次消费之前去Redis判断一下是否消费过了即可。

7.怎么保证消息可靠性传输（如何处理消息丢失问题）？

消费端保证数据：kafka的消费者关闭自动提交offset，改为手动提交offset

kafka保证数据不丢：leader还没同步到follower时宕机了

设置4个参数：
1.给topic设置replication.factor参数，必须大于1，要求partition至少2个副本
2.在kafka服务端设置min.insync.replicas参数，必须大于1，要求leader至少感知有一个follower跟自己保持通信
3.生产者端设置acks=all：要求每条数据必须是写入所有replication副本后才认为写入成功
4.生产者端设置retries=MAX（一个很大的值），一旦写入失败就无限重试，卡在这里

8.如何保证消息的顺序性？

kafka可保证写入一个partition中的数据一定是有顺序的，一个消费者消费一个partition，一定是有顺序的。

一个消费者开启多线程处理就可能出现顺序问题，利用内存队列queue分发+多线程，即可保证顺序也可保证高吞吐量

9.消息队列满了怎么处理，有几百万条消息持续积压几个小时怎么解决？

系统故障，消费者挂了，积压了几百万的数据，现在系统恢复了，只能操作临时紧急扩容来消积数据：
先修复consumer消费速度，然后新建一个topic，partition为原来的10倍，将积压的数据通过临时分发的consumer程序，轮询的写入新建的topic中，就有10倍数量的消息队列，接着临时征用10倍的机器来部署consumer，每一批消费一个消息队列的数据，这样相当于以正常10倍的速度消费积压的数据。

10.如果让你写一个消息队列，你怎么设计架构？

首先要支持可伸缩性（扩容）：设计一个分布式的系统，参照kafka，broker->topic->partition

其次要考虑mq的数据要落磁盘：保证数据不会丢失，磁盘顺序写入磁盘

其次要考虑mq的可用性：kafka的高可用保障机制，多副本->leader&follower->broker挂了重新选举leader对外服务

最后还有考虑mq的数据0丢失：参考问题7答案