【消息队列面试】11-14：kafka高可靠、高吞吐量、消息丢失、消费模式

十一、kafka消息高可靠的解决方案

1、高可靠=避免消息丢失

解决消息丢失的问题

2、如何解决

（1）保证消息发送是可靠的（发成功了/落到partition）

a.ack参数

发送端，采用ack机制

ack为0时，消息发送完就不管了

ack为1时，leader收到；如果leader宕机，会重新选举，丢失消息

ack为-1时，所有的follower全部同步完成（ISR同步完再返回）

b.unclean.leader.election.enable配置为FALSE，则会禁止ISR以外的follower被选举为leader

（被踢出来的）OSR是没有保持同步的，ISR是已经保持同步的节点

当跟上，又能进入ISR，是一个自动伸缩的

应当配置为FALSE，禁止没跟上的OSR中的节点选举

这种方式可能会降低可用性，但可以提高可靠性

c.重试次数tries>1

没收到，可以通过重试机制，确认发送到MQ中

d.最小同步副本数min.insync.replicas>1【与ack相互配置取得好的平衡】

把ack设置为or/-1时，效率没那么高，尤其是ISR节点多

可以配置此参数，不用同步全部的副本

保证消息不只在leade中有

没有满足此值时，不提供读写服务，写操作会产生异常

（2）保证消费端对是否成功消费敏感-配置offset手动提交

配置为手动提交offset，默认是自动提交

如果是自动提交，没有成功消费，处理失败，会丢失消息

处理完后，手动提交offset，确保消息是已经被消费过，不会产生丢失数据的问题

（3）消息成功落盘（保证节点可靠）-broker减少刷盘间隔

kafka写入pageCache，并从内部读出，由操作系统配置

如果停电，会丢失数据

使用sync函数，可以减少刷盘间隔

十二、kafka为什么比rabbitmq的吞吐量要高

生产者异步发送消息，并没有直接发送到broker，而是将消息发送到生产者

可以增加吞吐量

当消息积累到一定数量的时候，再批量发送至broker

但生产者宕机，消息会丢失，提高性能却降低了可靠性

十三、kafka消息丢失的场景及解决方案

高并发、高吞吐量的消息中间件

实际上，存在消息丢失的风险

1、丢失的场景

（1）发送端

存在的问题：

a.ack设置为0，性能高，但发送失败，消息就会丢失

b.当ack设置为1，只需要等待leader返回，就认为发送成功，有可能丢失消息（leader宕机）

c.leader节点宕机之后，在做follower的选举后，unclean.leader.election.enable配置为TRUE时，可能会从OSR中选举

ISR：节点的可靠性列表，其中的从节点和主节点数据可以保持一致，从节点滞后，就会被踢出到OSR中

解决方案：

a.ack设置的大一点，比如配置为all/-1（表示ISR中的所有节点），或者是2,3，可以保证leader返回就确认，为2时，表示至少要同步到一个从节点，重试次数tries>1

b.最小同步副本数min.insync.replicas>1，表示leader同步的时候，最少同步的follower节点数量，越大越可靠

副本数>1和ack通常搭配使用，最大程度保证消息的持久性

隐形逻辑关系：只有ack为-1或all时，最小同步副本数min.insync.replicas>1才会生效

c.失败的消息对应的offset要单独记录（遇到不可恢复异常要进行抛出）

（2）消费端

存在的问题：

先commit再处理消息，如果在处理消息时发生异常，offset已经提交了，这条消息对于消费者就是丢失了，再也不会被消费到

解决方案：

先处理消息，再进行commit，但可能存在重复消费的情况

（处理的过程中，消费者还没commit，就宕机了，就可能会产生重复消费的问题）

处理：先处理业务，再提交offset--》保证接口的幂等性，就不用担心重复消费

（3）消息在broker端的存储--broker的刷盘（由Linux保证page缓存）

Linux发生故障，应用端没有办法

间隔太长，容易丢失

减小刷盘间隔，保证消息一定能刷到pagecache中

十四、kafka是pull模式还是push模式，其优劣进行分析

1、含义

在consumer端拉取数据的模式

主动拉取pull（主要）☆☆☆☆☆-根据消费能力自己进行拉取

还是

推送到consumer-push

2、比较

（1）pull-由消费端主动拉取

优势：

可以根据消费能力拉取，从而可以控制速率，可以选择单条拉取或批量拉取

同时，可以设置不同的提交方式，可以设置手动提交offset，根据提交方式不同，控制传输方式的不同语义

缺点：

数据为空时，消费者不敏感，可能会导致空轮训，消耗CPU

解决：

通过参数设置，拉取数据为空或设置拉取的条数（10条），未达到就进行阻塞

（2）push-被动

优势：

不会导致consumer的服务等待，没有消息就不会做推送，并不会导致循环等待

缺陷：

无法保证速率，消费端可能会产生超时，并影响连锁反应、拒绝服务/网络拥塞，占用带宽