《Kafka权威指南》读书笔记

《Kafka权威指南》第一、三、四、六章，是重点。可以多看看。

一、 Kafka的组成

• kafka是一个发布与订阅消息系统
• 消息：kafka的数据单元称为"消息"。可以把消息看成是数据库中的一个"数据行"。

消息的key：为key生成一个一致性散列值(HashCode)，然后使用散列值对主题分区数进行取模，为消息选取分区。

• 消息被分批次写入kafka。

批次：就是一组消息，这些消息属于同一个主题和分区。

• 主题(topic)：kafka的消息，是通过topic来分类的。topic，好比数据库里的表，或者文件系统里的文件夹。

topic，可分为若干个分区(partition)。

由于一个topic一般分为几个partition，因此整个Topic范围内无法保证消息的顺序，但可以保证消息在单个Partition内的顺序。

• 生产者(producer)：创建消息。

• 消费者(consumer)：订阅读取消息。

consumer可以订阅一个或多个topic，并按照消息生成的顺序去读取它们。消费者通过检查消息偏移量来区分已经读取过的消息。

• 偏移量(offset)：是一个不断递增的整数值，在创建消息时，Kafka会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。

• 消费者群组： 消费者群组中，会有一个或多个消费者读取同一个topic。
  另外，群组能保证每个分区只能被一个消费者使用。

• 服务器(broker)：Kafka的服务器broker，接收生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。broker为消费者提供服务，对请求作出响应，返回已经提交到磁盘上的消息。broker是集群的重要组成部分。

为什么选择kafka?

• 多个生产者.
• 多个消费者.

多个消费者，能够提高消息的处理效率。

• 基于磁盘的数据存储.
• 伸缩性。

kafka可以灵活地配置broker的个数，根据生产环境的需要进行调整。

• 高性能.

二、Kafka配置

broker配置

• broker.id：服务器id
• port：端口号
• zookeeper.connect:用于保存broker元数据的zookeeper地址是通过此配置来指定的。
• log.dirs：磁盘存放日志的路径。
• auto.create.topics.enable：是否自动创建topic。

topic配置

• num.partitions：指定topic包含多少个分区。
• log.retention.ms：指定日志保留的时间。
• log.retention.bytes：通过保留的消息字节数来判断消息是否过期。
• message.max.bytes:限制单个消息的大小。

三、kafka生产者–向Kafka写入数据

kafka生产者组件图：

图片/kafka分区与消费者的关系

• kafka生产者有3个必选属性：

bootstrap.servers：指定broker的地址清单。建议提供两个以上的broker信息，一旦其中一个宕机，生产者仍然能够连接上集群。

key.serializer：broker的消息的key和value都是字节数组，因此需要序列化。生产者得知道如何把java对象转换成字节数组。key.serializer必须一个实现了Serializer接口的类，生产者会使用这个类把键对象序列化为字节数组。

value.serializer：同上。

生产者发送消息的三种方式：

• 发送并忘记(fire-and forge)：生产者把消息发送给服务器，但并不关心它是否正常到达。生产者会自动尝试重发，不过使用这种方式有时候也会丢失一些消息。

• 同步发送：send()方法发送消息，会返回一个Future对象，调用get()方法进行等待，就可以知道消息是否发送成功。

• 异步发送：调用send()方法，并指定一个回调函数，服务器在返回响应时调用该函数。

生产者使用多线程：

生产者是可以使用多线程来发送消息的。如果需要更高的吞吐量，可以在生产者数量不变的前提下增加线程数量。如果这样做还不够，可以增加生产者数量。

生产者配置：

• key.serializer
  用于 key 键的序列化，它实现了 org.apache.kafka.common.serialization.Serializer 接口

• value.serializer
  用于 value 值的序列化，实现了 org.apache.kafka.common.serialization.Serializer 接口

• acks
  acks 参数指定了要有多少个分区副本接收消息，生产者才认为消息是写入成功的。此参数对消息丢失的影响较大

如果 acks = 0，就表示生产者也不知道自己产生的消息是否被服务器接收了，它才知道它写成功了。如果发送的途中产生了错误，生产者也不知道，它也比较懵逼，因为没有返回任何消息。这就类似于 UDP 的运输层协议，只管发，服务器接受不接受它也不关心。

如果 acks = 1，只要集群的 Leader 接收到消息，就会给生产者返回一条消息，告诉它写入成功。如果发送途中造成了网络异常或者 Leader 还没选举出来等其他情况导致消息写入失败，生产者会受到错误消息，这时候生产者往往会再次重发数据。因为消息的发送也分为 同步 和 异步，Kafka 为了保证消息的高效传输会决定是同步发送还是异步发送。如果让客户端等待服务器的响应（通过调用 Future 中的 get() 方法），显然会增加延迟，如果客户端使用回调，就会解决这个问题。

如果 acks = all，这种情况下是只有当所有参与复制的节点都收到消息时，生产者才会接收到一个来自服务器的消息。不过，它的延迟比 acks =1 时更高，因为我们要等待不只一个服务器节点接收消息。

• buffer.memory
  此参数用来设置生产者内存缓冲区的大小，生产者用它缓冲要发送到服务器的消息。如果应用程序发送消息的速度超过发送到服务器的速度，会导致生产者空间不足。这个时候，send() 方法调用要么被阻塞，要么抛出异常，具体取决于 block.on.buffer.null 参数的设置。
  compression.type
  此参数来表示生产者启用何种压缩算法，默认情况下，消息发送时不会被压缩。该参数可以设置为 snappy、gzip 和 lz4，它指定了消息发送给 broker 之前使用哪一种压缩算法进行压缩。下面是各压缩算法的对比

• retries
  生产者从服务器收到的错误有可能是临时性的错误（比如分区找不到首领），在这种情况下，reteis 参数的值决定了生产者可以重发的消息次数，如果达到这个次数，生产者会放弃重试并返回错误。默认情况下，生产者在每次重试之间等待 100ms，这个等待参数可以通过 retry.backoff.ms 进行修改。

• batch.size
  当有多个消息需要被发送到同一个分区时，生产者会把它们放在同一个批次里。该参数指定了一个批次可以使用的内存大小，按照字节数计算。当批次被填满，批次里的所有消息会被发送出去。不过生产者井不一定都会等到批次被填满才发送，任意条数的消息都可能被发送。

• client.id
  此参数可以是任意的字符串，服务器会用它来识别消息的来源，一般配置在日志里。

• max.in.flight.requests.per.connection
  此参数指定了生产者在收到服务器响应之前可以发送多少消息，它的值越高，就会占用越多的内存，不过也会提高吞吐量。把它设为1 可以保证消息是按照发送的顺序写入服务器。

• timeout.ms、request.timeout.ms 和 metadata.fetch.timeout.ms

request.timeout.ms 指定了生产者在发送数据时等待服务器返回的响应时间，metadata.fetch.timeout.ms 指定了生产者在获取元数据（比如目标分区的首领是谁）时等待服务器返回响应的时间。如果等待时间超时，生产者要么重试发送数据，要么返回一个错误。timeout.ms 指定了 broker 等待同步副本返回消息确认的时间，与 asks 的配置相匹配----如果在指定时间内没有收到同步副本的确认，那么 broker 就会返回一个错误。

• max.block.ms
  此参数指定了在调用 send() 方法或使用 partitionFor() 方法获取元数据时生产者的阻塞时间当生产者的发送缓冲区已捕，或者没有可用的元数据时，这些方法就会阻塞。在阻塞时间达到 max.block.ms 时，生产者会抛出超时异常。

• max.request.size
  该参数用于控制生产者发送的请求大小。它可以指能发送的单个消息的最大值，也可以指单个请求里所有消息的总大小。

• receive.buffer.bytes 和 send.buffer.bytes
  Kafka 是基于 TCP实现的，为了保证可靠的消息传输，这两个参数分别指定了 TCP Socket 接收和发送数据包的缓冲区的大小。如果它们被设置为 -1，就使用操作系统的默认值。如果生产者或消费者与 broker 处于不同的数据中心，那么可以适当增大这些值。

生产者发送消息的顺序保证

• kafka可以保证同一个分区里的消息是有序的。也就是说生产者按照一定的顺序发送消息，broker就会按照这个顺序把它们写入分区，消费者也会按照顺序读取它们。

• 如果把retries设为非零整数，同时把max.in.flight.requests.per.connection设为比1大的值，那么如果第一个批次消息写入失败，而第二个批次写入成功，broker会重试写入第一个批次。如果此时第一个批次也写入成功，那么两个批次的顺序就反过来了。
  可以把max.in.flight.requests.per.connection设为1，这样在生产者尝试发送第一批消息时，就不会有其他的消息发送给broker。对消息的顺序有严格要求的情况下才能这么做，不然会影响吞吐量。

四、Kafka消费者–从Kafka读取消息

分区和消费者的关系

• 为什么kafka每个Partition，只能被消费者群组中的一个消费者消费？

假设群组内的多个消费者负责同一个分区，那么会有什么问题呢？

我们知道，Kafka它在设计的时候就是要保证分区下消息的顺序，也就是说消息在一个分区中的顺序是怎样的，那么消费者在消费的时候看到的就是什么样的顺序，那么要做到这一点就首先要保证消息是由消费者主动拉取的（pull），其次还要保证一个分区只能由一个消费者负责。倘若，两个消费者负责同一个分区，那么就意味着两个消费者同时读取分区的消息，由于消费者自己可以控制读取消息的offset，就有可能C1才读到2，而C1读到1，C1还没处理完，C2已经读到3了，则会造成很多浪费，因为这就相当于多线程读取同一个消息，会造成消息处理的重复，且不能保证消息的顺序，这就跟主动推送（push）无异。

• 假如两个不同群组的消费者，分别去消费同一个分区，那么分区消息上的偏移量会怎么变化？这两个消费者，最终能读取到相同的消息么？

不同的消费者群组可以从同一主题获取所有的消息，消费者群组G1和消费者群组G2之间互不影响。

多个应用程序可以从同一主题获取到所有的消息。

只要保证每个订阅的应用程序都有自己的不同的消费者群组，每个订阅的应用程序都可以从同一主题获取所有的消息，而不只是其中的一部分。

轮询

轮询是消费者api的核心。通过一个简单的轮询向服务器请求数据，一旦消费者订阅了主题，轮询就会处理群组协调、分区再均衡、发送心跳、获取数据。

其他

• 内存映射

概括：用户空间的一段内存区域映射到内核空间，这样，无论是内核空间或用户空间对这段内存区域的修改，都可以直接映射到另一个区域。
优势：如果内核态和用户态存在大量的数据传输，效率是非常高的。
为什么会提高效率：概括来讲，传统方式为read()系统调用，进行了两次数据拷贝；内存映射方式为mmap()系统调用，只进行一次数据拷贝

• 零拷贝方式：
  如何让数据不经过用户空间？零拷贝省略了拷贝到用户缓冲的步骤，通过文件描述符，直接从内核空间将数据复制到网卡接口。