kafka权威指南阅读笔记（二）

1.kafka生产者组件图

我们从创建 一 个 ProducerRecord 对象开始， ProducerRecord 对象需要包含目标主题和要发 送的内容。我们还可以指定键或分区。在发送 ProducerRecord对象时，生产者要先把键和 值对象序列化成字节数组，这样它们才 能够在网络上传输 。

接下来，数据被传给分区器。如果之前在 Produc巳rR巳cord对象里指定了分区，那么分区器 就不会再做任何事情，直接把指定的分区返回。如果没有指定分区 ，那么分区器会根据 ProducerRecord对象的键来选择一个分区 。选好分区以后 ，生产者就知道该往哪个主题和 分区发送这条记录了。紧接着，这条记录被添加到一个记录批次里，这个批次里的所有消 息会被发送到相同的主题和分区上。有一个独立的线程负责把这些记录批次发送到相应的 broker 上。

服务器在收到这些消息时会返回一个响应。如果消息成 功写入 Kafka，就返回一个 RecordMetaData 对象，它包含了主题和分区信息，以及记录在分区里的偏移量。如果写入失败， 则会返回一个错误 。生产者在收到错误之后会尝试重新发送消息，几次之后如果还 是失败，就返回错误信息。

2.生产者发送消息

（1）同步发送消息

 ProducerRecord<String,String> record = new ProducerRecord<>("","","");
    try{
producer.send(record).get();
     }
     catch(Exception e)
{
e.printSatckTrace();
}

(2)异步发送消息

private class DemoProducerCallback implements Callback
    {
        @Override
        public void onCompletion(RecordMetadata recordMetadata,Exception e)
        {
            if(e != null)
            {
                e.printStackTrace();
            }
        }
    }
    ProducerRecord<String,String> record = new ProducerRecord<>("","","");
    producer.send(record,new DemoProducerCallback());

3.生产者的配置

1. acks

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

2. buffer.memory

该参数用来设置生产者内存缓冲区的大小，生产者用它缓冲要发送到服务器的消息。如果 应用程序发送消息的速度超过发送到服务器的速度，会导致生产者空间不足。这个时候， send()方法调用要么被阻塞，要么抛出异常，取决于如何设置 block.on.buffer.fulll 参数 (在0.9.0.0版本里被替换成了 l'lax.block.ms，表示在抛出异常之前可以阻塞一段时间)。

3. compression.type

默认情 况下，消息发送时不会被压缩。该参数可以设置为 snappy、 gzi.p 或 lz4，它指定了 消息被发送给 broker之前使用哪一种压缩算也进行压缩。 snappy 压缩算怯由 Googl巳发明， 它占用较少 的 CPU，却能提供较好的性能和相当可观的压缩比，如果 比较关注性能和网 络带宽，可以使用这种算告。 gzip压缩算蓓一般会占用较多的 CPU，但会提供更高的压缩 比，所以如果网络带宽比较有限，可以使用这种算法。使用压缩可以降低网络传输开销和 存储开销，而这往往是向 Kafka发送消息的瓶颈所在。

4. retries

生产者从服务器收到的错误有可能是临时性的错误(比如分区找不到首领)。在这种情况 下， retries参数的值决定了生产者可以重发消息的次数，如果达到这个次数，生产者会 放弃重试并返回错民。默认情况下，生产者会在每次重试之间等待 l00ms，不过可以通过 retry.backoff.ms 参数来改变这个时间间隔。建议在设置重试次数和重试时间间隔之前， 先测试一下恢复一个崩愤节点需要多少时间(比如所有分区选举出首领需要多长时间)， 让总的重试时间比 Kafka集群从崩愤中恢复的时间长，否则生产者会过早地放弃重试。不 过有些错误不是临时性错误，没办怯通过重试来解决(比如“悄息太大”错误)。一般情 况下，因为生产者会自动进行重试，所以就没必要在代码逻辑里处理那些可重试的错误。 你只需要处理那些不可重试的错误或重试次数超出上限的情况。

5. batch.size

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

6. linger.ms

该参数指定了生产者在发送 批次之前等待更多消息加入批次的时间 。 KafkaProducer 会在 批次填满或linger.ms达到上限时把批次发送出去。默认情况下，只要有可用的线程， 生 产者就会把消息发送出去，就算批次里只有一个消息。把 linger.ms设置成比 0大的数， 让生产者在发送 批次之前等待 一会 儿，使更多的消息加入到这个批次 。虽然这样会增加延 迟，但也会提升吞吐量(因为一次性发送更多的消息，每个消息的开销就变小了)。

7. client.id 该参数可以是任意的字符串，服务器会用它来识别消息的来橱，还可以用在日志和配额指

标里。

8. max.in.flight.requests.per.connection

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

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

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

10. max.block.ms

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

11 . max.request.size

该参数用于控制生产者发送的请求大小。它可以指能发送的单个消息的最大值，也可以指 单个请求里所有消息总的大小。例如，假设这个值为 lMB，那么可以发送的单个最大消 息为 lMB，或者生产者可以在单个请求里发送一个批次，该批次包含了 1000个消息，每 个消息大小为 1KB 。另外， broker对可接收的消息最大值也有自己的限制( message.max. bytes)，所以两边的配置最好可以匹配，避免生产者发送的消息被 broker拒绝 。

12. receive.buffer.bytes 和 send.bu仔er.bytes

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