聊聊Kafka(四)Kafka主题与分区

主题

分区副本的分配

副本分配的三个目标：

1. 均衡地将副本分散于各个broker上
2. 对于某个broker上分配的分区，它的其他副本在其他broker上
3. 如果所有的broker都有机架信息，尽量将分区的各个副本分配到不同机架上的broker。

在不考虑机架信息的情况下：

1. 第一个副本分区通过轮询的方式挑选一个broker，进行分配。该轮询从broker列表的随机位置进行轮询。
2. 其余副本通过增加偏移进行分配。

分配案例：

考虑到机架信息，首先为每个机架创建一个broker列表。如：
三个机架（rack1，rack2，rack3），六个broker（0，1，2，3，4，5）
brokerID -> rack
0 -> “rack1”, 1 -> “rack3”, 2 -> “rack3”, 3 -> “rack2”, 4 -> “rack2”, 5 -> “rack1”
rack1：0，5
rack2：3，4
rack3：1，2
这broker列表为rack1的0，rack2的3，rack3的1，rack1的5，rack2的4，rack3的2
即：0, 3, 1, 5, 4, 2
通过简单的轮询将分区分配给不同机架上的broker：

每个分区副本在分配的时候在上一个分区第一个副本开始分配的位置右移一位。
六个broker，六个分区，正好最后一个分区的第一个副本分配的位置是该broker列表的最后一个。

如果有更多的分区需要分配，则算法开始对follower副本进行移位分配。
这主要是为了避免每次都得到相同的分配序列。
此时，如果有一个分区等待分配（分区6），这按照如下方式分配：
6 -> 0,4,2 (而不是像分区0那样重复0,3,1)

跟机架相关的副本分配中，永远在机架相关的broker列表中轮询地分配第一个副本。
其余的副本，倾向于机架上没有副本的broker进行副本分配，除非每个机架有一个副本。
然后其他的副本又通过轮询的方式分配给broker。
结果是，如果副本的个数大于等于机架数，保证每个机架最少有一个副本。
否则每个机架最多保有一个副本。
如果副本的个数和机架的个数相同，并且每个机架包含相同个数的broker，可以保证副本在机架和broker之间均匀分布。

分区

副本机制

Kafka在一定数量的服务器上对主题分区进行复制。
当集群中的一个broker宕机后系统可以自动故障转移到其他可用的副本上，不会造成数据丢失。
–replication-factor 3 1leader+2follower

1. 将复制因子为1的未复制主题称为复制主题。
2. 主题的分区是复制的最小单元。
3. 在非故障情况下，Kafka中的每个分区都有一个Leader副本和零个或多个Follower副本。
4. 包括Leader副本在内的副本总数构成复制因子。
5. 所有读取和写入都由Leader副本负责。
6. 通常，分区比broker多，并且Leader分区在broker之间平均分配。

Follower分区像普通的Kafka消费者一样，消费来自Leader分区的消息，并将其持久化到自己的日志中。
允许Follower对日志条目拉取进行批处理。

同步节点定义：

1. 节点必须能够维持与ZooKeeper的会话（通过ZooKeeper的心跳机制）
2. 对于Follower副本分区，它复制在Leader分区上的写入，并且不要延迟太多

Kafka提供的保证是，只要有至少一个同步副本处于活动状态，提交的消息就不会丢失。

宕机如何恢复
（1）少部分副本宕机
当leader宕机了，会从follower选择一个作为leader。当宕机的重新恢复时，会把之前commit的数据清空，重新从leader里pull数据。
（2）全部副本宕机
当全部副本宕机了有两种恢复方式
1、等待ISR中的一个恢复后，并选它作为leader。（等待时间较长，降低可用性）
2、选择第一个恢复的副本作为新的leader，无论是否在ISR中。（并未包含之前leader commit的数据，因此造成数据丢失）

Leader选举

下图中
分区P1的Leader是0，ISR是0和1
分区P2的Leader是2，ISR是1和2
分区P3的Leader是1，ISR是0，1，2。

生产者和消费者的请求都由Leader副本来处理。Follower副本只负责消费Leader副本的数据和Leader保持同步。

对于P1，如果0宕机会发生什么？
Leader副本和Follower副本之间的关系并不是固定不变的，在Leader所在的broker发生故障的时候，就需要进行分区的Leader副本和Follower副本之间的切换，需要选举Leader副本。

如何选举？
如果某个分区所在的服务器除了问题，不可用，kafka会从该分区的其他的副本中选择一个作为新的Leader。之后所有的读写就会转移到这个新的Leader上。现在的问题是应当选择哪个作为新的Leader。

只有那些跟Leader保持同步的Follower才应该被选作新的Leader。
Kafka会在Zookeeper上针对每个Topic维护一个称为ISR（in-sync replica，已同步的副本）的集合，该集合中是一些分区的副本。
只有当这些副本都跟Leader中的副本同步了之后，kafka才会认为消息已提交，并反馈给消息的生产者。
如果这个集合有增减，kafka会更新zookeeper上的记录。
如果某个分区的Leader不可用，Kafka就会从ISR集合中选择一个副本作为新的Leader。
显然通过ISR，kafka需要的冗余度较低，可以容忍的失败数比较高。
假设某个topic有N+1个副本，kafka可以容忍N个服务器不可用。

为什么不用少数服从多数的方法
少数服从多数是一种比较常见的一致性算发和Leader选举法。
它的含义是只有超过半数的副本同步了，系统才会认为数据已同步；
选择Leader时也是从超过半数的同步的副本中选择。
这种算法需要较高的冗余度，跟Kafka比起来，浪费资源。
譬如只允许一台机器失败，需要有三个副本；而如果只容忍两台机器失败，则需要五个副本。
而kafka的ISR集合方法，分别只需要两个和三个副本。

如果所有的ISR副本都失败了怎么办？

此时有两种方法可选，

1. 等待ISR集合中的副本复活，
2. 选择任何一个立即可用的副本，而这个副本不一定是在ISR集合中。
   需要设置 unclean.leader.election.enable=true

这两种方法各有利弊，实际生产中按需选择。
如果要等待ISR副本复活，虽然可以保证一致性，但可能需要很长时间。而如果选择立即可用的副本，则很可能该副本并不一致。

总结：
Kafka中Leader分区选举，通过维护一个动态变化的ISR集合来实现，一旦Leader分区丢掉，则从ISR中随机挑选一个副本做新的Leader分区。
如果ISR中的副本都丢失了，则：

1. 可以等待ISR中的副本任何一个恢复，接着对外提供服务，需要时间等待。
2. 从OSR中选出一个副本做Leader副本，此时会造成数据丢失

分区重新分配

向已经部署好的Kafka集群里面添加机器，我们需要从已经部署好的Kafka节点中复制相应的配置文件，然后把里面的broker id修改成全局唯一的，最后启动这个节点即可将它加入到现有Kafka集群中。

问题：新添加的Kafka节点并不会自动地分配数据，无法分担集群的负载，除非我们新建一个topic。
需要手动将部分分区移到新添加的Kafka节点上，Kafka内部提供了相关的工具来重新分布某个topic的分区。

使用Kafka自带的 kafka-reassign-partitions.sh 工具来重新分布分区。该工具有三种使用模式：
1、generate模式，给定需要重新分配的Topic，自动生成reassign plan（并不执行）
2、execute模式，根据指定的reassign plan重新分配Partition
3、verify模式，验证重新分配Partition是否成功

自动再均衡

我们可以在新建主题的时候，手动指定主题各个Leader分区以及Follower分区的分配情况，即什么分区副本在哪个broker节点上。

随着系统的运行，broker的宕机重启，会引发Leader分区和Follower分区的角色转换，最后可能Leader大部分都集中在少数几台broker上，由于Leader负责客户端的读写操作，此时集中Leader分区的少数几台服务器的网络I/O，CPU，以及内存都会很紧张。

Leader和Follower的角色转换会引起Leader副本在集群中分布的不均衡，此时我们需要一种手段，让Leader的分布重新恢复到一个均衡的状态。

用Kafka提供的自动再均衡脚本： kafka-preferred-replica-election.sh

修改分区副本

实际项目中，我们可能由于主题的副本因子设置的问题，需要重新设置副本因子或者由于集群的扩展，需要重新设置副本因子。

topic一旦使用又不能轻易删除重建，因此动态增加副本因子就成为最终的选择

假设我们有2个kafka broker分别broker0，broker1。

1. 当我们创建的topic有2个分区partition时并且replication-factor为1，基本上一个broker上一个分区。当一个broker宕机了，该topic就无法使用了，因为两个个分区只有一个能用。
2. 当我们创建的topic有3个分区partition时并且replication-factor为2时，可能分区数据分布情况是
   broker0， partiton0，partiton1，partiton2，
   broker1， partiton1，partiton0，partiton2，
   每个分区有一个副本，当其中一个broker宕机了，kafka集群还能完整凑出该topic的两个分区，例如当broker0宕机了，可以通过broker1组合出topic的两个分区。

使用 kafka-reassign-partitions.sh 修改副本因子

分区分配策略

在Kafka中，每个Topic会包含多个分区，默认情况下一个分区只能被一个消费组下面的一个消费者消费，这里就产生了分区分配的问题。Kafka中提供了多重分区分配算法（PartitionAssignor）的实现：RangeAssignor、RoundRobinAssignor、StickyAssignor。

RangeAssignor

PartitionAssignor接口用于用户定义实现分区分配算法，以实现Consumer之间的分区分配。

消费组的成员订阅它们感兴趣的Topic并将这种订阅关系传递给作为订阅组协调者的Broker。协调者选择其中的一个消费者来执行这个消费组的分区分配并将分配结果转发给消费组内所有的消费者。

Kafka默认采用RangeAssignor的分配算法。

RangeAssignor对每个Topic进行独立的分区分配。对于每一个Topic，首先对分区按照分区ID进行数值排序，然后订阅这个Topic的消费组的消费者再进行字典排序，之后尽量均衡的将分区分配给消费者。这里只能是尽量均衡，因为分区数可能无法被消费者数量整除，那么有一些消费者就会多分配到一些分区。

RangeAssignor策略的原理是按照消费者总数和分区总数进行整除运算来获得一个跨度，然后将分区按照跨度进行平均分配，以保证分区尽可能均匀地分配给所有的消费者。对于每一个Topic，RangeAssignor策略会将消费组内所有订阅这个Topic的消费者按照名称的字典序排序，然后为每个消费者划分固定的分区范围，如果不够平均分配，那么字典序靠前的消费者会被多分配一个分区。
这种分配方式明显的一个问题是随着消费者订阅的Topic的数量的增加，不均衡的问题会越来越严重，比如上图中4个分区3个消费者的场景，C0会多分配一个分区。如果此时再订阅一个分区数为4的Topic，那么C0又会比C1、C2多分配一个分区，这样C0总共就比C1、C2多分配两个分区了，而且随着Topic的增加，这个情况会越来越严重。

字典序靠前的消费组中的消费者比较“贪婪”。

RoundRobinAssignor

RoundRobinAssignor的分配策略是将消费组内订阅的所有Topic的分区及所有消费者进行排序后尽量均衡的分配（RangeAssignor是针对单个Topic的分区进行排序分配的）。如果消费组内，消费者订阅的Topic列表是相同的（每个消费者都订阅了相同的Topic），那么分配结果是尽量均衡的（消费者之间分配到的分区数的差值不会超过1）。如果订阅的Topic列表是不同的，那么分配结果是不保证“尽量均衡”的，因为某些消费者不参与一些Topic的分配。

相对于RangeAssignor，在订阅多个Topic的情况下，RoundRobinAssignor的方式能消费者之间尽量均衡的分配到分区（分配到的分区数的差值不会超过1——RangeAssignor的分配策略可能随着订阅的Topic越来越多，差值越来越大）。

对于消费组内消费者订阅Topic不一致的情况：假设有两个个消费者分别为C0和C1，有2个TopicT1、T2，分别拥有3和2个分区，并且C0订阅T1和T2，C1订阅T2，那么RoundRobinAssignor的分配结果如下：

看上去分配已经尽量的保证均衡了，不过可以发现C0承担了4个分区的消费而C1订阅了T2一个分区，是不是把T2P0交给C1消费能更加的均衡呢？

StickyAssignor

动机
尽管RoundRobinAssignor已经在RangeAssignor上做了一些优化来更均衡的分配分区，但是在一些情况下依旧会产生严重的分配偏差，比如消费组中订阅的Topic列表不相同的情况下。

更核心的问题是无论是RangeAssignor，还是RoundRobinAssignor，当前的分区分配算法都没有考虑上一次的分配结果。显然，在执行一次新的分配之前，如果能考虑到上一次分配的结果，尽量少的调整分区分配的变动，显然是能节省很多开销的。

目标
从字面意义上看，Sticky是“粘性的”，可以理解为分配结果是带“粘性的”：

1. 分区的分配尽量的均衡
2. 每一次重分配的结果尽量与上一次分配结果保持一致

当这两个目标发生冲突时，优先保证第一个目标。第一个目标是每个分配算法都尽量尝试去完成的，而第二个目标才真正体现出StickyAssignor特性的。

我们先来看预期分配的结构，后续再具体分析StickyAssignor的算法实现。
例如：

• 有3个Consumer：C0、C1、C2
• 有4个Topic：T0、T1、T2、T3，每个Topic有2个分区
• 所有Consumer都订阅了这4个分区
  StickyAssignor的分配结果如下图所示（增加RoundRobinAssignor分配作为对比）：
  
  如果消费者1宕机，则按照RoundRobin的方式分配结果如下：
  打乱从新来过，轮询分配：
  
  按照Sticky的方式：
  仅对消费者1分配的分区进行重分配，红线部分。最终达到均衡的目的。
  
  再举一个例子：
• 有3个Consumer：C0、C1、C2
• 3个Topic：T0、T1、T2，它们分别有1、2、3个分区
• C0订阅T0；C1订阅T0、T1；C2订阅T0、T1、T2

分配结果如下图所示

消费者0下线，则按照轮询的方式分配：

按照Sticky方式分配分区，仅仅需要动的就是红线部分，其他部分不动。

StickyAssignor分配方式的实现稍微复杂点儿，我们可以先理解图示部分即可。感兴趣的同学可以研究一下。

总结

本节主要介绍了kafka的主题和分区