消息队列面试问题

Kafka与其他三个消息系统关键区别是

• kafka是持久化日志，这些日志可以被重复读取和无限期保留
• kafka是分布式系统，它以集群方式运行，可以灵活伸缩
• kafka支持实时的流式处理

Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别

    ActiveMQ没经过大规模吞吐量验证，社区也不活跃。RabbitMQ是开源的，有稳定的支持，社区活跃度高，RocketMQ阿里出品，有可能会突然黄掉。所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。

 

为什么要使用消息队列

    如果能结合自己做过的项目说明，那是最好的。

• 解耦。
• 削峰
• 异步

 

消息队列缺点

• 系统可用性减低。本来只需要维护业务系统，现在还需要维护消息系统
• 复杂度上升。通上
• 一致性问题。可能会出现各个业务系统数据不一致的情况。

 

消息重复原因

• 生产者发送数据后，消息系统写入消息后，由于宕机或者返回超时等问题，导致生产者重试发送。
• 消费者获取到消息后，由于消费者宕机或者网络延迟，导致消息系统没有收到消息响应，重复发送。

 

如何解决消息重复。即接口的幂等性

参考https://blog.csdn.net/zgsxhdzxl/article/details/104414475 分布式系统的接口幂等性设计

 

消息的可靠性传输

1. activeMQ

• 生产者

    应该采用持久化方式或者事务方式

•  消费者

    activemq有四种确认机制

1. 1. AUTO_ACKNOWLEDGE = 1    自动确认
   2. CLIENT_ACKNOWLEDGE = 2    客户端手动确认   
   3. DUPS_OK_ACKNOWLEDGE = 3    自动批量确认
   4. SESSION_TRANSACTED = 0    事务提交并确认

AUTO_ACKNOWLEDGE  

自动确认

    “同步”(receive)方法返回message给消息时会立即确认。

     在"异步"(messageListener)方式中,将会首先调用listener.onMessage(message)，如果onMessage方法正常结束,消息将会正常确认。如果onMessage方法异常，将导致消费者要求ActiveMQ重发消息。

CLIENT_ACKNOWLEDGE :

客户端手动确认，这就意味着AcitveMQ将不会“自作主张”的为你ACK任何消息，开发者需要自己择机确认。

我们可以在当前消息处理成功之后，立即调用message.acknowledge()方法来"逐个"确认消息，这样可以尽可能的减少因网络故障而导致消息重发的个数；当然也可以处理多条消息之后，间歇性的调用acknowledge方法来一次确认多条消息，减少ack的次数来提升consumer的效率，不过需要自行权衡。

DUPS_OK_ACKNOWLEDGE

类似于AUTO_ACK确认机制，为自动批量确认而生，而且具有“延迟”确认的特点，ActiveMQ会根据内部算法，在收到一定数量的消息自动进行确认。在此模式下，可能会出现重复消息，什么时候？当consumer故障重启后，那些尚未ACK的消息会重新发送过来。

SESSION_TRANSACTED

当session使用事务时，就是使用此模式。当决定事务中的消息可以确认时，必须调用session.commit()方法，commit方法将会导致当前session的事务中所有消息立即被确认。在事务开始之后的任何时机调用rollback()，意味着当前事务的结束，事务中所有的消息都将被重发。当然在commit之前抛出异常，也会导致事务的rollback。

 

1. kafka

• 生产者

如果设置了ack为all，那么一定不会丢失数据

• kafka方面

    需要设置分区副本至少为2.

    min.insync.replicas参数：这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系。

    ack为all，这个是要求所有消息必须写入所有副本才算写入成功

    retries=MAX，这个要求无限重试

• 消费者方面

    关闭自动提交偏移量方式、消费者实现幂等操作。

 

消息的顺序执行

    严格来说，消息系统不应该有顺序依赖。最简单的实现方法就是生产者-消息系统-消费者是一对一关系

1. activemq

• 通过高级特性consumer独有消费者。

    当接收消息的时候，有多个独占着消费者的时候，只有一个消费者可以收到消息。。这样会导致其它消费者被闲置。

• 使用messageGroups

    Message Groups特性是一种负载均衡的机制。在一个消息被分发到consumer之前，broker首先检查消息JMSXGroupID属性。如果存在，那么broker会检查是否有某个consumer拥有这个message group。如果没有，那么broker会选择一个consumer，并将它关联到这个message group。此后，这个consumer会接收这个message group的所有消息，直到：Consumer被关闭。Message group被关闭，通过发送一个消息，并设置这个消息的JMSXGroupSeq为-1

1. kafka

    一个分区一个主题一个消费者

 

如果leader crash时，ISR为空怎么办

    kafka有一个配置参数unclean.leader.election，默认为true，允许不同步副本成为leader，这样会导致消息不一致的情况发生。如果为false，则会导致可用性减低。

kafka生产者如何优化写入速度

1.     多线程写入
2. 提高batch.size
3. 添加分区
4. 根据实际情况修改a'cks值
5. 调大缓冲区大小

传统消息传递方式

• 点对点模式
• 广播模式

kafka中zookeeper作用

    zookeeper用于生产者节点的注册、leader的选举、心跳检测、分布式同步、集群、分区、偏移量信息的存储等。目前是不能脱离zookeeper的。

数据传输的事务定义

• 最多一次。消息不会重复发送，有可能一次也不发
• 最少一次。消息不会漏发，但有可能重复发送
• 精确的一次。消息肯定会发送一次并且仅仅发送一次。

kafka创建消息如何将不同的分区放置到不同的broker中

    第一个分区的第一个副本位置是随机从列表中选取的。其他的副本位置就是从第1个分区之后移动。例如第一个分区在broker3上，那么第二个副本就在broker4上，第三个副本就在broker5上。