kakfa 生产者参数
比较重要的几个参数下面列出来出来，下面将详细的说明这些参数的含义：
- bootstrap.servers： broker的地址
- key.serializer：关键字的序列化方式
- value.serializer：消息值的序列化方式
- acks：指定必须要有多少个分区的副本接收到该消息，服务端才会向生产者发送响应，可选值为：0,1,2，…，all
- buffer.memory：生产者的内存缓冲区大小。如果生产者发送消息的速度 > 消息发送到kafka的速度，那么消息就会在缓冲区堆积，导致缓冲区不足。这个时候，send()方法要么阻塞，要么抛出异常。
- max.block.ms：表示send()方法在抛出异常之前可以阻塞多久的时间，默认是60s
- compression.type：消息在发往kafka之前可以进行压缩处理，以此来降低存储开销和网络带宽。默认值是null，可选的压缩算法有snappy、gzip和lz4
- retries：生产者向kafka发送消息可能会发生错误，有的是临时性的错误，比如网络突然阻塞了一会儿，有的不是临时的错误，比如“消息太大了”，对于出现的临时错误，可以通过重试机制来重新发送
- retry.backoff.ms：每次重试之间间隔的时间，第一次失败了，那么休息一会再重试，休息多久，可以通过这个参数来调节
- batch.size：生产者在发送消息时，可以将即将发往同一个分区的消息放在一个批次里，然后将这个批次整体进行发送，这样可以节约网络带宽，提升性能。该参数就是用来规约一个批次的大小的。但是生产者并不是说要等到一个批次装满之后，才会发送，不是这样的，有时候半满，甚至只有一个消息的时候，也可能会发送，具体怎么选择，我们不知道，但是不是说非要等装满才发。因此，如果把该参数调的比较大的话，是不会造成消息发送延迟的，但是会占用比较大的内存。但是如果设置的太小，会造成消息发送次数增加，会有额外的IO开销
- linger.ms：生产者在发送一个批次之前，可以适当的等一小会，这样可以让更多的消息加入到该批次。这样会造成延时增加，但是降低了IO开销，增加了吞吐量
- client.id：服务器用来标志消息的来源，是一个任意的字符串
- max.in.flight.requests.per.connection：一个消息发送给kafka集群，在收到服务端的响应之前的这段时间里，生产者还可以发n-1个消息。这个参数配置retries，可以保证消息的顺序，后面会介绍
- request.timeout.ms：生产者在发送消息之后，到收到服务端响应时，等待的时间限制
- max.request.size：生产者发送消息的大小。可以是一个消息的大小，也可以发送的一个批次的消息大小
- receive.buffer.bytes和send.buffer.bytes：tcp socket接收和发送消息的缓冲区大小，其实指的就是ByteBuffer的大小
Kafka的顺序保证
Kafka可以保证消息在一个分区里是有序的存放的，即生产者如果按照某个顺序发送消息，那么broker也会按照这个顺序来将消息写入到分区，消费者也会按照这个顺序来读取消息。但是在生产环境中，retries参数的设置一般都是非零的整数，比如retries=3，那么当消息1发送失败的时候，在执行重试之前，消息2被发送了，并且没有错误，那么消息2将会先于消息1到达broker，这样的话，消息就顺便不对了。那么在Kafka里，这个问题是如何保证顺序性的呢？
上面我们提到一个参数，叫做max.in.flight.requests.per.connection，这个参数可以控制在生产者收到响应之前，还可以发送多少个消息。如果把这个参数设置成1，那么即使发生了错误重试，那么消息2，也没有机会在消息1之前发送，而是必须等到消息1的响应被收到之后，消息2才可以发送。
