kafka相关问题总结

一直在使用kafka,遇到过很多问题,总结一下

数据丢失???

很多人对比kafka和AMQP的时候,都会强调kafka会丢数据,感觉好像只要用kafka就会丢数据一样,从而排斥使用kafka,亦或者在使用的过程中,发现数据丢失就认定罪魁祸首是kafka,好像丢数据就是使用kafka的代价。悄悄的鄙视一下这些伪程序猿。

kafka是一个强调高性能、高吞吐量的分布式消息中间件,在CAP中强调CP,当失去Broker Controller,选举新的Controller前服务处于不可用的状态,毕竟作为消息中间件对数据一致性还是有很高的要求。

大致解释一下kafka集群,kafka server一般叫broker,在集群里,各个broker通过zookeeper抢占broker controller,Controller的职责是管理所有的Partition和Replica的分布以及ISR列表并通知其他broker,如果controller宕机,其他broker又通过zk抢占Controller,在Controller选举的过程中,服务处于不可用的状态。

partition leader和partition replica:新建过topic的同学肯定知道,在新建topic的时候,我们一般会指定两个变量partition和replica,其实每个topic都是由多个partition组成的,一般情况下,partition的数量等于broker的数量,生产端产生数据存储在这些partition中。如果每个partition都没有备份,一旦服务器宕机,其中的数据都无法消费了,所以需要若干partition replica去备份这些partition, 而这些被备份的partition就称之为partition leader。这里再解释一下leader和replica切换的问题,leader与replica的数据copy肯定会有延迟的问题,不可能保证每时每刻replica的数据都与leader一致,所以就引入了一个ISR列表去维护哪些replica的数据是完整的,是值得信赖的,当replica中的数据与leader中的数据的延迟量超过一定的数值(可以自己设定的)或者卡住多少时间不返回的时候,这个replica就会被移除ISR列表,意味着此时如果leader宕机,当前这个replica是没有机会成为leader的,除非ISR列表里没有可用的replica。当这个replica的延迟或者返回时间恢复正常后,又会动态的把这个replica加入到ISR列表,总之ISR列表是动态的。

消息写入kafka的过程:producer会通过所连接的broker获取到当前kafka集群的状态例如broker地址、partition的分配等,producer通过消息中的key或者round robin选择要写入的partition, producer只会将消息写入partition leader, 再由leader分发给所有的replica。在这个过程中,producer可以指定消息写入的ack模型,acks=0时,意味着不在乎消息是否已经写入partition leader,只要发送了就好;acks=1,消息写入leader需要返回ack才算成功;acks=-1或者all,消息写入leader后且所有replica也都写入并返回leader ack后才算成功。producer发送消息的确认模式选择就可能导致数据丢失,例如:当acks=1时,数据成功写入partition leader,producer会认为消息投递成功啦,突然partition leader在通知replica备份之前挂了,这条数据就沉入大海了,即使这个leader在一段时间后恢复,其他的replica可能早就已经取代它,成为新的leader了。

消息持久化broker时也可能发生丢失,在未写入硬盘前,机器挂掉也可能丢失数据,这种情况就认命吧,或者让acks更严格,消息未确认写入成功时能够继续重试。

最后就是消费的时候也可能发生丢失,kafka的消费模式和传统的AMQP是完全不同的,传统AMQP通过broker推送从而由broker控制消息的消费,消费端处理消息后需要通知broker消费状态(例如rabbitmq的ack,nack)如果失败broker会重新将消息推给其他消费端;kafka则是通过pull的方式,由消费端从broker上拉取消息,而拉取哪些消息由消费端自己控制(存在zk也是自己控制),这就导致如果消费失败,且消费端没有做好相应处理,offset+1后,这条消息也就丢失了,所以对不允许数据丢失的业务,可以通过代码管理offset。

消费消息没有顺序???

kafka的消费端有两个概念consumer group和consumer, consumer group由多个consumer组成,partition只能被在同一个consumer group中的一个consumer消费,但是可以被多个不同consumer group的consumer同时消费,如果consumer group中只有一个consumer,那么这个consumer可以消费所有的partition,所以一般来说有多少partition就初始化多少consumer,这样消费效率最高。

既然kafka允许多个consumer对多个partition同时消费且producer投递的消息也落于不同的partition中,那么在这种情况下,消费这些消息的顺序肯定是不可控的。但是要知道kafka的partition是只能被一个consumer(同一group下)消费的,那么只要让消息全部都落入同一个partition不就好了,我们投递消息的过程中通过设定消息的key就能让kafka producer根据key进行hash选择要写入的partition,就能保证消息写入的顺序以及消费的顺序。

    原文作者:穆砚
    原文地址: https://zhuanlan.zhihu.com/p/35027158
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞