目录
4、zk保存kafka数据的目录结构是什么样子的,在kafka集群中的作用
一、工作流程
Kafka中消息是以topic进行分类的,生产者生产消息,消费者消费消息,都是面向topic的。
topic是逻辑上的概念,而partition是物理上的概念,每个partition对应于一个log文件,该log文件中存储的就是producer生产的数据。Producer生产的数据会被不断追加到该log文件末端,且每条数据都有自己的offset。消费者组中的每个消费者,都会实时记录自己消费到了哪个offset,以便出错恢复时,从上次的位置继续消费。
由于生产者生产的消息会不断追加到log文件末尾,为防止log文件过大导致数据定位效率低下,Kafka采取了分片和索引机制,将每个partition分为多个segment。每个segment对应两个文件——“.index”文件和“.log”文件。这些文件位于一个文件夹下,该文件夹的命名规则为:topic名称+分区序号。例如,first这个topic有三个分区,则其对应的文件夹为first-0,first-1,first-2。
00000000000000000000.index
00000000000000000000.log
00000000000000170410.index
00000000000000170410.log
00000000000000239430.index
00000000000000239430.log
1、分区的好处
1,方便集群的伸缩
每个Partition可以通过调整以适应它所在的机器,而一个topic又可以有多个Partition组成,因此整个集群就可以适应任意大小的数据了
2,可以提高并发
可以以Partition为单位读写,提高集群的读写速度
2、分区是如何分配到broker上
目的
1. 保证所有的分区以及副本可以均衡在分布上所有的broker上
2. 保证同一个分区及其副本尽量不要分布在同一个broker上
规则
让分区和broker进行排序 partition leader排序: p0 p1 p2 p3
partition 副本: p0r p1r p2r p3r
broker排序: br0 br1 br2
分区怎么分配到broker上: p0随机一个broker topic越多,每个topic都对应有一个p0 越平均的分配到不同的broker
leader p0->br1 p1->br2 p2 ->br0 p3->br1(p0随机,以后的放入下一个)
副本随机: p0r->br0 p1r->br1 p2r->br1 p3r->br2
3、副本的好处
提高kafka的系统的可靠性和稳定性,同一个partitation对应一个或者多个副本,创建topic时就可以设置(--replication-factor 2)。没有副本,一旦当前保存消息的服务器宕机,就会造成消息丢失,如果有replication,当保存消息的服务器宕机后,从新选举新的leader,继续进行消息读写,不会造成消息丢失。
4、zk保存kafka数据的目录结构是什么样子的,在kafka集群中的作用
1,broker在zk中注册:集群启动时,每个broker都会在/brokers/ids/下注册(创临时节点),如果broker挂掉了,zk就会删除该节点。
2,topick会在zk中注册:创建topic时,每个topic都会在/brokers/topics/下注册,topic删除,节点失效。每个broker和topic的对应关系也是由zk进行维护。
3,consumer(消费者)在zk注册:当新的消费者都会zk进行注册,zk在/consumers/consumer-group/ 创建3个节点 ids offsets(偏移量) owners
ids: 记录当前消费者组所有的消费者id
offsets:消费者在消费topic每个partition时,消费到哪个位置(offset 偏移量)
owners:记录该消费者组消费的topic信息(订阅了哪些topic)
新版本无效
二、生产者如何写入消息的
get /brokers/topics/tpa/partitions/0/state
{"controller_epoch":7,"leader":2,"version":1,"leader_epoch":19,"isr":[2]}
ack=-1/all
为保证producer发送的数据,能可靠的发送到指定的topic,topic的每个partition收到producer发送的数据后,都需要向producer发送ack(acknowledgement确认收到),如果producer收到ack,就会进行下一轮的发送,否则重新发送数据。
1、消息写入时,放入分区的规则
1、指定分区,直接按照指定分区写入
2、没有指定分区,但是消息中含有key(一般消息是key value的方式),通过key的值进行hash运算,计算得到一个partition,写入到这个分区。(aaa hash运算后可能得到一个和aaa没有任何关系的一个数值123132,对分区的总数量取模,根据结果,得到分区)
3、如果没有指定分区,key都没有,使用轮询(第一次调用时随机生成一个整数(后面每次调用在这个整数上自增),将这个值与 topic 可用的 partition 总数取余得到 partition 值,也就是常说的 round-robin 算法),找出一个分区,并写入。
2、ack应答机制
0 producer不等待broker同步完成的确认,继续发送下一条(批)信息
提供了最低的延迟。但是最弱的持久性,当服务器发生故障时,就很可能发生数据丢失。例如leader已经死亡,producer不知情,还会继续发送消息broker接收不到数据就会数据丢失
1 producer要等待leader成功收到数据并得到确认,才发送下一条message。此选项提供了较好的持久性较低的延迟性。Partition的Leader死亡,follwer尚未复制,数据就会丢失
-1/all 意味着producer得到leader和所有follwer确认,才发送下一条数据
3、ISR(In Sync Replicas)
当ack配置-1时 leader收到数据,所有follower都开始同步数据,但有一个follower,因为某种故障,迟迟不能与leader进行同步,那leader就要一直等下去,直到它完成同步,才能发送ack。这个问题怎么解决呢?
Leader维护了一个动态的in-sync replica set (ISR),意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后,follower就会给leader发送ack。如果follower长时间未向leader同步数据,则该follower将被踢出ISR,该时间阈值由replica.log.time.max.ms参数设定。Leader发生故障之后,就会从ISR中选举新的leader。
三、消费者消费要点
消息的消费模式有两种:推送模式(push) 和拉取模式(pull)
kafka采取的拉取模式(pull),由消费者自己记录消费状态(消费者自己记录自己的消费位置(offset偏移量)),每个消费者相互独立的消费每个一个分区的消息。每个消费者消费完了后,对消息本身不做任何处理,决定该消息是否能被删除,跟消费者没有任何关系,与配置的消息过期时间和消息总容量的大小配置参数有关(log.retention.hours=168 log.retention.bytes=1G)。
消费者是以消费者组( consumer group)的方式,由一个或者多个消费者组成一个组,共 同消费一个topic(主题),在同一时刻,只能由同一个组的一个消费者去消费同一个分区。
pull模式不足之处是,如果kafka没有数据,消费者可能会陷入循环中,一直返回空数据。针对这一点,Kafka的消费者在消费数据时会传入一个时长参数timeout,如果当前没有数据可供消费,consumer会等待一段时间之后再返回,这段时长即为timeout。
四、相关面试
kafka 如何减少数据丢失
Producer端:
#在Producer端用来存放尚未发送出去的Message的缓冲区大小。缓冲区满了之后可以选择阻塞发送或抛出异常,由block.on.buffer.full的配置来决定。
block.on.buffer.full = true
acks = all
#无限重试,直到你意识到出现了问题
retries = MAX_VALUE
#限制客户端在单个连接上能够发送的未响应请求的个数。设置此值是1表示kafka broker在响应请求之前client不能再向同一个broker发送请求。
max.in.flight.requests.per.connection = 1
#而不是send(record)方法自定义回调逻辑处理消息发送失败
使用KafkaProducer.send(record, callback)
#设置此参数是为了避免消息乱序
callback逻辑中显式关闭producer:close(0)
#关闭unclean leader选举,即不允许非ISR中的副本被选举为leader,以避免数据丢失
unclean.leader.election.enable=false
replication.factor = 3
#消息至少要被写入到这么多副本才算成功,也是提升数据持久性的一个参数。与acks配合使用
min.insync.replicas = 2
replication.factor > min.insync.replicas
Consumer端:
consumer端丢失消息的情形比较简单:如果在消息处理完成前就提交了offset,那么就有可能造成数据的丢失。由于Kafka consumer默认是自动提交位移的,所以在后台提交位移前一定要保证消息被正常处理了,因此不建议采用很重的处理逻辑,如果处理耗时很长,则建议把逻辑放到另一个线程中去做。为了避免数据丢失,现给出两点建议:
enable.auto.commit=false
消息处理完成之后再提交位移
消费者故障,出现活锁问题如何解决?
kafka 消费者正常情况下是订阅一个 topic 并且能够 poll 消息。该消费者会占用一个分区,同时需要定时向 zk 发送心跳监测,以证明自己活着。当消费者占用一个分区后,且能够正常发送心跳,但是不 poll 消息了,不再进行消息处理了,这种情况下就出现了活锁。
kafka 这边处理的时候会配置 max.poll.interval.ms 活跃监测机制。如果客户端调用 poll 的频率大于最大间隔,就会将当前客户端连接断开,让其它的消费者过来消费。
kafka 如何不消费重复数据?
1,幂等操作,重复消费不会产生问题
2,对每个partitionID,产生一个uniqueID,.只有这个partition的数据被完全消费,才算成功,否则失败回滚。下次若重复执行,就skip