【深入理解Kafka系列】第四章 主题与分区

        主题和分区是Kafka的两个核心概念，主题作为消息的归类，可以再细分为一个或者多个分区，分区可以看作是对消息的二次归类。分区的划分不仅可以为Kafka提供了可伸缩性，水平扩展能力，还可以通过副本机制来为Kafka提供数据冗余以提高数据的可靠性，为了做到均匀分布，通常partition的数量通常是BrokerServer数量的整数倍。

        从底层上来说，主题和分区都是逻辑上的概念。分区可以有一个或多个副本，每个副本对应一个日志文件，每个日志文件对应一个或多个日志段文件。

        主题、分区、副本、日志关系：

1、主题

        主题是一个逻辑概念，代表了一类消息，实际工作中我们使用主题来区分业务。

  1.1、创建主题  

[root@localhost kafka_2.12-2.4.1]# bin/kafka-topics.sh --create -zookeeper 127.0.0.1:2181 -replication-factor 3 --partitions 3 --topic topic-create
Created topic topic-create.

        –create： 表示创建主题

        –zookeeper: 后面表示kafka集群中的使用的zookpeer集群地址

        –replication-factor：代表副本数

        –partitions：代表分区数

        –topic：代表主题的名称

        执行完脚本后，Kafka会在log.dir或log.dirs参数配置的目录（默认目录为：/tmp/kafka-logs/）下创建相应的主题分区，其实就是创建对应的文件夹，命名方式概括为<topic>-<partition>。

        每个副本（或者确切说是日志，副本与日志一一对应）才真正对应一个命名形式如<topic>-<partition>的文件夹。

 

  1.2、查看主题

        使用list来查看所有的主题

[root@localhost kafka_2.12-2.4.1]# bin/kafka-topics.sh --zookeeper localhost:2181 -list
__consumer_offsets
topic-create
topic-demo
topic-demo2
topic-demo3

  1.3、修改主题

        我们现在将topic-create的分区数量增加一个。

[root@localhost kafka_2.12-2.4.1]# bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic topic-create --partitions 4
WARNING: If partitions are increased for a topic that has a key, the partition logic or ordering of the messages will be affected
Adding partitions succeeded!

        kafka只支持增加分区而不支持减少分区。

  1.4、删除分区

> bin/kafka-topics.sh --zookeeper 127.0.0.1:2181 --delete --topic hello_config

        这里的删除只是将topic标记为已删除，并没有实际删除。

        要真正的删除主题，需要执行下面三个步骤：

                步骤一：删除zookeeper的/config/topics/{topic}结点
                步骤二：删除zookeeper的/brokers/topics/{topic}及其子结点
                步骤三：删除kafka日志文件

2、分区

• 每个topic（逻辑名称）由一个或多个分区组成，分区是topic物理上的分组，在创建topic时被指定。
• 一个partition只对应一个Broke，一个Broke可以管理多个partition。
• 由消息在顺序写入，在同一个分区内的消息是有序的，在不同的分区间，kafka并不保证消息的顺序（所以kafka消息是支持跨分区的）。
• 同一个主题下，不同分区所包含的内容是不同的，每个消息被添加到分区当中时，会被 分配一个偏移量（Offset），它是消息在分区当中的唯一编号，kafka通过offset来确保分区内的消息是顺序的，offset的顺序并不跨越分区。
• 要想保证消息顺序消息，需要将partion数目设为1。

  2.1、分区写入策略

        所谓分区写入策略，即是生产者将数据写入到kafka主题后，kafka如何将数据分配到不同分区中的策略。常见的有三种策略：

• 随机策略：每次都随机地将消息分配到每个分区。

• 轮询策略：按顺序轮流将每条数据分配到每个分区中。轮询策略是默认的策略，除非有特殊的业务需求，否则使用这种方式即可。
• 按键（key）保存策略：当生产者发送数据的时候，可以指定一个key，计算这个key的hashCode值，按照hashCode的值对不同消息进行存储。

        kafka默认是实现了两个策略，没指定key的时候就是轮询策略，有的话那就是按键保存策略了。

  2.2、实现自定义分区

        Kafka提供了两种让我们自己选择分区的方法：

                第一种是在发送producer的时候，在ProducerRecord中直接指定，但需要知道具体发送的分区index，所以并不推荐。

                第二种则是需要实现Partitioner.class类，并重写类中的partition(String topic, Object key, byte[] keyBytes,Object value, byte[] valueBytes, Cluster cluster) 方法，后面在生成kafka producer客户端的时候直接指定新的分区类就可以了。

3、副本

        在kafka中，每个主题可以有多个分区，每个分区又可以有多个副本。这多个副本中，只有一个是leader，而其他的都是follower副本。仅有leader副本可以对外提供服务。
        多个follower副本通常存放在和leader副本不同的broker中，通过这样的机制实现了高可用，当某台机器挂掉后，其他follower副本也能迅速”转正“，开始对外提供服务。

  3.1、AR、ISR、OSR：

• AR：分区中的所有副本统称为AR ( Assigned Replicas ) 。
• ISR：所有与leader 副本保持一定程度同步的副本（包括leader 副本在内）组成ISR （In-Sync Replicas ) , ISR 集合是AR 集合中的一个子集。所谓“ 一定程度的同步”是指可忍受的滞后范围，这个范围可以通过参数进行配置。
• OSR: 与leader 副本同步滞后过多的副本（不包括leader 副本）组成OSR ( Out-of-Sync Replicas ），由此可见， AR=ISR+OSR 。

        默认情况下， 当leader 副本发生故障时，只有在ISR集合中的副本才有资格被选举为新的leader， 而在OSR集合中的副本则没有任何机会（不过这个原则也可以通过修改相应的参数配置来改变） 。

  3.2、kafka的副本都有哪些作用？

        在kafka中，副本的目的就是冗余备份，且仅仅是冗余备份，所有的读写请求都是由leader副本进行处理的。follower副本仅有一个功能，那就是从leader副本拉取消息，尽量让自己跟leader副本的内容一致。

  3.3、为什么follower副本不对外提供服务

        如果follower副本也对外提供服务那会怎么样呢？首先，性能是肯定会有所提升的。但同时，会出现一系列问题。类似数据库事务中的幻读，脏读。比如你现在写入一条数据到kafka主题a，消费者b从主题a消费数据，却发现消费不到，因为消费者b去读取的那个分区副本中，最新消息还没写入。而这个时候，另一个消费者c却可以消费到最新那条数据，因为它消费了leader副本。