一个应用程序在很多情况下需要往Kafka写入消息：记录用户的活动（用于审计和分析），记录度量指标，保存日志消息，记录智能家电的信息，与其他应用程序进行异步通信，缓冲即将写入到数据库的数据，等等。
多样的使用场景意味着多样的需求：是否每个消息都很重要？是否允许丢失一小部分消息？偶尔出现重复消息是否可以接受？是否有严格的延迟和吞吐量要求？
不同的使用场景对生产者API的使用和配置会有直接的影响。
消息发送过程
首先创建一个ProducerRecord对象。
ProducerRecord对象包含目标主题和要发送的内容。
可以指定键或分区。
如果有键的话，将键序列化成字节数组，以便在网络上传输。同样地，要发送的内容，即值，也需要序列化成字节数组。
接下来，数据被传给分区器。
如果之前在ProducerRecord对象里指定了分区，那么分区器就不会再做任何事情，直接把指定的分区返回。
如果没有指定分区，那么分区器会根据ProducerRecord对象的键来选择一个分区。
选好分区后，生产者就知道该往哪个主题和分区发送记录了。
紧接着，这条记录被添加到了一个记录批次里。
这个批次里的所有消息都会被发送到相同的主题和分区上。
有一个独立的线程负责把这些记录批次发送到相应的broker上。
服务器在收到这些消息时会返回一个相应。
如果消息成功写入Kafka，就返回一个RecordMetaData对象，它包含了主题和分区信息，以及记录在分区里的偏移量。
如果写入失败，则会返回一个错误。
生产者在接收到错误之后会尝试重新发送消息，几次之后如果还是失败，就返回错误信息。
发送消息的方式
生产者可以使用单个消费者单个线程，也可以使用单个消费者多个线程。
或者增加消费者。
发送并忘记
producer.send(record)
我们把消息发送给服务器，但并不关心它是否正常到达。
大多数情况下，消息会正常到达， 因为Kafka是高可用的，而且生产者会自动尝试重发。
不过这种方式有时候也会丢失一些消息。
同步发送
producer.send(record).get()
如果服务器返回错误，get()方法会抛出异常。如果没有发生错误，我们会的到一个RecordMetadata对象，可以用它获取消息的偏移量。
我们使用send()发送消息，它会返回一个Future对象，调用get()方法进行等待。就可以知道消息是否发送成功。
异步发送
producer.send(record, ? extends org.apache.kafka.clients.producer.Callback)
Callback接口只有一个onCompletion方法。
如果Kafka返回一个错误，onCompletion方法会抛出一个非空异常。
我们调用send()方法，并指定一个回调函数，服务器在返回响应时调用该函数。
KafkaProducer异常
KafkaProducer一般会发生两类错误。
其中一类是可重试错误。这类错误通过重发消息来解决。比如连接错误，无主错误等。KafkaProducer可以被配置成自动测试，如果在多次重试后仍无法解决问题，应用程序会收到一个重试异常。
另一类错误无法通过重试解决，比如消息太大异常。对于这类错误，KafkaProducer不会进行任何重试，直接抛出异常。
生产者配置
org.apache.kafka.clients.producer.ProducerConfig
bootstrap.servers
该属性指定broker的地址清单，地址的格式为host:port。
清单不需要包含所有的broker地址，生产者会从给定的broker里查找到其他broker的信息。
建议至少要提供两个broker的信息，一旦其中一个单机，生产者仍然能够连接到集群上。
该参数为必选参数。
key.serializer
broker希望接收到的消息的键和值都是字节数组。
生产者接口允许使用参数化类型，因此可以把Java对象作为键和值发送给broker。这样的代码具有良好的可读性，不过生产者需要知道如何把这些Java对象转化成字节数组。
key。serializer必须被设置为一个实现了org.apache.kafka.common.serialization.Serializer接口的类，生产者会使用这个类把键对象序列化成字节数组。
Kafka客户端默认提供了ByteArraySerializer，StringSerializer和IntegerSerializer。
该参数必须设置，即使只发送值。
value.serializer
用指定的类将值序列化。
该参数必须设置。
acks
acks参数指定了必须要有多少个分区副本接收到消息，生产者才会认为消息写入是陈宫的。
这个参数对消息丢失的可能性有重要影响。
该参数有如下选项：
acks=0.生产者在写入消息之前不会等待任何来自服务器的响应。所以该值可以以网络能够支持的最大速度发送消息，从而达到很高的吞吐量。
acks=1.只要集群的首领结点接收到消息，生产者就会收到一个来自服务器的成功响应。如果首领结点发生崩溃，一个没有收到消息的结点称为新首领，消息将丢失。
acks=all.只有当所有参与复制的结点全部接收到消息时，生产者才会收到一个来自服务器的成功响应。这种模式是最安全的，但是延迟最高。
buffer.memory
该参数用来设置生产者内存缓冲区的大小，生产者用它缓冲要发送到服务器的消息。
如果应用程序发送消息的速度超过发送到服务器的速度，会导致生产者空间不足。这个时候，send()方法调用要么被阻塞，要么抛出异常，取决于如何设置max.block.ms参数。
compression.type
默认情况下，消息发送时不会被压缩。
使用压缩可以降低网络传输开销和存储开销，这也往往是Kafka发送消息的瓶颈所在。
该参数指定了消息被发送给broker之前使用哪一种压缩算法进行压缩，可以设置为：
snappy -- 占用较少的cpu，提供较好的性能和相当可观的压缩比
gzip -- 占用较多的cpu，提供更高的压缩比
lz4
retries
生产者从服务器收到的错误有可能是临时性的错误（比如分区找不到首领）。
retries参数的值决定了生产者可以重发消息的次数，如果达到这个次数，生产者会放弃重试并返回错误。
默认情况下，生产者会在每次重试之间等待100ms，不过可以通过retry.backoff.ms参数来改变这个时间间隔。
一般情况下，因为生产者会自动进行重试，所以就没必要在代码逻辑里处理那些可重试的错误。只需要处理那些不可重试的错误或重试次数超出上限的情况。
batch.size
该参数指定了一个批次可以使用的内存大小，按照字节计算（而不是消息个数）。
当有多个消息需要被发送到同一个分区时，生产者会把它们放到同一个批次里。
当批次被填满，批次里的所有消息会被发送出去。
不过生产者并不一定都会等到批次被填满时才发送（见下一个参数linger.ms）。
所以，就算把批次大小设置的很大，也不会造成延迟，只是会占用更多的内存而已。
但如果设置的太小，因为生产者需要更频繁的发送消息，会增加一些额外的开销。
linger.ms
该参数指定了生产者在发送批次之前等待更多消息加入批次的时间。
KafkaProducer毁在批次填满或linger.ms达到上限时把批次发送出去。
默认情况下， 只要有可用的线程，生产者就会把消息发送出去，就算批次里只有一个消息。
把linger.ms设置成比0大的书，让生产者在发送批次之前等待一会儿，使更多的消息加入到这个批次。虽然这样会增加延迟，但也会提升吞吐量。
https://www.itread01.com/content/1524315728.html
只要滿足linger.ms和batch.size滿了就會激活sender線程來發送消息。
client.id
该参数可以使任意的字符串，服务器会用它来识别消息的来源，还可以用在日志和配额指标里。
max.in.flight.requests.per.connection
该参数指定了生产者在接收到服务器响应之前可以发送多少个消息。
它的值越高，就会占用越多的内存，不过也会提升吞吐量。
把它设为1可以保证消息时按照发送的顺序写入服务器，即使发生了重试。
timeout.ms
该参数制定了broker等待同步副本返回消息确认的时间，也acks的配置相匹配。
如果在指定时间内没有收到同步副本的确认，那么broker就会返回一个错误。
request.timeout.ms
该参数制定了生产者在发送数据时等待服务器返回响应的时间。
如果等待响应超时，那么生产者要么重试发送数据，要么返回一个错误。
medata.fetch.timeout.ms
该参数制定了生产者在获取元数据时等待服务器返回相应的时间。
max.block.ms
该参数制定了在调用send()方法或使用partitionsFor()方法获取元数据时生产者的阻塞时间。
当生产者的发送缓冲区已满，或者没有可用的元数据时，这些方法就会阻塞。在则色时间达到max.block.ms时，生产者会抛出超时异常。
max.request.size
该参数用于控制生产者发送的请求大小。
它可以指定能发送的单个消息的最大值，也可以指单个请求里所有消息总的大小。
另外，broke对可接收的消息最大值也有自己的限制（message.max.bytes），所以，两边的配置最好可以匹配，避免生产者发送的消息被broker拒绝。
receive.buffer.bytes
该参数指定了TCP socker接收数据包的缓冲区大小。
如果被设为-1，就使用操作系统的默认值。
如果生产者或消费者与broker处于不同的数据中心，那么可以适当增大这些值，因为跨数据中心的网络一般都有比较高的延迟和比较低的宽带。
send.buffer.bytes
该参数指定了TCP socker发送数据包的缓冲区大小。
如果被设为-1，就使用操作系统的默认值。
如果生产者或消费者与broker处于不同的数据中心，那么可以适当增大这些值，因为跨数据中心的网络一般都有比较高的延迟和比较低的宽带。
序列化器
创建一个生产者对象必须制定序列化器。
自定义序列化器
如果发送到Kafka的对象不是简单的字符串或整型，那么可以使用序列化框架来创建消息记录，如Avro,Thrift或Protobuf，或者自定义序列化器。
建议使用通用的序列化框架。
自定义序列化器需要实现org.apache.kafka.common.serialization.Serializer接口。
Avro
Apache Avro是一种与编程语言无关的序列化格式。
Avro数据通过与语言无关的schema来定义。
schema通过JSON来描述，数据被序列化成二进制文件或JSON文件，不过一般会使用二进制文件。
Avro在读写文件时需要用到schema，schema一般会被内嵌在数据文件里。
Avro有一个很有意思的特性，当负责写消息的应用程序使用的新的schema，负责读消息的应用程序可以继续处理消息而无需做任何改动，这个特性使得它特别适合用在像Kafka这样的消息系统上。
不过，有以下两个需要注意的地方：
用于写入数据和读取数据的schema必须是相互兼容的。
反序列化器需要用到用于写入数据的schema，即使它可能与用于读取数据的schema不一样。Avro数据文件里就包含了用于写入数据的schema，不过在Kafka里一般会将schema文件注册到注册表中。
在Kafka里使用Avro
Avro的数据文件里包含了整个schema，不过这样的开销是可接受的。
但是如果在每条Kafka记录里都嵌入schema，会让记录的大小成倍地增加。
通过schema注册表可以将schema保存在注册表中，然后在记录里引用schema的标识符。
分区
ProducerRecord对象包含了目标主题，键和值。
Kafka的消息是一个个键值对，ProducerRecord对象可以只包含目标主题和值，键可以设置为默认的null，不过大多数应用程序会用到键。
键有两个用途：
作为消息的附加信息
决定消息该被写到主题的哪个分区
如果键值为null，并且使用了默认的分区器，那么记录将被随机地发送到主体内各个可用的分区上。
分区器使用轮询算法将消息均匀地分布到各个分区上。
如果键不为空，并且使用了默认的分区器，那么Kafka会对键进行散列，然后根据散列值把消息映射到特定的分区上。
同一个键总是被映射到同一个分区上，所以在进行映射时，我们会使用主题所有的分区，而不仅仅是可用的分区。这也意味着，如果写入数据的分区时不可用的，那么就会发生错误。
只有在不改变主题分区数量的情况下， 键与分区之间的映射才能保持不变。
如果要使用键来映射分区，那么最好在创建主题的时候就把分区规划好，而且永远不要增加新分区。
自定义分区策略
实现org.apache.kafka.clients.producer.Partitioner接口
