Kafka系列 - kafka基础认知

kafka是什么？

kafka是一个分布式的，基于发布、订阅的消息系统。目前主流互联网公司都在使用kafka，常见的一些使用场景：实时计算、实时推荐、实时风控、埋点监控等。所有的这些业务场景，都依赖kafka作为中间的一个消息系统，比如：数据从mysql binlog日志经过kafka，再到flink计算引擎，数据从logtail日志采集客户端，经过kafka，再到下游业务系统进行埋点处理。为何这么多业务场景都偏爱kafka？

其本质原因是：削峰填谷。防了防止大的流量直接让下游应用雪崩，那么为何选择kafka呢？主要原因与kafka的特性有关：

kafka具有高吞吐能力、大数据存储能力、可靠性非常高，数据丢失率极其低，并且还支持幂等以及事物，可以保证消息从端到端的exactly once，这个在flink中非常重要。同时可以提供offset的功能给到端，业务可以自由处理消息。

整体架构

此图，从知乎上采纳而来，把kafka的整体架构描述的非常清楚。

Producer：生产者，也就是发送消息的一方。生产者负责创建消息，然后将其投递到Kafka中。

Consumer：消费者，也就是接收消息的一方。消费者连接到Kafka上并接收消息，进而进行相应的业务逻辑处理。

Broker：服务代理节点。对于Kafka而言，Broker可以简单地看作一个独立的Kafka服务节点或Kafka服务实例。大多数情况下也可以将Broker看作一台Kafka服务器，前提是这台服务器上只部署了一个Kafka实例。一个或多个Broker组成了一个Kafka集群。

Zookeeper: zookeeper的节点维护了一些基础元数据信息：比如：集群中有哪些broker，以及kafka的动态配置能力。同时zookeeper也用来对控制器进行选举。这里简单说下控制器：在 Kafka 集群中会有一个或多个 broker，其中有一个 broker 会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态。

部署安装

因为电脑是windows电脑，这里重点记录下windows安装的过程以及潜在的坑点。

1. 官网下载合适的kafka版本，注意是二进制包，不是源码包。https://kafka.apache.org/downloads
2. 解压，修改config目录文件夹内的server.properties文件，修改log.dir为合适的磁盘目录，也可以对zk的地址进行修改，因为本机默认启动了zk，所以就用localhost:2181。
3. 启动命令：\bin\windows>kafka-server-start.bat E:\tools\kafka_2.11-2.0.1\config\server.properties，格式为：kafka-server-start.bat server.properties，需要为启动命令指定一个具体的配置文件地址。

windows安装的几个坑点：

1. 执行启动命令，提示：错误: 找不到或无法加载主类，解决办法：https://www.jianshu.com/p/220ed57e07fb
2. 执行启动命令，出现如下报错：

看了下截图，初步猜测是路径符号的问题，改为log.dirs=E:\\tools\\kafka_log，主要是改为\\后解决。

在单机windows上部署一个kafka集群，需要修改server.config配置文件，由于我是起了三个broker服务，对server.config复制了三份，修改如下几个核心配置：broker.id=1，listeners=PLAINTEXT://:9093，log.dirs=E:\\tools\\kafka_log_1。然后再根据上文的命令，启动三个broker进程即可，就可以模拟是一个kafka的集群了。

名词解释

主题（Topic）：Kafka中的消息以主题为单位进行归类，生产者负责将消息发送到特定的主题（发送到Kafka集群中的每一条消息都要指定一个主题），而消费者负责订阅主题并进行消费。主题只是一个逻辑上的概念。

分区（Partition）：Kafka 中的分区机制指的是将每个主题划分成多个分区（Partition），每个分区是一组有序的消息日志。生产者生产的每条消息只会被发送到一个分区中，也就是说如果向一个双分区的主题发送一条消息，这条消息要么在分区 0 中，要么在分区 1 中。同一主题下的不同分区包含的消息是不同的，分区在存储层面可以看作一个可追加的日志（Log）文件，消息在被追加到分区日志文件的时候都会分配一个特定的偏移量（offset）。offset是消息在分区中的唯一标识，Kafka通过它来保证消息在分区内的顺序性，不过offset并不跨越分区，也就是说，Kafka保证的是分区有序而不是主题有序。

副本（Replica）：Kafka 为分区引入了多副本（Replica）机制，通过增加副本数量可以提升容灾能力。同一分区的不同副本中保存的是相同的消息（在同一时刻，副本之间并非完全一样），副本之间是“一主多从”的关系，其中leader副本负责处理读写请求，follower副本只负责与leader副本的消息同步。副本处于不同的broker中，当leader副本出现故障时，从follower副本中重新选举新的leader副本对外提供服务。Kafka通过多副本机制实现了故障的自动转移，当Kafka集群中某个broker失效时仍然能保证服务可用。

ISR/AR: 分区中所有副本，叫做AR (Assigned Replicas)，所有与leader副本保持一定程度同步的副本（同时也包含Leader副本），组成ISR （In-Sync Replicas）,ISR副本是AR副本的子集合，消息会先发送到leader副本，然后follower副本才能从leader副本中拉取消息进行同步，同步期间内follower副本相对于leader副本而言会有一定程度的滞后。前面所说的“一定程度的同步”是指可忍受的滞后范围，这个范围可以通过参数进行配置。与leader副本同步滞后过多的副本（不包括leader副本）组成OSR（Out-of-Sync Replicas），由此可见，AR=ISR+OSR。在正常情况下，所有的 follower 副本都应该与 leader 副本保持一定程度的同步，即 AR=ISR，OSR集合为空。

生产者：负责生产消息，可以是一段程序或者一段脚本，负责把消息发送到某个主题上，消息最终会保存在broker的分区上。

消费者：消费者（Consumer）负责订阅Kafka中的主题（Topic），并且从订阅的主题上拉取消息。代码中常见的写法是一直死循环去拉取消息，同时处理offset。

位移（offset）：对于Kafka中的分区而言，它的每条消息都有唯一的offset，offset是单调递增的。用来表示消息在分区中对应的位置。对于消费者而言，它也有一个offset的概念，消费者使用offset来表示消费到分区中某个消息所在的位置。对于消息在分区中的位置，我们将offset称为“偏移量”；对于消费者消费到的位置，将 offset 称为“位移”，有时候也会更明确地称之为“消费位移”。

HW/LEO:  HW是High Watermark的缩写，俗称高水位，它标识了一个特定的消息偏移量（offset），消费者只能拉取到这个offset之前的消息。LEO是Log End Offset的缩写，它标识当前日志文件中下一条待写入消息的offset。

实例如下：

0-5是已提交消息，6是HW即高水位，消费者只能消费到HW之前的消息，LEO是日志分区中下一条待写入的消息，等于当前分区最大的offset + 1。

消费者组：指的是多个消费者实例共同组成一个组来消费一组主题。这组主题中的每个分区都只会被组内的一个消费者实例消费，其他消费者实例不能消费它。

实例：

某个主题中共有4个分区（Partition）：P0、P1、P2、P3。有两个消费组A和B都订阅了这个主题，消费组A中有4个消费者（C0、C1、C2和C3），消费组B中有2个消费者（C4和C5）。

消费者组A中，4个消费者分别消费每一个分区的数据。消费者组B中，2个消费者，分别消费两个分区的数据。

注意：一个消费者组内，最好是消费者实例的数量不能大于分区数，不然会有消费者实例出现资源浪费，不会消费任何分区。

如下：

重平衡（rebalance）: Rebalance 本质上是一种协议，规定了一个 Consumer Group 下的所有 Consumer 如何达成一致，来分配订阅 Topic 的每个分区。举个例子：假如说，某个topic有100个分区，有一个消费者组A，A里面有20个实例，如何协调这20个实例来分配这100个分区进行消费，假如说又有10个消费者宕机下线后，变成10个实例，又是如何协调的呢？Rebalance最主要是为了解决这种问题。

触发rebalance的几个条件：

1.消费者组内消费者实例发生变化，比如新增实例或者下线宕机实例。

2.主题分区数发生变化，比如topic A 从100个分区，变成200个。

3.还有一个主题数发生变化，比如原先一个消费者组订阅一个主题，后来改为订阅10个主题。

影响点（从极客时间了解到，待实操）：

在 Rebalance 过程中，所有 Consumer 实例都会停止消费，等待 Rebalance 完成。这是 Rebalance 为人诟病的一个方面。其次，目前 Rebalance 的设计是所有 Consumer 实例共同参与，全部重新分配所有分区。其实更高效的做法是尽量减少分配方案的变动。例如实例 A 之前负责消费分区 1、2、3，那么 Rebalance 之后，如果可能的话，最好还是让实例 A 继续消费分区 1、2、3，而不是被重新分配其他的分区。

rebalance流程以及原理，后面文章补上，需要深入剖析和实践操作。

关键参数

• log.dirs：这是非常重要的参数，指定了 Broker 需要使用的若干个文件目录路径。目前我只设置了一个目录，可以设置多个目录，利用逗号分隔。设置多个目录的好处：1）提升读写性能：比起单块磁盘，多块物理磁盘同时读写数据有更高的吞吐量。2）能够实现故障转移：即 Failover。这是 Kafka 1.1 版本新引入的强大功能。要知道在以前，只要 Kafka Broker 使用的任何一块磁盘挂掉了，整个 Broker 进程都会关闭。但是自 1.1 开始，这种情况被修正了，坏掉的磁盘上的数据会自动地转移到其他正常的磁盘上，而且 Broker 还能正常工作。
• log.retention.bytes：这是指定 Broker 为消息保存的总磁盘容量大小。默认值-1，即保存多少数据都可以。
• log.retention.{hours|minutes|ms}：这是个“三兄弟”，都是控制一条消息数据被保存多长时间。从优先级上来说 ms 设置最高、minutes 次之、hours 最低。我这里默认配置文件的值是168小时。
• jvm系列参数，如果 Broker 所在机器的 CPU 资源非常充裕，建议使用 CMS 收集器。启用方法是指定-XX:+UseCurrentMarkSweepGC。否则，使用吞吐量收集器。开启方法是指定-XX:+UseParallelGC。
• 操作系统参数，ulimit -n，设置一个较大的值。

总结

• kafka的特性：高吞吐，数据可持久化存储到磁盘，可靠性强，数据丢失概率极低，并且还支持幂等性和事务，对接flink框架后，可以做到消息端到端的精准一次。
• kafka的整体架构，分为生产者，消费者，broker以及zk。生产者和消费者一般都有kafka的client端程序支持，当然最近也有connector来支持更丰富的功能，比如flink的kafka connector。broker一般是kafka的服务端，用来对主题，分区，offset，消费者分组，日志等管理。
• kafka的整体概念还是比较多的，整体设计是围绕主题进行设计，即一个topic下会有多个分区，每个分区可以通过配置指定多个副本，一般是一个分区三个副本，一个leader，两个follower，再就是对于主题的消费，有消费者组的概念，有了消费者组灵活性大大的增加，横向拓展性大大增强，不过需要注意的是消费者组的重平衡问题，kafka还是有待解决。
• 关键参数，对于kafka非常重要，这里只列举了部分关键参数。包括对日志的存储目录和保存周期管理，后面继续补充对topic的参数管理。