微处事架构之–动静行列Kafka图解最全常识点

broker动静存储

• Kafka的动静以二进制的方法紧凑地存储，节减了很大空间
• 另外动静存在ByteBuffer而不是堆，这样broker历程挂掉时，数据不会丢失，同时停止了gc题目
• 通过零拷贝温次序寻址，让动静存储和读取速率都很是快
• 处理赏罚fetch哀求的时辰通过zero-copy 加速速率

broker状态数据

• broker计划中，每台呆板都生涯了沟通的状态数据。首要包罗以下：
• controller地址的broker ID，即生涯了当前集群中controller是哪台broker
• 集群中全部broker的信息：好比每台broker的ID、机架信息以及设置的多少组毗连信息
• 集群中全部节点的信息：严酷来说，它和上一个有些一再，不外此项是凭证broker ID和监听器范例举办分组的。对付超大集群来说，行使这一项缓存可以快速地定位和查找给定节点信息，而无需遍历上一项中的内容，算是一个优化吧
• 集群中全部分区的信息：所谓分区信息指的是分区的leader、ISR和AR信息以及当前处于offline状态的副本荟萃。这部门数据凭证topic-partitionID举办分组，可以快速地查找到每个分区的当前状态。(注：AR暗示assigned replicas，即建设topic时为该分区分派的副本荟萃)

broker负载平衡

分区数目负载：各台broker的partition数目应该匀称

partition Replica分派算法如下：

1. 将全部Broker(假设共n个Broker)和待分派的Partition排序
2. 将第i个Partition分派到第(i mod n)个Broker上
3. 将第i个Partition的第j个Replica分派到第((i + j) mod n)个Broker上

容量巨细负载：每台broker的硬盘占用巨细应该匀称

在kafka1.1之前，Kafka可以或许担保各台broker上partition数目匀称，但因为每个partition内的动静数差异，也许存在差异硬盘之间内存占用差别大的环境。在Kafka1.1中增进了副本跨路径迁徙成果kafka-reassign-partitions.sh，我们可以团结它和监控体系，实现自动化的负载平衡

Kafka高可用

在先容kafka高可用之前先先容几个观念

• 同步复制：要求全部能事变的Follower都复制完，这条动静才会被以为commit，这种复制方法极大的影响了吞吐率
• 异步复制：Follower异步的从Leader pull数据，data只要被Leader写入log以为已经commit，这种环境下假如Follower落伍于Leader的较量多，假如Leader溘然宕机，会丢失数据

Isr

Kafka结条约步复制和异步复制，行使ISR(与Partition Leader保持同步的Replica列表)的方法在确保数据不丢失和吞吐率之间做了均衡。Producer只需把动静发送到Partition Leader，Leader将动静写入当地Log。Follower则从Leader pull数据。Follower在收到该动静向Leader发送ACK。一旦Leader收到了ISR中全部Replica的ACK，该动静就被以为已经commit了，Leader将增进HW而且向Producer发送ACK。这样假如leader挂了，只要Isr中有一个replica存活，就不会丢数据。

Isr动态更新

Leader会跟踪ISR，假如ISR中一个Follower宕机，可能落伍太多，Leader将把它从ISR中移除。这里所描写的“落伍太多”指Follower复制的动静落伍于Leader后的条数高出预定值(replica.lag.max.messages)可能Follower高出一按时刻(replica.lag.time.max.ms)未向Leader发送fetch哀求。

broker Nodes In Zookeeper

/brokers/topics/[topic]/partitions/[partition]/state 生涯了topic-partition的leader和Isr等信息

Controller认真broker妨碍搜查&&妨碍转移(fail/recover)

• Controller在Zookeeper上注册Watch，一旦有Broker宕机，其在Zookeeper对应的znode会自动被删除，Zookeeper会触发 Controller注册的watch，Controller读取最新的Broker信息
• Controller确定set_p，该荟萃包括了宕机的全部Broker上的全部Partition
• 对set_p中的每一个Partition，推举出新的leader、Isr，并更新功效。

3.1 从/brokers/topics/[topic]/partitions/[partition]/state读取该Partition当前的ISR

3.2 抉择该Partition的新Leader和Isr。假如当前ISR中有至少一个Replica还幸存，则选择个中一个作为新Leader，新的ISR则包括当前ISR中全部幸存的Replica。不然选择该Partition中恣意一个幸存的Replica作为新的Leader以及ISR(该场景下也许会有隐藏的数据丢失)

3.3 更新Leader、ISR、leader_epoch、controller_epoch：写入/brokers/topics/[topic]/partitions/[partition]/state

直接通过RPC向set_p相干的Broker发送LeaderAndISRRequest呼吁。Controller可以在一个RPC操纵中发送多个呼吁从而进步服从。

Controller挂掉

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!