Kafka 是一个分布式消息中间件,但是它并不符合JMS 规范,即使消息已经被消费,也不会被马上删除,当消息保留一定时间后,会被批量删除。
kafka节点之间如何复制备份的?
kafka消息是否会丢失?为什么?
通过request.required.acks属性进行配置:
0代表:不进行消息接收是否成功的确认(默认值);
1代表:当Leader副本接收成功后,返回接收成功确认信息;
-1代表:当Leader和Follower副本都接收成功后,返回接收成功确认信息;
六种发送场景
两个维度相交,生成六种情况,如下图:
消息丢失的场景
网络异常
acks设置为0时,不和Kafka集群进行消息接受确认,当网络发生异常等情况时,存在消息丢失的可能;
客户端异常
异步发送时,消息并没有直接发送至Kafka集群,而是在Client端按一定规则缓存并批量发送。在这期间,如果客户端发生死机等情况,都会导致消息的丢失;
缓冲区满了
异步发送时,Client端缓存的消息超出了缓冲池的大小,也存在消息丢失的可能;
Leader副本异常
acks设置为1时,Leader副本接收成功,Kafka集群就返回成功确认信息,而Follower副本可能还在同步。这时Leader副本突然出现异常,新Leader副本(原Follower副本)未能和其保持一致,就会出现消息丢失的情况;
以上就是消息丢失的几种情况,在日常应用中,我们需要结合自身的应用场景来选择不同的配置。
想要更高的吞吐量就设置:异步、ack=0;想要不丢失消息数据就选:同步、ack=-1策略
kafka最合理的配置是什么?
kafka的leader选举机制是什么?
Kafka的Leader选举是通过在zookeeper上创建/controller临时节点来实现leader选举,并在该节点中写入当前broker的信息
{“version”:1,”brokerid”:1,”timestamp”:”1512018424988”}
利用Zookeeper的强一致性特性,一个节点只能被一个客户端创建成功,创建成功的broker即为leader,即先到先得原则,leader也就是集群中的controller,负责集群中所有大小事务。
当leader和zookeeper失去连接时,临时节点会删除,而其他broker会监听该节点的变化,当节点删除时,其他broker会收到事件通知,重新发起leader选举。
kafka对硬件的配置有什么要求?
kafka的消息保证有几种方式?
kafka为什么会丢消息?
为什么 Kafka 性能高?
顺序写磁盘,媲美内存随机访问的性能。
顺序写磁盘的性能是随机写入的性能的6000倍的提升,磁盘不再是瓶颈点。零拷贝技术,减少上下文切换和拷贝次数。s
如何保证Kafka 不丢消息?
1. ACK 机制
通过 ACK 机制保证消息送达。Kafka 采用的是至少一次(At least once),消息不会丢,但是可能会重复传输
2. 复制机制
Kafka 保证可靠性依赖的是复制机制,因为单机容易出现故障。Kafka 以Topic 为单位进行设置复制因子,以 Partition 为单位进行复制,允许一份数据复制到集群中的多个节点上。通过复制,Kafka 在Broker 集群中的部分节点挂掉的情况下,仍然可以继续发送和接收消息。
3. 消息删除机制
Broker 端删除消息有一个配置策略,默认是7天,如果7天消息还没有消费,则有可能被删除,也就是丢消息了。
4. 发送消息
为了得到更好的性能,Kafka 支持在生产者一侧进行本地buffer,也就是累积到一定的条数才发送,如果这里设置不当是会丢消息的。
生产者端设置 producer.type=async, sync,默认是 sync。
当设置为 async,会大幅提升性能,因为生产者会在本地缓冲消息,并适时批量发送。
如果对可靠性要求高,那么这里可以设置为 sync 同步发送。
5. 消费消息
如果更注重可靠性,则需要显示提交 Offset,也就是当所有业务都处理完成的时候,再提交 Offset。这样会导致重复消费,需要提供幂等性接口。