Kafka玩出植物大战僵尸即视感

​从这篇文章你将了解到什么？

• Kafka的topic为何要分区。

• 消费者组的做用。
  

• Kafka分区分配。

“Kafka是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统。”

看着这一句句对Kafka的介绍，以及这张架构图, 忽然感受眼前一阵恍惚......

再睁眼的瞬间, 画风竟然变成了植物大战僵尸的样子!!!

下面咱们来讲道说道这有趣的场景：

咱们熟悉的消息生产者——天然就是植物大战僵尸中能够生成粮食的植物了。

好比生产者豌豆射手：

他能够发送出普通豌豆（消息）。

好比生产者寒冰射手：

他能够发送出寒冰豌豆（消息）。

再来看看咱们可爱的消费者僵尸，他们能够消耗(消费)生产者发出来的豌豆(消息)。

而Kafka broker服务就是一个个炮台!

炮台能够储存豌豆射手发送过来的豌豆， 而后再把这些豌豆投送给僵尸。

ZooKeeper就是僵尸最喜欢的大脑了!

固然这只是一句玩笑，咱们消费者僵尸是不会移动的，也不会去攻击Zookeeper。

这里要说明一下，全部消费者僵尸的梦想都是不放过每一颗属于他的豌豆。他们甚至会主动从炮台拉取(pull)豌豆过来消耗(消费)。

玩过植物大战僵尸的小伙伴们都知道，游戏中是没有Kafka炮台这种东西的。那为何咱们须要Kafka呢?

下面咱们来看看，没有Kafka时，生产者直接面对消费者僵尸的状况。

1 生产者大战僵尸

在没有Kafka的状况下, 豌豆射手(生产者)VS僵尸(消费者)。

豌豆射手要一边留意僵尸的位置, 一边费尽全力将豌豆(消息)发送到僵尸身上!

若是这时候出现一大波新的僵尸!

豌豆射手除了要及时辨认出全部僵尸的位置外, 还要把同一颗豌豆(同一个消息)同时投送给每个僵尸。

豌豆射手还要留意投送出去的的豌豆有没有发送成功，若是一颗豌豆石沉大海，那究竟是这个僵尸已经挂了，仍是方向射偏了？同时还要从万千消费者中找到这个投送失败的僵尸，从新投送。

这也太累了吧!

而从僵尸的角度上看呢, 他除了要消耗每个豌豆, 还要费劲辨认出每个豌豆射手的位置, 不然的话, 就接不到豌豆射手投出来的豌豆了!

随着生产者和消费者的增多，他们之间的关系也就愈来愈混乱。这样一来, 不只豌豆射手累, 僵尸也累!

2 Kafka大战僵尸

若是在豌豆射手和僵尸之间加上一个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的做用。

• 分区的有序性。
  

• 分区数。
  

• 重平衡。