从这篇文章你将了解到什么？Kafka的topic为什么要分区。
消费者组的作用。
Kafka的分区分配。
“Kafka是一个分布式、支持分区的(partition)、多副本的(replica)，基于zookeeper协调的分布式消息系统。”
看着这一句句对Kafka的介绍，以及这张架构图, 突然感觉眼前一阵恍惚......
再睁眼的瞬间, 画风居然变成了植物大战僵尸的样子!!!
下面我们来说道说道这有趣的场景：
我们熟悉的消息生产者——自然就是植物大战僵尸中可以生成粮食的植物了。
比如生产者豌豆射手：
他可以发送出普通豌豆(消息)。
比如生产者寒冰射手：
他可以发送出寒冰豌豆(消息)。
再来看看我们可爱的消费者僵尸，他们可以消耗(消费)生产者发出来的豌豆(消息)。
而Kafka broker服务就是一个个炮台!炮台可以储存豌豆射手发送过来的豌豆， 然后再把这些豌豆投送给僵尸。
ZooKeeper就是僵尸最喜欢的大脑了!
当然这只是一句玩笑，我们消费者僵尸是不会移动的，也不会去攻击Zookeeper。
这里要说明一下，所有消费者僵尸的梦想都是不放过每一颗属于他的豌豆。他们甚至会主动从炮台拉取(pull)豌豆过来消耗(消费)。
玩过植物大战僵尸的小伙伴们都知道，游戏中是没有Kafka炮台这种东西的。那为什么我们需要Kafka呢?
下面我们来看看，没有Kafka时，生产者直接面对消费者僵尸的情况。
1生产者大战僵尸
在没有Kafka的情况下, 豌豆射手(生产者)VS僵尸(消费者)。
豌豆射手要一边留意僵尸的位置, 一边费尽全力将豌豆(消息)发送到僵尸身上!
如果这时候出现一大波新的僵尸!
豌豆射手除了要及时辨认出所有僵尸的位置外, 还要把同一颗豌豆(同一个消息)同时投送给每一个僵尸。
豌豆射手还要留意投送出去的的豌豆有没有发送成功，如果一颗豌豆石沉大海，那到底是这个僵尸已经挂了，还是方向射偏了？同时还要从万千消费者中找到这个投送失败的僵尸，重新投送。
这也太累了吧!
而从僵尸的角度上看呢, 他除了要消耗每一个豌豆, 还要费劲辨认出每一个豌豆射手的位置, 否则的话, 就接不到豌豆射手投出来的豌豆了!
随着生产者和消费者的增多，他们之间的关系也就越来越混乱。这样一来, 不仅豌豆射手累, 僵尸也累!
2Kafka大战僵尸
如果在豌豆射手和僵尸之间加上一个Kafka炮台(kafka broker)会怎么样呢?现在豌豆射手只需要关心Kafka炮台的位置, 然后把豌豆发送给Kafka炮台存储起来。豌豆射手不用再关心有多少个消费者僵尸, 只要一心一意地生产豌豆就好, 多舒心!
而消费者僵尸呢， 同样也不需要关心有多少生产者，只需要记住Kafka炮台的位置，专心消耗豌豆就行。
Kafka的使用场景之一就是解耦生产者和消费者，生产者和消费者不再直接接触。
消费者组
Kafka炮台支持两种豌豆投递方式。
把消费者僵尸划分成不同的消费者组，那么就可以实现点对点模式和广播模式。
如果每个消费者僵尸属于不同的消费组，那么同一颗豌豆会被“广播”给每个消费组内的僵尸。
如果每个消费者僵尸都在同一个消费组，那么同一颗豌豆，每一个消费组内只能有一个僵尸能消耗这颗豌豆。
主题与订阅
生产者有很多类型，有普通豌豆射手，有寒冰射手，有火焰射手等等，这些生产者发出来的豌豆就分别对应3个Topic：普通主题，寒冰主题， 火焰主题。
主题如果没有分区，那么就意味着每个炮台只能接收一种主题的豌豆。如果一个炮台接收了寒冰豌豆，那么他就不能再接收普通豌豆。
消费者僵尸也有很多种类型，寒冰僵尸擅长消耗寒冰豌豆，火焰抗性高的僵尸擅长消耗火焰豌豆。
不同的消费者僵尸会主动从Kafka炮台“订阅”自己感兴趣的主题。比如寒冰僵尸会专门去消耗寒冰豌豆，普通僵尸会专门去消耗普通豌豆。
主题没有分区的弊端
很多不同类型生产者其实都可以生产普通豌豆，比如二连豌豆，三连豌豆，加特林豌豆(四连发)，甚至还有可以五连发的豌豆荚。
如果现在战场上投入一批五连发的豌豆荚！
可以预见的是，将会有巨量的普通豌豆发送到普通主题炮台中，很快这个炮台就会积压很多豌豆发送不出去，并且还有可能因为负载过大而宕机，而与此形成鲜明对比的是，其他主题的炮台却是处于空闲状态，连一颗寒冰/火焰豌豆都接收不到。
而站在消费组僵尸的角度上看，即使现在新增再多的消费者，也无法加速豌豆的消耗，因为Kafka炮台已经成为吞吐量的瓶颈。
3主题分区
如果我们让每个炮台都可以接收多种主题的豌豆, 这样就可以充分利用场上的每一个炮台了。这就是主题的分区。
假如现在我们给普通豌豆主题2个分区， 这2个分区分别分布在两个炮台中。
这样场上所有炮台可以接收普通豌豆子弹，理想状态下，是可以减缓了单一炮台的压力，这就是主题分区的特点之一，分布式存储。
而对于消费者僵尸而言，现在同一时间可以有两个消费者僵尸消耗普通豌豆， 加快了豌豆的消耗速度，这主题分区的另一个特点，分布式消费。
4分区分配
现在主题有了分区，在获得了很多好处的同时，又必然会引申出一系列复杂的问题。
生产者的分区分配
如图，如果豌豆荚每次给主题分区1和分区2按4:1的比例发放豌豆，那么最后还是会导致分区1所在的Kafka炮台负担过重。
所有现在生产者要考虑怎么才能把豌豆均匀地分发给各个Kafka炮台。
在Kafka中，如果生产者有指定分区号，那么消息会直接发往指定的分区。否则会提供默认的分区器DefaultPartitioner，对消息的key进行哈希运算得到分区号。如果消息没有key，那么就会采用轮询的方式给主题下的各个分区发送消息。
消费者的分区分配
如图，如果两个分区的豌豆都由同一个消费者僵尸负责消耗，另一个消费者将无所事事，这就是消费者分区分配不均的情况。
所以，消费者僵尸也要讨论由哪些僵尸负责消耗哪些分区的豌豆，让每个僵尸都可以均匀地承受打击。
Kafka提供的消费者分区分配策略有三种，分别是RangeAssignor、RoundRobinAssignor和StickyAssignor。每种策略的具体细节属于僵尸大军中的“高度机密”(面试高频)，我们将在下一篇文章中进行讲解。
broker端的分区分配
思考一下，如果一个生产者把所有豌豆发送给炮台存储后，炮台宕机了，那这批豌豆就丢失了，那怎么才能避免这问题呢？这就是数据的容灾能力问题了。
我们给每个主题的分区引入副本的概念。
如果每一个分区都有2个副本，副本之间的关系是一个Leader对多个follower。
只有Leader副本才能存储豌豆，其他副本只是同步Leader的数据。
如果Leader宕机了，那么就会在剩下的副本中选出新的Leader。这就实现了故障的自动转移。
Kafka集群在创建主题时，就要考虑分区副本应该分配在哪个broker上。
而引入副本机制后，与此相关的优先副本选举，副本之间的同步机制等问题又是一次长篇大论了。
5后续
由于篇幅/时间有限，很多没有提及的问题，就留到下一篇再讲解了。ZooKeeper的作用。
分区的有序性。
分区数。
重平衡。
字节武装
4611
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
