来源作者：kaleidoscopic
Apache Kafka 是一款流行的分散式资料流平台，它已经广泛地被诸如 New Relic（资料智慧平台）、Uber、Square（移动支付公司）等大型公司用来构建可扩充套件的、高吞吐量的、且高可靠的实时资料流系统。
例如，在 New Relic 的生产环境中 ， Kafka 群集每秒能够处理超过 1500 万条讯息，而且其资料聚合率接近 1Tbps。
可见，Kafka 大幅简化了对于资料流的处理，因此它也获得了众多应用开发人员和资料管理专家的青睐。
然而，在大型系统中 Kafka 的应用会比较复杂。 如果您的 Consumers 无法跟上资料流的话，各种讯息往往在未被检视之前就已经消失掉了。
同时，它在自动化资料保留方面的限制， 高流量的释出+订阅（publish-subscribe，pub/sub）模式等，可能都会影响到您系统的效能 。
可以毫不夸张地说， 如果那些存放着资料流的系统无法按需扩容、或稳定性不可靠的话，估计您经常会寝食难安 。
为了减少上述复杂性，我在此分享 New Relic 公司为 Kafka 丛集在应对高吞吐量方面的 20 项最佳优化实践 。
我将从如下四个方面进行展开：
1、Partitions（分割槽） 2、Consumers（消费者） 3、Producers（生产者） 4、Brokers（代理）
要了解最佳优化实践需先熟悉如下 “关键术语”
Message（讯息）
Kafka 中的一条记录或资料单位。 每条讯息都有一个键和对应的一个值，有时还会有可选的讯息头。
Producer（生产者）
Producer 将讯息释出到 Kafka 的 topics 上。 Producer 决定向 topic 分割槽的释出方式，如： 轮询的随机方法、或基于讯息键（key）的分割槽算法。
Broker（代理）
Kafka 以分散式系统或丛集的方式执行。 那么群集中的每个节点称为一个 Broker。
Topic（主题）
Topic 是那些被发布的资料记录或讯息的一种类别。 消费者通过订阅Topic，来读取写给它们的资料。
Topic Partition（主题分割槽）
不同的 Topic 被分为不同的分割槽，而每一条讯息都会被分配一个 Offset，通常每个分割槽都会被复制至少一到两次。
每个分割槽都有一个 Leader 和存放在各个 Follower 上的一到多个副本（即： 资料的副本），此法可防止某个 Broker 的失效。
群集中的所有 Broker 都可以作为 Leader 和 Follower，但是一个 Broker 最多只能有一个 Topic Partition 的副本。 Leader 可被用来进行所有的读写操作。
Offset（偏移量）
单个分割槽中的每一条讯息都被分配一个 Offset，它是一个单调递增的整型数，可用来作为分割槽中讯息的唯一识别符号。
Consumer（消费者）
Consumer 通过订阅 Topic partition，来读取 Kafka 的各种 Topic 讯息。 然后，消费类应用处理会收到讯息，以完成指定的工作。
Consumer group（消费组）
Consumer 可以按照 Consumer group 进行逻辑划分。 Topic Partition 被均衡地分配给组中的所有 Consumers。
因此，在同一个 Consumer group 中，所有的 Consumer 都以负载均衡的方式运作 。整编：微信公众号，搜云库技术团队，ID：souyunku
换言之，同一组中的每一个 Consumer 都能看到每一条讯息。 如果某个 Consumer 处于“离线”状态的话，那么该分割槽将会被分配给同组中的另一个 Consumer。 这就是所谓的“再均衡（rebalance）”。
当然，如果组中的 Consumer 多于分割槽数，则某些 Consumer 将会处于闲置的状态。
相反，如果组中的 Consumer 少于分割槽数，则某些 Consumer 会获得来自一个以上分割槽的讯息。
Lag（延迟）
当 Consumer 的速度跟不上讯息的产生速度时，Consumer 就会因为无法从分割槽中读取讯息，而产生延迟。
延迟表示为分割槽头后面的 Offset 数量。 从延迟状态（到“追赶上来”）恢复正常所需要的时间，取决于 Consumer 每秒能够应对的讯息速度。
其公式如下： time = messages / (consume rate per second - produce rate per second)
针对 Partitions 的最佳实践
以下是 Kafka 的 20 项最佳优化实践
让你的 Kafka 飞起来
1、了解分割槽的资料速率，以确保提供合适的资料储存空间
此处所谓“分割槽的资料速率”是指资料的生成速率。 换言之，它是由“平均讯息大小”乘以“每秒讯息数”得出的资料速率决定了在给定时间内，所能保证的资料储存空间的大小（以字节为单位）。
如果您不知道资料速率的话，则无法正确地计算出满足基于给定时间跨度的资料，所需要储存的空间大小。
同时，资料速率也能够标识出单个 Consumer 在不产生延时的情况下，所需要支援的最低效能值。
2、除非您有其他架构上的需要，否则在写 Topic 时请使用随机分割槽
在您进行大型操作时，各个分割槽在资料速率上的参差不齐是非常难以管理的。
其原因来自于如下三个方面：
首先，“热”（有较高吞吐量）分割槽上的 Consumer 势必会比同组中的其他 Consumer 处理更多的讯息，因此很可能会导致出现在处理上和网络上的瓶颈。
其次，那些为具有最高资料速率的分割槽，所配置的最大保留空间，会导致Topic 中其他分割槽的磁盘使用量也做相应地增长。
第三，根据分割槽的 Leader 关系所实施的最佳均衡方案，比简单地将 Leader 关系分散到所有 Broker 上，要更为复杂。 在同一 Topic 中，“热”分割槽会“承载”10 倍于其他分割槽的权重。
有关 Topic Partition 的使用，可以参阅《Kafka Topic Partition的各种有效策略》https://blog.newrelic.com/engineering/effective-strategies-kafka-topic-partitioning/。
针对 Consumers 的最佳实践
3、如果 Consumers 执行的是比 Kafka 0.10 还要旧的版本，那么请马上升级
在 0.8.x 版中，Consumer 使用 Apache ZooKeeper 来协调 Consumer group，而许多已知的 Bug 会导致其长期处于再均衡状态，或是直接导致再均衡算法的失败（我们称之为“再均衡风暴”）。
因此在再均衡期间，一个或多个分割槽会被分配给同一组中的每个 Consumer。
而在再均衡风暴中，分割槽的所有权会持续在各个 Consumers 之间流转，这反而阻碍了任何一个 Consumer 去真正获取分割槽的所有权。
4、调优 Consumer 的套接字缓冲区（socket buffers），以应对资料的高速流入
在 Kafka 的 0.10.x 版本中，引数 receive.buffer.bytes 的预设值为 64KB。 而在 Kafka 的 0.8.x 版本中，引数 socket.receive.buffer.bytes 的预设值为 100KB。
这两个预设值对于高吞吐量的环境而言都太小了，特别是如果 Broker 和 Consumer 之间的网络带宽延迟积（bandwidth-delay product）大于局域网（local areanetwork，LAN）时。
对于延迟为 1 毫秒或更多的高带宽的网络（如 10Gbps 或更高），请考虑将套接字缓冲区设定为 8 或 16MB。
如果您的内存不足，也至少考虑设定为 1MB。 当然，您也可以设定为 -1，它会让底层操作系统根据网络的实际情况，去调整缓冲区的大小。
但是，对于需要启动“热”分割槽的 Consumers 来说，自动调整可能不会那么快。
5、设计具有高吞吐量的 Consumers，以便按需实施背压（back-pressure）
通常，我们应该保证系统只去处理其能力范围内的资料，而不要超负荷“消费”，进而导致程序中断“挂起”，或出现 Consume group 的溢位。
如果是在 Java 虚拟机器（JVM）中执行，Consumers 应当使用固定大小的缓冲区，而且最好是使用堆外内存（off-heap） 。整编：微信公众号，搜云库技术团队，ID：souyunku
请参考 Disruptor 模式：
http://lmax-exchange.github.io/disruptor/files/Disruptor-1.0.pdf
固定大小的缓冲区能够阻止 Consumer 将过多的资料拉到堆叠上，以至于 JVM 花费掉其所有的时间去执行垃圾回收，进而无法履行其处理讯息的本质工作。
6、在 JVM 上执行各种 Consumers 时，请警惕垃圾回收对它们可能产生的影响
例如，长时间垃圾回收的停滞，可能导致 ZooKeeper 的会话被丢弃、或 Consumer group 处于再均衡状态。
对于 Broker 来说也如此，如果垃圾回收停滞的时间太长，则会产生丛集掉线的风险。
针对 Producers 的最佳实践
7、配置 Producer，以等待各种确认
籍此 Producer 能够获知讯息是否真正被发送到了 Broker 的分割槽上。 在 Kafka 的 0.10.x 版本上，其设定是 Acks； 而在 0.8.x 版本上，则为 request.required.acks。
Kafka 通过复制，来提供容错功能，因此单个节点的故障、或分割槽 Leader 关系的更改不会影响到系统的可用性。
如果您没有用 Acks 来配置 Producer（或称“fireand forget”）的话，则讯息可能会悄然丢失。
8、为各个 Producer 配置 Retries
其预设值为 3，当然是非常低的。 不过，正确的设定值取决于您的应用程序，即： 就那些对于资料丢失零容忍的应用而言，请考虑设定为 Integer.MAX_VALUE（有效且最大）。
这样将能够应对 Broker 的 Leader 分割槽出现无法立刻响应 Produce 请求的情况。
9、为高吞吐量的 Producer，调优缓冲区的大小
特别是 buffer.memory 和 batch.size（以字节为单位）。 由于 batch.size 是按照分割槽设定的，而 Producer 的效能和内存的使用量，都可以与 Topic 中的分割槽数量相关联。
因此，此处的设定值将取决于如下几个因素：
Producer 资料速率（讯息的大小和数量）要生成的分割槽数可用的内存量请记住，将缓冲区调大并不总是好事，如果 Producer 由于某种原因而失效了（例如，某个 Leader 的响应速度比确认还要慢），那么在堆内内存（on-heap）中的缓冲的资料量越多，其需要回收的垃圾也就越多。
10、检测应用程序，以跟踪诸如生成的讯息数、平均讯息大小、以及已使用的讯息数等指标
针对 Brokers 的最佳实践
11、在各个 Brokers 上，请压缩 Topics 所需的内存和 CPU 资源。
日志压缩
请参考： https://kafka.apache.org/documentation/#compaction
需要各个 Broker 上的堆叠（内存）和 CPU 周期都能成功地配合实现而如果让那些失败的日志压缩资料持续增长的话，则会给 Brokers 分割槽带来风险。
您可以在 Broker 上调整 log.cleaner.dedupe.buffer.size 和 log.cleaner.threads 这两个引数，但是请记住，这两个值都会影响到各个 Brokers 上的堆叠使用。
如果某个 Broker 丢掷 OutOfMemoryError 异常，那么它将会被关闭、并可能造成资料的丢失。
而缓冲区的大小和执行绪的计数，则取决于需要被清除的 Topic Partition 数量、以及这些分割槽中讯息的资料速率与金钥的大小。
对于 Kafka 的 0.10.2.1 版本而言，通过 ERROR 条目来监控日志清理程式的日志档案，是检测其执行绪可能出现问题的最可靠方法。
12、通过网络吞吐量来监控 Brokers
请监控发向（transmit，TX）和收向（receive，RX）的流量，以及磁盘的 I/O、磁盘的空间、以及 CPU 的使用率，而且容量规划是维护群集整体效能的关键步骤。
13、在群集的各个 Brokers 之间分配分割槽的 Leader 关系
Leader 通常会需要大量的网络 I/O 资源。 例如，当我们将复制因子（replication factor）配置为 3、并执行起来时。
Leader 必须首先获取分割槽的资料，然后将两套副本传送给另两个 Followers，进而再传输到多个需要该资料的 Consumers 上。
因此在该例子中，单个 Leader 所使用的网络 I/O，至少是 Follower 的四倍。 而且，Leader 还可能需要对磁盘进行读操作，而 Follower 只需进行写操作。
14、不要忽略监控 Brokers 的 in-sync replica（ISR）shrinks、under-replicatedpartitions 和 unpreferred leaders
这些都是丛集中潜在问题的迹象。 例如，单个分割槽频繁出现 ISR 收缩，则暗示著该分割槽的资料速率超过了 Leader 的能力，已无法为 Consumer 和其他副本执行绪提供服务了。
15、按需修改 Apache Log4j 的各种属性
详细内容可以参考： https://github.com/apache/kafka/blob/trunk/config/log4j.properties
Kafka 的 Broker 日志记录会耗费大量的磁盘空间，但是我们却不能完全关闭它。
因为有时在发生事故之后，需要重建事件序列，那么 Broker 日志就会是我们最好的、甚至是唯一的方法。
16、禁用 Topic 的自动建立，或针对那些未被使用的 Topics 建立清除策略
例如，在设定的 x 天内，如果未出现新的讯息，您应该考虑该 Topic 是否已经失效，并将其从群集中予以删除。 此举可避免您花时间去管理群集中被额外建立的元资料。
17、对于那些具有持续高吞吐量的 Brokers，请提供足够的内存，以避免它们从磁盘子系统中进行读操作
我们应尽可能地直接从操作系统的快取中直接获取分割槽的资料。 然而，这就意味着您必须确保自己的 Consumers 能够跟得上“节奏”，而对于那些延迟的 Consumer 就只能强制 Broker 从磁盘中读取了 。
18、对于具有高吞吐量服务级别目标（service level objectives，SLOs）的大型群集，请考虑为 Brokers 的子集隔离出不同的 Topic
至于如何确定需要隔离的 Topics，则完全取决于您自己的业务需要。 例如，您有一些使用相同群集的联机事务处理（multipleonline transaction processing，OLTP）系统。
那么将每个系统的 Topics 隔离到不同 Brokers 子集中，则能够有助于限制潜在事件的影响半径。
19、在旧的客户端上使用新的 Topic 讯息格式。 应当代替客户端，在各个 Brokers 上载入额外的格式转换服务
当然，最好还是要尽量避免这种情况的发生。
20、不要错误地认为在本地主机上测试好 Broker，就能代表生产环境中的真实效能了
要知道，如果使用复制因子为 1，并在环回界面上对分割槽所做的测试，是与大多数生产环境截然不同的。
在环回界面上网络延迟几乎可以被忽略的，而在不涉及到复制的情况下，接收 Leader 确认所需的时间则同样会出现巨大的差异。
总结
希望上述各项建议能够有助于您更有效地去使用 Kafka。 如果您想提高自己在 Kafka 方面的专业知识，请进一步查阅 Kafka 配套文件中的“操作”部分，其中包含了有关操作群集等实用资讯。
end：如果你觉得本文对你有帮助的话，记得关注点赞转发，你的支援就是我更新动力。
