Kafka作为分布式系统、异步消息系统等应用常用技术栈，是一个很受开发者欢迎的消息处理方案；在实践过程中，也总结出了一些较适用的实践经验。
建议1
了解分区的数据速率，以确保保留足够的空间；
建议2
除非有其他架构方面的需求，否则在消息生产时，请使用随机分区 ；如果按比例操作分区，分区处理速度很难掌控；理由如下：
(1) 高吞吐量分区的消费者将比同消费组中的其他消费者处理更多的消息，可能导致cpu和网络瓶颈。
(2) 为具有高速率的分区保留足够的Topic消息大小，导致跨其他分区的磁盘使用增加。
(3) 分区平衡更加复杂，如：一个“热”分区可能是同主题中另一个分区的权重的10倍。
建议3
针对消费者：
(1) kafka版本建议高于0.10
(2) 调整消费者套接字缓冲区大小以高速处理速度：receive.buffer.bytes,默认 64kB，当broker与消费者存在大的带宽延时时>10 Gbps建议 8 or 16 MB的缓存.如果<10Gbps建议1 MB. 或者设置该值为-1操作系统根据网络状况调整缓存大小，但是自动调节可能存在延迟，这对hot热数据分区可能有点无法忍受；
(3) 设计高吞吐的消费者：让消费者尽力而为达到最高处理性能，而非一次加载较大的、固定大小的消息导致频繁GC
(4) 避免过长的GC时间：导致zk会话超时、broker超时而进行消费组重平衡操作
建议4
针对生产者：
(1) 配置生产者等待ACK，具体设置acks=-1，避免消息丢失
(2) 配置重试，对应retries，默认3，对于不能容忍数据丢失的应用可以设置Integer.MAX_VALUE
(3) 调整缓存大小提高吞吐量，对应buffer.memory和batch.size参数，其中batch.size是分区级别的设置，该值取决于：生产者数据速率（消息的大小和数量）、要处理的分区数和可用内存量。
(4) 缓存并非越大越好，会无形中增加GC的耗时
(5) 统计生产者度量，例如生成的消息的数量、平均生成的消息大小和消耗的消息的数量；
建议5
针对broker：
(1) 针对Topic、日志压缩过程需占用内存、CPU等，调整log.cleaner.dedupe.buffer.size 和 log.cleaner.threads。如果broker抛出OutOfMeMyRebug异常，它将关闭并可能丢失数据。缓冲区大小和线程计数将取决于要清理的Topic分区的数量以及这些分区中消息的数据速率和键大小。监视日志清理器日志文件查找ERROR条目是检测日志清理器线程问题的比较可靠的方法
(2) 监控网络吞吐量，同时监控发送（TX）和接收（RX）以及磁盘I/O、磁盘空间和CPU使用
(3) 分配Leader在分布式分区中来均衡网络、磁盘、IO等的占用。Leader需要大量的网络I/O资源。例如，当使用复制因子3运行时，Leader必须接收分区数据，将两个副本发送到副本，再加上发送到许多消费者想要消费该数据，在网络I/O使用方面，作为领导者至少要比跟随者贵四倍。
(4) 不要忽视对同步复制（ISR）shrinks、under-replicated partitions、 unpreferred leaders的监视。单个分区的频繁ISR shrinks可以指示该分区的数据速率超过领导者为消费者线程和复制线程服务的能力。
(5) 优化Log4j ，避免过多日志占用磁盘开销
(6) 禁用自动主题创建或者建立清除未使用主题策略。元数据尽量还是自己管理，不要让集群管理。
(7) 对于持续高吞吐量的brokers提供足够的内存避免从磁盘子系统读取资源。这意味着消费者需要跟上生产者速度，避免消息写磁盘、读磁盘带来的异步处理开销。落后的消费者会迫使broker从磁盘读取。
(8) 对于高吞吐量服务级别的集群，考虑将主题隔离到broker的子集。
(9) 尽量避免消息格式的转换，会给broker带来额外的负载。
