kafka 实践指南

综述

kafka 在使用中的的基本概念包括，zookeeper，broker，主题，分区，生产者，消费者，消费者群组。

其中zookeeper用于协调broker中的元数据，对整个kafka状态以及元数据的管理，以及保存了分区的偏移量。

broker：kafka集群中的一个实例，一个broker可以包含多个主题，每个主题也可以包含多个分区。

主题：一种逻辑概念，生产者向主题中发送数据，消费者订阅该主题并进行消费。

分区：broker中的实际存储模型，生产者发送的消息存储在分区内（对应的磁盘文件），消费者订阅一个分区并进行消息的消费，可以通过增加主题的分区数，从而提高消费者的并行消费能力。

生产者：产生消息，并向topic中发送相关消息，是kafka数据产生的源头。

消费者：订阅主题，通过分区管理器，分配特定的分区给消费者从而消费消息，是kafka数据的终点。

消费者群组： 生产者产生的消息，最终存储到磁盘内，可以设置不同的消费者群组，从而实现所有消息的再次重放。

broker参数配置

** brokerId

集群内broker唯一标识

** port

服务监听那个端口

** zookeeper.connect

用于保存broker原数据的zookeeper地址是通过zookeeper.connect参数来指定

** log.dirs

kafka所有消息都保存在磁盘上，存放这些日志片段的目录是通过log.dirs来指定 ，使用【，】来分割多个存储路径，broker会根据“最少使用原则”，把同一个分区的日志片段保存到同一个路径下，broker会往拥有最少数目分区的路径新增分区，而不是向拥有最小磁盘空间的路径新增分区。

** num.recovery.threads.per.data.dir

对于如下三种情况，kafka会使用可配置的线程池来处理日志片段

• 服务器正常启动，用于打开每个分区的日志片段。
• 服务器崩溃后重启，用于检查和截断每个分区的日志片段。
• 服务器正常关闭，用于关闭日志片段。

默认情况下，每个日志目录只是用一个线程，这些线程只是在服务器启动或者关闭时会用到。

** auto.create.topic.enable

kafka在如下几种情形下，会自动创建主题

• 生产者向kafka写入消息
• 消费者开始从主题读取消息
• 任意一个客户端请求主题元数据

主题的默认配置

** num.partitions，这个参数很重要

指定新创建的主题包含多少个分区，该参数默认值是1. kafka集群通过分区对主题进行横向扩展，所以当有新的broker加入集群式，可以通过分区个数来实现集群的负载均衡，拥有大量消息的主题如果想要进行负载分散，就需要设置大量的分区。

分区数量的评估：
1. 主题吞吐量/消费者吞吐量酸楚分区个数
2. 如果不知道这些信息，根据经验分区大小限制在25G以内。

** log.retention.ms

决定消息多久以后会被删除，根据时间保留数据是通过检查磁盘上日志片段文件的最后修改时间来实现的，最后修改时间指的是日志片段的关闭时间。

** log.retention.bytes

另一种方式是通过保留的消息字节数来判断消息是否过期，他的值是通过log.retention.bytes来指定，作用在每一个分区上，也就是说如果有一个包含八个分区的主题，并且log.retention.bytes被设为1G，则主题最多可以保留8G的数据。所以，当主题的分区个数增加时，主题的保留数据也随之增加。

** log.segment.bytes

当日志片段大小达到log.segment.bytes指定的上限，当前日志片段就会被关闭，一个新的日志片段被打开，如果一个日志片段被关闭，就开始等待过期时间，这个参数的值越小，就会越频繁的关闭和分配新文件。

** log.segment.ms

指定多长时间之后日志片段被关闭，和log.segment.bytes不存在互斥关系，日志片段会在大小或时间达到上限时被关闭。

基于时间的日志片段对磁盘性能的影响
在使用基于时间的日志片段时，要着重考虑并行关闭多个日志片段对磁盘性能的影响，如果多个分区的日志片段永远不能达到大小的上限，就会发生这种情况，日志片段的关闭操作同时发生。

** message.max.bytes

broker通过设置message.max.bytes参数来限制耽搁消息的大小，默认是1MB，如果生产者尝试发送的消息超过这个大小，会收到broker返回的错误信息。该参数指的是压缩后的大小。这个值对性能有显著的影响，值越大，那么负责处理网络连接和请求线程就需要花越多的时间来处理这些请求，还会增加磁盘写入块的大小，从而影响IO吞吐量。

生产者参数配置

* acks

指定必须要有多少个分区副本收到消息，生产者才会认为消息写入是成功的

** buffer.memory

设置生产者内存缓冲区的大小，生产者用它缓冲要发送到服务器的消息，如果应用程序发送消息的速度超过发送到服务器的速度，会导致生产者空间不足，此时，send（）方法调用阻塞，取决于max.block.ms

** comporession.type

压缩算法，可以设置为snappy，gzip，使用压缩算法可以降低网络传输开销和存储开销，而这也是向kafka发送消息的瓶颈所在

** retries

retries参数决定生产者可以重发消息的次数

** bacth.size

当有多个消息需要发送到同一个分区时，生产者会把他们放在同一个批次里，该参数指定了一个批次可以使用的内存大小，按照字节数计算，当批次被填满，批次里所有消息会被发送出去，不过生产者不一定会等到批次被填满才发送，，半满的批次甚至只包含一个消息的批次也有可能被发送，所以就算把批次设置的很大也不会造成延迟，只是会占用更多的内存，但是设置的太小，因为生产者需要频繁的发送消息，会增加一些额外的开销

** linger.ms

该参数指定在发送批次之前等待更多消息加入批次的时间。kafkaProducer会在批次填满或linger.ms达到上限时把批次发送出去。

** client.id

识别消息的来源

** max.inflight.requests.per.connection

该参数指定生产者在收到服务器响应之前可以发送多少个消息。他的值越高会占用越多的内存，不过也会提升吞吐量，把它设置为1可以保证消息是按照发送的顺序写入服务器，即使发生了重试。

** timeout.ms,request.timeout.ms,metadata.fetch.timeout.ms

request.timeout.ms: 制定生产者在发送数据时等待服务器返回相应的时间。

metadata.fetch.timeout.ms: 生产者在获取元数据时等待服务器返回相应的时间。

timeout.ms: 指定broker等待同步副本返回消息确认的时间，与acks配置相匹配。

** max.block.ms

该参数指定了在调用send()方法或partitionsFor()方法获取元数据时生产者阻塞的时间，当生产者的发送缓冲区已满，或者没有可用的元数据时，这些方法就被阻塞。

** max.request.size

控制生产者发送请求大小，即一条消息或者一次发送消息（可以是多条消息）的消息总大小，需要和broker配置的参数message.max.bytes相匹配。

** receive.buffer.bytes和send.buffer.bytes

这两个参数指定了TCP socket接受和发送数据包的缓冲区大小，如果被设为-1 使用操作系统的默认值，如果生产者和消费者和broker处于不同的数据中心，可以适当增大这些值，因为跨数据中心的网络一般都有比较高的延迟和比较低的带宽。

消费者

消费者与消费者群组

kafka发送到主题的消息会被拆分成多个分区，并最终存盘，假设一个主题包含4个分区，则同一个消费者群组内的消费者会进行负载均衡的消费这四个分区内的消息，如果此时消费者数量为2，则每个消费者负责消费两个分区内的消息，如果消费者为5，则空出一个消费者无可用分区进行消费。而不同的消费者群组内的消费者互不相干，可以从头消费主体内的所有消息。

消费者群组与分区再均衡

分区再均衡： 一个新的消费者加入群组时，他读取的是原本由其他消费者读取的消息，当一个消费者被关闭或者发生崩溃是就离开群组，原本由他读取的分区将由群组内的其他消费者读取，在主题发生变化时，比如管理员增加了新的分区，会发生分区再均衡。正常情况下，我们不希望这样的行为发生，在再均衡期间，消费者无法读取消息，造成整个群组一小段时间的不可用。

心跳：消费者通过向broker（群组协调器）发送心跳来维持他们和群组的从属关系以及对分区的所有权关系，只要消费者以正常的时间间隔来发送心跳，就被认为是活跃的，消费者会在轮训消息或者提交偏移量时发送心跳。如果消费者长时间未发送心跳，则群组协调器认为他已经死亡，就会触发一次再均衡。

消费者群主：当消费者要加入群组时，会向群组协调器发送一个JoinGroup请求，第一个加入群组的消费者将成为“群主”，群主从协调器那里获得群组的成员列表，并负责给每一个消费者分配分区，他使用了一个PartitionAssignor接口的类来决定哪些分区应该被分配给哪个消费者。

消息轮询

消息轮询是消费者API的核心，通过一个简单的轮询向服务起请求数据，轮询会处理所有的细节，包括群组协调，分区再均衡，发送心跳和获取数据。
轮询示例：

poll(): 持续不断的向broker请求数据，poll方法的参数是一个超时时间，用于控制poll方法的阻塞时间，如果参数被设置为0，则立即返回，否则，会在指定的ms内一直等待broker返回数据。poll方法返回一个记录列表。然后循环处理。

轮循不只是获取数据那么简单，在第一次调用新消费者的poll方法时，会负责查找GroupCoordinator,然后加入群组，接受分配的分区，如果发生了再均衡，整个过程也是在轮询期间进行的，当然，心跳也是在轮询里发送出去的，所以，要确保在轮询期间所做的任何处理工作尽快完成。

消费者的配置

** fetch.min.bytes

该属性指定了消费者从服务器获取记录的最小字节数，broker在收到消费者的请求时，如果可用的数据量小于fetch.min.bytes指定的大小，会等到有足够的可用数据时在把它返回给消费者。可以降低broker的负载

** fetch.max.wait.ms

指定broker的等待时间，默认为500ms。

** max.partition.fetch.bytes

指定服务器从每个分区里返回给消费者的最大字节数，默认为1MB。如果一个主题有20个分区，5个消费者，则每个消费者至少需要4M的可用内存来接收记录。

** session.timeout.ms

该属性指定了消费者在被认为死亡之前，可以与服务器断开连接的时间，默人为3s。把session.timeout.ms设的比默认值小，可以更快的检测和恢复崩溃的节点，不过长时间的轮询或垃圾收集可能导致非预期的再均衡，设置的大，会导致检测节点崩溃需要更长的时间

** auto.offset.reset

该属性指定了消费者在读取一个没有偏移量的分区或者偏移量无效的情况下该作何处理，默认值是latest，即在偏移量无效的情况下，消费者从最新的记录开始读区数据（消费者启动之后生成的记录）。

** enable.auto.commit

消费者是否自动提交偏移量，默认为true，需要改为false防止消息拉取后还没来得及处理消费者宕机而造成的数据丢失。

** partition.assignment.strategy

PartitionAssignor根据给定的消费者和主题，决定哪些分区应该被分配给哪个消费者，kafka有两个默认的分配策略：

Range: 将若干个连续的分区分配给消费者，比如有两个消费者C1，C2。三个分区，则C1分配到三个分区的P1，P2，C2分配到P3.

RoundRobin: 轮询式分配。

** max.poll.records:

该属性用于控制单词调用call时能够返回的记录数量，可以帮你控制在轮询里需要处理的数据量。

** receive.buffer.bytes和send.buffer.bytes:

提交和偏移量

提交： 更新分区当前位置的操作叫做提交。
偏移量： 消费者一直处于运行状态，那么偏移量就没有什么作用，不过如果消费者发生崩溃或者有新的消费者加入群组，就会触发再均衡，完成再均衡之后，每个消费者可能分配到新的分区，为了能够继续之前的工作，从偏移量指定的地方继续处理。