kafka存储机制与读写流程

最新推荐文章于 2022-08-19 15:57:30 发布

weixin_34410662

最新推荐文章于 2022-08-19 15:57:30 发布

阅读量1.7k

点赞数 3

文章标签：大数据 python

原文链接：https://my.oschina.net/u/3049601/blog/1826985

版权

2019独角兽企业重金招聘Python工程师标准>>>

存储机制

kafka用topic对消息进行归类，每一个topic可以分为多个分区，分区中的消息不重复，每个分区又有很多个segment（段），segment是在磁盘上就是一对文件，包含index和log文件，两种文件名相同，后缀不同

每个topic的第一个segment的两种文件都是00000000000000000000.index和00000000000000000000.log，后来新产生的文件名都以上一个segment中最有一条消息的offset（偏移量）结束，不足20个字符的用0填充，如图。

kafka数据被消费后虽然不会被立即删除，但不可能一直不删除，kafka根据两个设置定时检测做删除操作

1. 基于时间：log.retention.hours=168
2. 基于大小：log.retention.bytes=1073741824

满足任何一个都会删除之前的segment，记住不是删除某一个消息，删除的最小单位是segment

写流程

先上图

步骤：

1.连接ZK集群，从ZK中拿到对应topic的partition信息和partition的Leader的相关信息

2.连接到对应Leader对应的broker

3.将消息发送到partition的Leader上

4.其他Follower从Leader上复制数据

5.依次返回ACK

6.直到所有ISR中的数据写完成，才完成提交，整个写过程结束

因为是描述写流程，没有将replica与zk的心跳通讯表达出来，心跳通讯就是为了保证kafka高可用。一旦Leader挂了，或者Follower同步超时或者同步过慢，都会通过心跳将信息报告给ZK，由ZK做Leader选举或者将Follower从ISR中移动到OSR中

读流程

步骤：

1.连接ZK集群，从ZK中拿到对应topic的partition信息和partition的Leader的相关信息

2.连接到对应Leader对应的broker

3.consumer将自己保存的offset发送给Leader

4.Leader根据offset等信息定位到segment（索引文件和日志文件）

5.根据索引文件中的内容，定位到日志文件中该偏移量对应的开始位置读取相应长度的数据并返回给consumer

高可用

replication(复制)

topic的每个partition都有1到N个分区，每个分区有多个replica，多个replica中有一个是Leader，其他都是Follower，Leader负责响应producer和consumer的读写请求。一旦有数据写到Leader,则所有的Follower都会从Leader中去同步数据，但并非所有Follower都能及时同步，所以kafka将所有的replica分成两个组：ISR和OSR。ISR是与Leader数据同步的Follower，而OSR是与Leader数据不同步的Follower

Leader failover(Leader失败恢复)

为了保证数据一致性，当Leader挂了之后，kafka的controller默认会从ISR中选择一个replica作为Leader继续工作，选择的条件是：新Leader必须有挂掉Leader的所有数据。

如果为了系统的可用性，而容忍降低数据的一致性的话，可以将"unclean.leader.election.enable = true" ，开启kafka的"脏Leader选举"。当ISR中没有replica，则会从OSR中选择一个replica作为Leader继续响应请求，如此操作提高了Kafka的分区容忍度，但是数据一致性降低了。

broker failover(broker失败恢复)

broker挂了比单个partition的Leader挂了要做的事情多很多，因为一个broker上面有很多partition和多个Leader。因此至少需要处理如下内容：

1.更新该broker上所有Follower的状态

2.从新给Leader在该broker上的partition选举Leader

3.选举完成后，要更新partition的状态，比如谁是Leader等

kafka集群启动后，所有的broker都会被controller监控，一旦有broker宕机，zk的监听机制会通知到controller，controller拿到挂掉broker中所有的partition，以及它上面的存在的leader，然后从partition的ISR中选择一个Follower作为Leader，更改partition的follower和leader状态。

contoller failover(controller失败恢复)

当 controller 宕机时会触发 controller failover。每个 broker 都会在 zookeeper 的 "/controller" 节点注册 watcher，当 controller 宕机时 zookeeper 中的临时节点消失，所有存活的 broker 收到 fire 的通知，每个 broker 都尝试创建新的 controller path，只有一个竞选成功并当选为 controller。

转载于:https://my.oschina.net/u/3049601/blog/1826985