Kafka 真是一个异常稳定的组件，服务器上我们部署了 kafka_2.11-1.0.1 版本的 kafka 除了几次计算时间太长触发了 rebalance 以外，基本没有处理过什么奇怪的问题。
但是还是感觉 Kafka 的配置非常全面非常多，也非常容易把人搞懵逼。有时候看官方文档也就是一句话，经常搞得人不明所以。所以想仔细看看 然后总结一下。
读取配置 server.properties 查看 「Broker」相关配置
1. 设置这个 broker 节点的 id 值
broker.id=02. 可以配置可以访问 kafka 的对应端口号和 hostname
port=9092
host.name=10.171.97.1这里需要注意，能访问 kafka 还支持其他类型的监听器，比如这种方式
这里的 PLAINTEXT 表示明文传输
# The address the socket server listens on. It will get the value returned from
# java.net.InetAddress.getCanonicalHostName() if not configured.
# FORMAT:
# listeners = listener_name://host_name:port
# EXAMPLE:
# listeners = PLAINTEXT://your.host.name:9092
#listeners=PLAINTEXT://:9092
# Hostname and port the broker will advertise to producers and consumers. If not set,
# it uses the value for "listeners" if configured. Otherwise, it will use the value
# returned from java.net.InetAddress.getCanonicalHostName().
#advertised.listeners=PLAINTEXT://your.host.name:90923. 配置 kafka broker 的集群存储信息，这里有个 log basics 的区域。这一块应该都等待你的配置不会有默认值的，
b# A comma seperated list of directories under which to store log files
log.dirs=/opt/kafka/kafka_2.11-1.0.1/logs
# The default number of log partitions per topic. More partitions allow greater
# parallelism for consumption, but this will also result in more files across
# the brokers.
num.partitions=10这里第一个参数是值 kafka 生产数据的日志放在哪个路径。
第二个参数就是创建 topic 的时候默认生成几个 partitions.
log.dirs 这个 s 就代表着他可以被设置多个路径存储日志，这一点非常关键和重要。我们可以在这个参数位置设置上多个路径来提升吞吐量。比如
log.dirs=/opt/kafka/kafka_2.11-1.0.1/logs,/opt/kafka/kafka_2.11-1.0.1/logs1,/opt/kafka/kafka_2.11-1.0.1/logs2这种配置方法似乎在 1.1版本之后还引入了故障转移机制(failover) 但是我没有尝试过，在这里记录一下之后有时间仔细调研一下。
4. 下面是跟 zookeeper 通讯需要用到的配置。
############################# Zookeeper #############################
# Zookeeper connection string (see zookeeper docs for details).
# This is a comma separated host:port pairs, each corresponding to a zk
# server. e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002".
# You can also append an optional chroot string to the urls to specify the
# root directory for all kafka znodes.
zookeeper.connect=10.171.97.1:2181,10.163.13.219:2181,10.170.249.122:2181
# Timeout in ms for connecting to zookeeper
zookeeper.connection.timeout.ms=6000zookeeper.connect 是配置连接 zookeeper 的地址，因为 zookeeper 通常是集群，所以同样可以使用逗号分隔配置多个地址和端口。
zookeeper.connection.timeout.ms 是配置连接 zk 的超时时间
这里注意，所有 ip:port 都可以被更换为 hostname:port 这没什么问题。也有很多人推荐使用 host:port 这种写法，我觉得不写错应该都没啥问题- -
5. topic 相关的部分
delete.topic.enable=true
auto.create.topics.enable=false
unclean.leader.election.enable=false
auto.leader.rebalance.enable=true5.1. 参数是是否允许可以删除对应的 topic 。这个默认是 False 可以设置打开。因为有时候我们是真的需要删除这个 topic ！！！
5.2. 自动创建 topics 开启。这个玩意我建议不开，开启就意味着随便来个客户端接上一个没有的 topic 也会被自动创建上，看上去很方便。如果有不那么熟悉的队友，你就知道这个还是关掉吧。
5.3. 允许除开 leader 副本之外的副本成为 leader。成为 leader 副本的条件就是这个副本是跟上最新的副本的而且 lag 少。但是当他们都挂了之后，设置了这个参数就运行没有跟上的副本成为 leader 副本，不可避免的会产生一些数据丢失。
5.4. 开启这个参数会定期进行 leader 的重新选举。如果我们出现了机器的崩溃可能会造成我们的 副本 leader 进行偏移形成 leader 倾斜。比如我们本来是 0 1 2 三台机器上均衡的分布着各副本的 leader 突然 2 挂了 那么 2 是 leader 那一部分就会向 0 和 1 节点的 isr 副本进行转移。这样当 2重新活过来之后 他上面就没 leader 了。如果我们不再均衡一下 leader 他就一直维持这样了。
因为 kafka 是只有 leader 会对外进行服务的，这样压力就偏移了。开启这个参数我们将可以又重新平衡 leader ，让其恢复到初始状态。
6. 日志数据保留相关的参数
############################# Log Retention Policy #############################
# The following configurations control the disposal of log segments. The policy can
# be set to delete segments after a period of time, or after a given size has accumulated.
# A segment will be deleted whenever *either* of these criteria are met. Deletion always happens
# from the end of the log.
# The minimum age of a log file to be eligible for deletion due to age
log.retention.hours=168
# A size-based retention policy for logs. Segments are pruned from the log unless the remaining
# segments drop below log.retention.bytes. Functions independently of log.retention.hours.
#log.retention.bytes=1073741824
# The maximum size of a log segment file. When this size is reached a new log segment will be created.
log.segment.bytes=1073741824
# The interval at which log segments are checked to see if they can be deleted according
# to the retention policies
log.retention.check.interval.ms=300000
message.max.bytes6.1. log.retention.hours 设置一个日志保留时间，这个除了 hours 可选还有[minutes|ms] 可选比如 log.retention.ms ，感觉这个小时就差不多了吧 默认 168个小时 7天。
6.2. log.retention.bytes 我感觉设置了时间没必要控制大小，这个默认是一个分区一个 G 数据，超过了会滚动删除。如果我有10个 partitions ，就一共可以存储 10G 数据。
下面图片是一个 partition 里的情况。
6.3. log.segment.bytes 这个是设置消息片最大片大小 设置 1g 1g应该够用了也就是到达一 g 之后会切日志并且等待过期。
6.4. log.retention.check.interval.ms 这个是设置多久检查一下是否符合以上配置的间隔时间。
6.5 message.max.bytes 消息默认是 1M 如果生产者尝试发送的消息超过这个大小，不仅消息不会被接收，还会收到 broker 返回的错误消息。跟其他与字节相关的配置参数一样，该参数指的是压缩后的消息大小，也就是说，只要压缩后的消息小于 mesage.max.bytes，那么消息的实际大小可以大于这个值这个值对性能有显著的影响。
7. 客户端生产者参数
7.1 max_in_flight_requests_per_connection 设置成 1 可以保证在有 retry 的情况下也能在一个 partitions 里面进行顺序发送。
7.2 retries 重试次数，如果不设置默认为 0 ，设置了在默认 max_in_flight_requests_per_connection == 5 的情况下可能因为重试机制而在单个 partitions 里乱序。
7.3 delivery.timeout.ms kafka-python 里还有一个没有支持的 KIP-91 参数，这个参数用于设置发送传输以及重试消息的最大时间。超过 retries 次数和超过这个时间都会跳过该消息。默认是 120s
Reference:
https://matt33.com/2017/09/10/produccer-end/ Kafka 源码解析之 Producer 单 Partition 顺序性实现及配置说明
https://cwiki.apache.org/confluence/display/KAFKA/An+analysis+of+the+impact+of+max.in.flight.requests.per.connection+and+acks+on+Producer+performance An analysis of the impact of max.in.flight.requests.per.connection and acks on Producer performance
Kafka 0.11版本新功能介绍 —— 空消费组延时rebalance
