Kafka源码分析及图解原理之Broker端
|
此时producer给该topic分区发送了一条消息。此时的状态如下图所示：  如上图所见，producer发送消息成功后(假设acks=1, leader成功写入即返回)，follower发来了新的FECTH请求，依然请求fetchOffset = 0的数据。和上次不同的是，这次是有数据可以读取的，因此整个处理流程如下图：  显然，现在leader和follower都保存了位移是0的这条消息，但两边的HW值都没有被更新，它们需要在下一轮FETCH请求处理中被更新，如下图所示：  简单解释一下， 第二轮FETCH请求中，follower发送fetchOffset = 1的FETCH请求——因为fetchOffset = 0的消息已经成功写入follower本地日志了，所以这次请求fetchOffset = 1的数据了。Leader端broker接收到FETCH请求后首先会更新other replicas中的LEO值，即将remote LEO更新成1，然后更新分区HW值为1——具体的更新规则参见上面的解释。做完这些之后将当前分区HW值(1)封装进FETCH response发送给follower。Follower端broker接收到FETCH response之后从中提取出当前分区HW值1，然后与自己的LEO值比较，从而将自己的HW值更新成1，至此完整的HW、LEO更新周期结束。 3.3 ISR维护 在0.9.0.0版本之后，只有一个参数：replica.lag.time.max.ms来判定该副本是否应该在ISR集合中，这个参数默认值为10s。意思是如果一个follower副本响应leader副本的时间超过10s，kafka会认为这个副本走远了从同步副本列表移除。 四.日志设计 Kafka的每个主题相互隔离，每个主题可以有一个或者多个分区，每个分区都有记录消息数据的日志文件：  图中有个demo-topic的主题，这个topic有8个分区，每一个分区都存在[topic-partition]命名的消息日志文件 。在分区日志文件中，可以看到前缀一样，但是文件类型不一样的几个文件。比如图中的3个文件，(00000000000000000000.index、00000000000000000000.timestamp、00000000000000000000.log)。这称之为一个LogSegment(日志分段)。 4.1 LogSegment 以一个测试环境的具体例子来讲，一个名为ALC.ASSET.EQUITY.SUBJECT.CHANGE的topic，我们看partition0的日志文件：  （编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
