1.Broker端配置详解
1.1 必配参数1.2 监听器相关参数1.3 主题相关参数1.4 线程相关参数1.5 压缩相关参数1.6 ZooKeeper相关参数1.7 重平衡与选举相关参数1.8 日志刷写相关参数1.9 日志保留相关参数1.10 日志滚动切片相关参数1.11 元数据相关参数1.12 副本相关参数1.13 offset相关参数1.14 消息相关参数 2.Topic级别配置详解
2.1 日志清理压缩相关参数2.2 日志刷写相关参数2.3 索引相关参数2.4 消息、副本与选举相关参数2.5 日志保留与滚动相关参数 3.Producer端配置详解
3,1 序列化、分区器、拦截器相关参数3.2 集群地址与压缩相关参数3.3 批处理相关参数3.4 TCP缓冲相关参数3.5 消息有序性相关参数3.6 事务相关参数 4.Consumer端配置详解
4,1 必配参数4.2 反序列化、拦截器相关参数4.3 自动提交offset参数4.4 拉取数据相关参数4.5 分区分配策略参数4.6 TCP缓冲及其他参数
1.Broker端配置详解 1.1 必配参数 1.2 监听器相关参数 1.3 主题相关参数 1.4 线程相关参数 1.5 压缩相关参数生产中，一般Kafka会配置压缩以减少磁盘占用。
附：Facebook Zstandard官网提供的压缩算法对比结果：
ZK相关的参数一般不做修改。默认即可。
1.7 重平衡与选举相关参数重平衡相关参数需要根据实际需求进行调整，原理类似于HDFS中的重平衡。
1.8 日志刷写相关参数在Linux系统中，当我们把数据写入文件系统之后，其实数据在操作系统的pagecache里面，并没有刷到磁盘上。如果操作系统挂了，数据就丢失了。一方面，应用程序可以调用fsync这个系统调用来强制刷盘，另一方面，操作系统有后台线程，定时刷盘。频繁调用fsync会影响性能，需要在性能和可靠性之间进行权衡。实际上，官方不建议通过上述的三个参数来强制写盘，认为数据的可靠性通过replica来保证，而强制flush数据到磁盘会对整体性能产生影响。
Kafka的持久性并非要求同步数据到磁盘，因为问题节点都是从副本中恢复数据。这样刷盘依赖操作系统及Kafka的后台刷盘机制。这样的好处是：无需调优、高吞吐量、低延时和可全量恢复。
操作系统一般默认30s刷盘一次。
1.9 日志保留相关参数日志保留相关参数需要根据具体的生产实际及磁盘容量与数据量进行调整。
1.10 日志滚动切片相关参数日志滚动与切片参数建议根据生产实际进行调整。
1.11 元数据相关参数元数据相关参数一般不做调整。
1.12 副本相关参数副本相关参数一般不做调整。
1.13 offset相关参数offset内部主题相关参数，一般保持默认即可。
1.14 消息相关参数 2.Topic级别配置详解topic级别的参数，一般都在broker中对应有默认配置，但是也可以对单独的topic进行设置，可以在topic创建之初使用–config来进行指定，也可以在创建完成之后再进行修改。
以下是比较重要的topic级别的参数配置。
2.1 日志清理压缩相关参数 2.2 日志刷写相关参数 2.3 索引相关参数 2.4 消息、副本与选举相关参数 2.5 日志保留与滚动相关参数 3.Producer端配置详解Producer负责向服务器发送数据，在实际生产中，更多的是使用API作为Producer端进行数据发送。
以下是Producer端中比较重要的配置参数。
3,1 序列化、分区器、拦截器相关参数 3.2 集群地址与压缩相关参数 3.3 批处理相关参数 3.4 TCP缓冲相关参数 3.5 消息有序性相关参数 3.6 事务相关参数 4.Consumer端配置详解Consumer对数据进行消费，一般通过流处理框架对Kafka中的数据进行消费处理，因此，Consumer端是否消费正常对于数据处理显得尤为重要。
以下是Consumer端的重要参数。
4,1 必配参数 4.2 反序列化、拦截器相关参数 4.3 自动提交offset参数 4.4 拉取数据相关参数 4.5 分区分配策略参数 4.6 TCP缓冲及其他参数
