消息队列八股文

目录

1.kafka和rocketMq的区别

2.1如何保证消息不丢失

2.2如何保证消息的一致性/幂等性/重复消费

3.kafka的容灾机制/MQ的高可用

---

消息队列常考的问题是：

        1.不同之间的区别

        2.高可用/容灾机制

        3.顺序性

        4.一致性/幂等性/重复消费问题

1.kafka和rocketMq的区别

之前常用的是rabbitMQ，开源，语言是erlang。目前常用的是rocketMQ，是阿里出品的，Kafka是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区 活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。

1.RocketMQ常用于一般业务，支持重试，消息查询，消息回溯，定时功能。

2.Kafka一般用于实时计算和日志采集，适用于大数据领域，和Flink等框架结合做实时流处理。

2.1如何保证消息不丢失

Rocketmq如何保证消息不丢失，如何保证消息不被重复消费_码上得天下的博客-CSDN博客_rocketmq如何保证消息不丢失

2.2如何保证消息的一致性/幂等性/重复消费

场景：

        1.kafka对每条消息都有一个offset，用来宕机恢复的时候知道从哪条消息开始重新发，假如生产者发送了一条消息，但是offset还没有来得及更新就宕机了。这样重启后，此消息就会重发。

        2.消息消费过慢，自动重发了。

解决核心：主要靠业务场景，由开发人员解决

        1.如果是写redis，更新数据，天然幂等，不用管。

        2.写数据库，写之前先根据某些字段查一查有没有该数据，如果有就不处理。滴滴是这么干的的

        3.某些业务场景，比如消费库存变更消息，可以在拿到消息后，反查一下数据库。美团是这么干的

        4.每条消息生成一个特定的id，把这个id存到redis、mysql里面，设置一定的过期时间。处理时先查一下有没有存过这个ID。但是面试官认为把所有的id存到redis里面不现实。

3.kafka的容灾机制/MQ的高可用

        Kafka 一个最基本的架构认识：由多个 broker 组成，每个 broker 是一个节点；你创建一个 topic，这个 topic 可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个 partition 就放一部分数据。 这就是天然的分布式消息队列，就是说一个 topic 的数据，是分散放在多个机器上的，每个机器就放一部分数据。

        Kafka 0.8 以后，提供了 HA (高可用)机制，就是 replica（复制品） 副本机制。每个 partition 的数据都会同步到其它机器上，形成自己的多个 replica 副本。所有 replica 会选举一个 leader 出来，那么生产和消费都跟这个 leader 打交道，然后其他 replica 就是 follower。写的时候，leader 会负责把数据同步到所有 follower 上去，读的时候就直接读 leader 上的数据即可。

        如果某个 broker 宕机了，没事儿，那个 broker上面的 partition 在其他机器上都有副本的。如果这个宕机的 broker 上面有某个 partition 的 leader，那 么此时会从 follower 中重新选举一个新的 leader 出来，大家继续读写那个新的 leader 即可。

        写数据的时候，生产者就写 leader，然后 leader 将数据落地写本地磁盘，接着其他 follower 自 己主动从 leader 来 pull 数据。一旦所有 follower 同步好数据了，就会发送 ack 给 leader， leader 收到所有 follower 的 ack 之后，就会返回写成功的消息给生产者。（当然，这只是其中 一种模式，还可以适当调整这个行为）