生产者参数优化 · Hadoop2.x

1. **`bootstrap.servers`** 无需添加所有的集群地址，Kafka 会根据提供的地址发现其他的地址，但尽量多提供几个，以防提供的服务器关闭。 2. **`acks`** acks=0 如果设置为 0，那么生产者将不等待任何消息确认。消息将立刻添加到 socket 缓冲区并考虑发送。在这种情况下不能保障消息被服务器接收到。并且重试机制不会生效（因为客户端不知道故障了没有）。每个消息返回的 offset 始终设置为-1。 acks=1，这意味着 leader 写入消息到本地日志就立即响应，而不等待所有follower 应答。在这种情况下，如果响应消息之后但 follower 还未复制之前 leader立即故障，那么消息将会丢失。 acks=all 这意味着 leader 将等待所有副本同步后应答消息。此配置保障消息不会丢失（只要至少有一个同步的副本）。这是最强壮的可用性保障。等价于acks=-1。 3. **`buffer.memory`** 生产者用来缓存等待发送到服务器的消息的内存总字节数。如果消息发送比可传递到服务器的快，生产者将阻塞 max.block.ms 之后，抛出异常。此设置应该大致对应生产者将要使用的总内存，但不是硬约束，因为生产者所使用的所有内存都用于缓冲。一些额外的内存将用于压缩（如果启动压缩），以及用于保持发送中的请求。 首先要明确一点，那就是在内存缓冲里大量的消息会缓冲在里面，形成一个一个的 Batch，每个 Batch 里包含多条消息。然后 KafkaProducer 有一个 Sender线程会把多个 Batch 打包成一个 Request 发送到 Kafka 服务器上去。那么如果要是内存设置的太小，可能导致一个问题：消息快速的写入内存缓冲里面，但是Sender 线程来不及把 Request 发送到 Kafka 服务器。这样是不是会造成内存缓冲很快就被写满？一旦被写满，就会阻塞用户线程，不让继续往 Kafka 写消息了。 所以对于“buffer.memory”这个参数应该结合自己的实际情况来进行压测，你需要测算一下在生产环境，你的用户线程会以每秒多少消息的频率来写入内存缓冲。比如说每秒 300 条消息，那么你就需要压测一下，假设内存缓冲就 32MB，每秒写 300 条消息到内存缓冲，是否会经常把内存缓冲写满？经过这样的压测，你可以调试出来一个合理的内存大小。 4. **`batch.size`** 当多个消息要发送到相同分区的时，生产者尝试将消息批量打包在一起，以减少请求交互。这样有助于客户端和服务端的性能提升。该配置的默认批次大小（以字节为单位）：16384，即 16KB。不会打包大于此配置大小的消息，发送到broker 的请求将包含多个批次，每个分区一个，用于发送数据。较小的批次大小有可能降低吞吐量（批次大小为 0 则完全禁用批处理）。一个非常大的批次大小可能更浪费内存，因为我们会预先分配这个资源。比如说发送消息的频率就是每秒 300 条，那么如果 batch.size 调节到了 32KB，或者 64KB，也不会提升发送消息的整体吞吐量。 理论上来说，提升 batch 的大小，可以允许更多的数据缓冲在里面，那么一次 Request 发送出去的数据量就更多了，这样吞吐量可能会有所提升。但是也不能无限的大，过于大了之后，要是数据老是缓冲在 Batch 里迟迟不发送出去，那么岂不是你发送消息的延迟就会很高。比如说，一条消息进入了 Batch，但是要等待 5 秒钟 Batch 才凑满了 64KB，才能发送出去。那这条消息的延迟就是 5 秒钟。 所以需要在这里按照生产环境的发消息的速率，调节不同的 Batch 大小自己测试一下最终出去的吞吐量以及消息的延迟，设置一个最合理的参数。 5. **`compression.type`** 数据压缩的类型。默认为空（就是不压缩）。有效的值有 none，gzip，snappy, 或 lz4。压缩全部的数据批，因此批的效果也将影响压缩的比率（更多的批次意味着更好的压缩）。 6. **`retries`** 设置一个比零大的值，客户端如果发送失败则会重新发送。注意，这个重试功能和客户端在接到错误之后重新发送没什么不同。如果max.in.flight.requests.per.connection 没有设置为 1，有可能改变消息发送的顺序，因为如果 2 个批次发送到一个分区中，并第一个失败了并重试，但是第二个成功了，那么第二个批次将超过第一个。 `retries`和`retries.backoff.ms`决定了重试机制，也就是如果一个请求失败了可以重试几次，每次重试的间隔是多少毫秒。这个大家适当设置几次重试的机会，给一定的重试间隔即可，比如给 100ms 的重试间隔。 7. **`linger.ms`** 指逗留时间，这个逗留指的是消息不立即发送，而是逗留这个时间后一块发送。这个设置是比较有用的，有时候消息产生的要比能够发送的要快，这个参数完美的实现了一个人工的延迟，使得大批量可以聚合到一个 Batch 里一块发送，当 Batch 慢了的话，会忽略这个参数立即发送。默认值 : 0。 8. **`client.id`** 当发出请求时传递给服务器的 id 字符串。这样做的目的是允许服务器请求记录这个“逻辑应用名”，这样能够追踪请求的源，而不仅仅只是 ip:port。