从架构的角度看Kafka(三)

本文章内容皆出自作者阅读胡夕著Apache Kafka 实战一书的总结，可能有理解错误，仅作为参考。如有侵权，笔者将会删除它们。

注：本文将会讲解producer的使用以及一些机制。

1.1 Client

    Kafka有很完善的生态系统，支持大部分主流的语言。笔者这里就简单列举一下书中列出的客户端不在展开说了，后续我们将使用Java客户端来举例。

1.2 producer大概生产流程。

     Kafka生产端可以想象成一个工厂，有两批工人一个代表生产消息线程，一个代表负责将消息发送到Kafka的线程。生产消息线程就是我们的主线程，生产消息的线程会帮我们把消息放入一个缓冲区中，另外一个搬运线程负责将同一分区的多条消息封装进一个batch中，当batch满了后会自动帮我们实时的将消息放入Kafka中，实际并不会总是等消息满了才会发送，下面我们会说明。

1.3 producer的一些重要参数。

    下面的参数都是需要封装在一个Properties类中在创建Producer类时传入。

  1.3.1 bootstrp.server

    在Producer类中并没有这个参数的初始值，所以它是一个必须传入的参数。它是一组host:port键值对，多个键值对通过逗号分开。

  1.3.2 key.serializer和value.serializer

    这两个参数是指明key和value的序列化器，需要传入序列化器的全限定名。同样也是必须指明的。这两个参数可以在Producer构造器中指明，就可以不封装到properties中了。

  1.3.3 acks

    这个参数是一个很重要的参数。它有三个值
    当acks = 0时，Kafka可以有较高的吞吐量，同时带来的是消息并不能保证安全。当ack为0是producer只知道将消息发送给Kafka到底Kafka有没有收到，它并不关心。
    当acks = all或者-1时，producer发送消息后会等待leader节点将消息写入本地日志成功，而且也会等待leader节点的follower节点也成功写入本地日志才会返回。他可以保证消息的安全性，带来的也是吞吐量的减少。
    前面两个方案都是走极端的，所以一旦有这个问题时一般会采用中和的方法，所以acks还有一个值，那就是1。当acks = 1时，producer只会等待leader节点成功写入日志，至于follower节点的成功与否他并不关心。

  1.3.4 buffer.memory

    这个参数是缓冲区的大小，默认值是32M。这个参数需要根据消息量的大小来决定。如果生产消息的主线程的写入速率大于搬运线程往Kafka搬运的速率，这样肯定会造成缓冲区大小不够用，使得生产者专心搬运线程。如果一段时间后还是无法结局这个问题，那么producer就会抛出异常提醒用户人工处理。

  1.3.5 compression.type

    这个参数来决定消息是否进行压缩。压缩消息肯定会试系统降低网络IO的压力。从而提升整体的吞吐量，但是压缩需要耗费CPU。它的默认值为none,1.0.0版本Kafka支持三种压缩算法，分别为GZIP、Snappy、LZ4.

  1.3.6 retries

    这个参数控制当生产者发送消息失败了可以重试几次，默认值为0。书中建议这个的值大于0，因为可以很好地应对瞬间的错误。而且书中认为这种错的大部分都是leader的选举导致的，所以可以根据系统leader选举时间来决定另外一个参数retry.backoff.ms来设置重试的间隔避免频繁的重试给系统带来不必要的压力。
    重试可能带来两种问题消息的重复发送和消息乱序。具体原因下图贴出了书的原文。

  1.3.7 batch.size

    上面讲producer的机制时我们说了producer会将同一分区的多个消息封装到一个batch中统一发送，这个参数就指明的batch的大小。默认值为16KB，书中认为这个值是很保守的，所以在实际开发中可以适当调整这个参数的大小来提高吞吐量。当这个值大的时候势必会使内存的压力变大，小的时候也会使Kafka的吞吐量达不到最优，所以还需要根据场景来考虑最合适的值。

  1.3.8 linger.ms

    上面讲producer机制是我们说可以bacth并没有满，但是还是发给了Kafka。这个参数就是来控制消息延时的。当时间到时不会关心batch是否满了。它的默认值是0，即立刻发出消息。我们肯定更希望消息尽快发给Kafka，但是这样会带来更多的网络消耗降低我们producer的吞吐量，所以具体这个值具体是多少我们还是需要根据实际情况来决定到底是多少。

  1.3.9 max.request.size

    这个参数来控制每次请求最大的消息大小。默认值为1M，但是这个值显然有点小，所以可以适当去调大这个参数。

  1.3.10 request.timeout.ms

    这个参数来控制一个请求的超时时间，默认值为30s，即producer发送给Kafka一个请求后，30s还没收到Kafka的回应，那么producer就会抛出异常。一般这个默认值是够用的，但是如果你的producer负载很大那么可以酌情去增大一点。以免造成不必要的资源浪费。

 总结

    文章中简单讲了一下Kafka producer的一些机制以及一些重要的参数的配置建议。没有任何一种配置可以适用所有场景的，所以还是需要根据业务和硬件等实际情况去考量。谢谢观看。