本文要点

Kafka 低开销和友好水平扩展的设计使它可以使用廉价的日用硬件仍能保持成功运行。
使用最好的磁盘、分别存储日志、隔离ZooKeeper进程，以及禁用交换以减少延迟，从而为ZooKeeper提供强大的网络带宽。
将Kafka的默认复制因子从两个增加到三个，这适用于大多数生产环境。
更多的分区意味着更好的并行化和吞吐量，但分区也意味着更多的复制延迟、平衡，以及打开更多服务器文件。
监控系统网络吞吐量、打开文件句柄、内存、负载、磁盘使用情况等指标，以及像垃圾回收暂停和堆使用情况等JVM 统计数据。

Apache Kafka 肯定会像它的同名小说家一样不负众望，因为它能激奋新来者、挑战深度，若能更全面的理解它还会产生丰厚的回报。抛开文学，书归正传。遵循kafka最新的最佳实践，一定可以让这个强大的数据流平台的管理变得非常、非常容易，而且还会相当有效。

这里有10个具体的技巧，可以帮助您优化Kafka部署并更容易管理：

设置日志配置参数以使日志易于管理
了解kafka的(低)硬件需求
充分利用Apache ZooKeeper
以正确的方式设置复制和冗余
注意主题配置
使用并行处理
带着安全性思维配置和隔离Kafka
通过提高限制避免停机
保持低网络延迟
利用有效的监控和警报

让我们详细分析一下这些最佳实践。

设置日志配置参数以使日志易于管理

Kafka为用户提供了大量的日志配置选项，虽然默认设置是合理的，但定制日志行为以满足您的特定需求将确保它们不会成为长期的管理挑战。这包括设置日志保留策略、清理、压缩和压缩活动。

可以使用Log.segment.bytes、log.segment.ms、log.cleanup.policy (或主题级等价参数)来控制日志行为。如果在应用场景中您不需要以前的日志，那么您可以使用Kafka删除某个文件大小的日志文件，或者通过设置cleanup.policy 在一段时间之后再“删除”。您还可以将其设置为“compact”，以便在需要时保留日志。注意，要了解运行日志清理会消耗CPU和RAM资源；在将Kafka用于任何时间长度的操作日志时，一定要平衡压缩的频率和维持性能的需要。

压缩是Kafka确保每个消息键(在单个主题分区的数据日志中)至少保留最后一个已知值的过程。压缩操作处理主题中的每个键，以保留其最后的值，清理所有其他重复项。在删除的情况下，该键保存成“null”值(它被称为“墓碑（tombstone）”，因为它能生动地表示已删除)。

图1 Kafka提交日志压缩过程

请参考Kafka操作日志文档：

了解kafka(低)硬件需求

虽然许多不熟悉Kafka的团队会高估它的硬件需求，但其实这个解决方案的设计初衷是低开销和友好地水平扩展。这使得使用廉价的商品硬件并仍可以保持成功运行Kafka成为可能：

CPU：除非需要SSL和日志压缩，否则Kafka不需要强大的CPU。而且，使用的内核越多，并行性越好。而且在大多数情况下，压缩也不会产生影响，应该使用LZ4编解码器来提供最佳性能。
RAM：在大多数情况下，Kafka可以以6 GB的内存运行堆空间。对于特别重的生产负载，使用32 GB以上的机器。额外的RAM将用于支持OS页面缓存和提高客户端吞吐量。虽然Kafka可以以更少的RAM运行，但当可用的内存较少时，它处理负载的能力就会受到限制。
磁盘：如果在RAID设置中使用多个驱动器，就该Kafka大显身手了。由于Kafka的顺序磁盘I/O范式，所以SSD不会提供太多的优势，不应该使用NAS。
网络和文件系统：建议使用XFS，如果条件允许，还可以将集群放在单个数据中心。同时，应尽可能提供更多的网络带宽。

Apache Kafka网站还包含一个专门的硬件和操作系统配置部分，提供了有价值的建议。

关于Kafka负载/性能测试的其他有价值的链接：

充分利用Apache ZooKeeper

Apache ZooKeeper集群的运行是Kafka运行的关键依赖项。但是当你在kafka旁边使用ZooKeeper的时候，一定要记住一些重要的最佳实践。

ZooKeeper 节点的数量最大应该是五个。一个节点适合于开发环境，三个节点对于大多数产品Kafka集群来说就足够了。虽然一个大型Kafka环境可能需要五个ZooKeeper节点来减少延迟，但是必须考虑节点上的负载。如果有七个或更多节点同步并处理请求，负载将变得非常大，性能可能会受到明显的影响。还需要注意的是，与早期版本相比，近期版本的Kafka对Zookeeper的负载要低得多，早期版本使用Zookeeper来存储消费者偏移。

最后一点，就像Kafka的硬件需求一样，为ZooKeeper提供最强大的网络带宽。使用最好的磁盘、分别存储日志、隔离ZooKeeper进程、禁用交换，这些也会减少延迟。

下表重点显示了不同Kafka版本中依赖于Zookeeper的一些控制台操作。早期版本0.8.0在控制台没有提供很多功能。从0.10.0.0开始，我们可以看到一些主要功能与Zookeeper分离开了，这就降低了Zookeeper的使用率。

适当的管理意味着kafka部署的弹性。一个重要的实践是将Kafka的默认复制因子从两个增加到三个，这一条在大多数生产环境中都合适。这样做可以确保一个代理出现问题不要太要紧，甚至两个代理都出问题了也不会中断可用性，尽管这种情况不太可能发生。另一个需要考虑的问题是数据中心机架区域。例如，如果使用AWS， Kafka服务器应该位于同一个区域，但是利用多个可用性区域来实现冗余和弹性。以正确的方式设置复制和冗余。

机架部署要考虑的Kafka配置参数是：

broker.rack=rack-id

如Apache Kafka文档所述：

当一个主题被创建、修改或复制被重新分发时，将遵守机架约束，确保复制能够跨尽可能多的机架，分区将尽可能分布在不同的机架上，在此，机架即为复制因子。

举个例子：

假设，9个Kafka代理(B1-B9)分布在三个货架上。

图2 带有机架感知的kafka集群

在这里，一个具有三个分区(P1、P2、P3)和三个复制因子(R1、R2、R3)的单一主题将在每个机架中为一个节点分配一个分区。这个场景中每个分区有两个副本，以此提供高可用性，即使一个完整的机架发生故障(如图所示)也可以保持正常运行。

注意主题配置

主题配置对Kafka集群的性能有巨大的影响。因为更改设置(如复制因子或分区计数)可能很困难，所以您需要在第一次以正确的方式设置这些配置，然后在需要更改时简单地创建一个新主题(一定要在准生产环境中测试新主题)。

使用三个复制因子，并仔细思考大型消息的处理。如果可能的话，将大的消息分解成有序的块，或者使用指向数据的指针(比如指向S3的链接)。如果这些方法不可选，则在生产者一方启用压缩。默认的日志段大小是1 GB，如果您的消息更大，就应该仔细检查一下用例了。分区计数也是一个非常重要的设置，将在下一节详细讨论。

主题配置有一个“服务器默认”属性。可以在主题创建时或稍后进行重写，以便具有特定于主题的配置。

如上所述，最重要的配置之一是复制因子。以下例子演示了从控制台创建主题的过程，复制因子为3个和3个分区，以及其他“主题级别”配置：

bin/kafka-topics.sh --zookeeper ip_addr_of_zookeeper：2181 --create --topic my-topic –partitions 3 --replication-factor 3 --config max.message.bytes=64000 --config flush.messages=1

有关主题级别配置的完整介绍，请参阅这里的内容。

使用并行处理

Kafka是为并行处理而设计的，和并行操作本身一样，充分利用它需要操作的平衡。分区计数是一个主题级设置，分区越多，并行性和吞吐量就越大。然而，分区也意味着更多的复制延迟、重平衡和打开服务器文件。

找到您的最佳分区设置很简单，就像计算您希望为您的硬件实现的吞吐量，然后计算所需的分区数量就可以了。按照保守的估计，一个主题上的一个分区可以传递10 MB/s，根据这个估计可以推断出您需要的总吞吐量。另一种直接进行测试的方法是对每个主题使用一个代理，然后看看结果，如果需要更高的吞吐量，则将分区加倍。

总的来说，这里有条规则值得一用：主题的总分区数要低于10，集群的总分区数要低于10，000。如果您不这样做，那么需具有很高的监控能力，并且准备好处理可能非常具有挑战性的重平衡和中断!

创建Kafka主题时设置了分区的数量，如下所示。

bin/kafka-topics.sh --zookeeper ip_addr_of_zookeeper：2181 --create --topic my-topic –partitions 3 --replication-factor 3 --config max.message.bytes=64000 --config flush.messages=1

创建分区后可以增加分区计数。但它会影响消费者，因此建议在处理完所有结果后再执行此操作。

bin/kafka-topics.sh --zookeeper zk_host：port/chroot --alter --topic topic_name –partitions new_number_of_partitions

出于安全性考虑配置和隔离Kafka

确保Kafka部署的两个主要关注点是1)Kafka的内部配置，2)Kafka运行的基础设施。

Kafka的.9版本包含了许多有价值的安全特性，例如Kafka/client和Kafka/ZooKeeper认证支持，以及对具有公共互联网客户端的保护系统的TLS支持。虽然TLS确实为吞吐量和性能带来了成本，但它有效且有价值地隔离并保护了Kafka代理的流量。

隔离kafka和ZooKeeper 对安全至关重要。除极为罕见的情况之外，ZooKeeper 不应该连接到公共互联网，而应该只与kafka(或它所使用的其他解决方案)交互。防火墙和安全组应该隔离Kafka和ZooKeeper，让代理处于一个单独的私有网络中，拒绝外部连接。中间件或负载平衡层应该将Kafka与公共互联网客户端隔离。

Kafka的安全选项和协议：

SSL/SASL：客户端到代理、中介代理、代理到工具的身份验证。
SSL：客户端到代理之间、代理到代理之间和工具到代理之间的数据加密
SASL类型：SASL/GSSAPI (Kerberos)， SASL/PLAIN
Zookeeper安全性：为客户端(代理、工具、生产者、消费者)进行身份验证，使用ACL进行授权。
- Kafka代理客户端：生产者、消费者、其他工具。
- ZooKeeper 客户：kafka代理、生产者、消费者、其他工具。
- 授权是可插拔的。

一个使用SASL_SSL进行安全设置的配置示例：

#Broker configuration
      listeners=SSL://host.name:port,SASL_SSL://host.name:port 
      advertised.listeners=SSL://host.name:port,SASL_SSL://host.name:port
      security.protocol=SASL_SSL 
      security.inter.broker.protocol=SSL 

      listener.security.protocol.map=INTERBROKER\:SSL,PUBLIC_CLIENT\:
SASL_PLAINTEXT,PRIVATE_CLIENT\:SASL_PLAINTEXT


       ssl.keystore.location=/var/private/ssl/server.keystore.jks

       ssl.keystore.password=test1234
       ssl.key.password=test1234
 
       ssl.truststore.location=/var/private/ssl/server.truststore.jks
 
       ssl.truststore.password=test1234

       sasl.mechanism.inter.broker.protocol=PLAIN 
       sasl.enabled.mechanisms=PLAIN 


#Client Configuration (jaas file)
       sasl.mechanism=PLAIN
 
       sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule 
       required \
       
       username="[USER NAME]" 
       password="[USER PASSWORD]";

通过提高Ulimit避免停机

一种经常发生的情况是：代理看起来从过多的负载降下来了，但实际上是一个(尽管仍然有压力)“打开的文件太多”的良性错误。编辑/etc/sysctl.conf文件，配置Ulimit以允许128，000或更多的打开文件，可以避免发生这个错误。

增加CentOS上限的一个例子：

创建一个新的文件：/etc/security/limits.d/nofile.conf
输入内容：

soft nofile 128000
hard nofile 128000

重新启动系统或重新登录。
通过以下命令来验证：

ulimit - a

*注意，有多种方法可以增加ulimit。您可以按照任何适合您自己的Linux发行版的方法来修改。

保持低网络延迟

为了实现Kafka部署的低延迟，请确保代理位于离客户端最近的区域，并在选择云提供商提供的实例类型时一定要考虑网络性能。如果带宽阻碍了您的发展，那么可能就值得考虑投资一个更大更强力的服务器了。

利用有效的监控和警报

在创建Kafka集群时，按照上面的做法，您可以在以后的工作中避免很多问题，但是您仍然需要保持警惕，在出现问题之前，提前正确识别和处理任何小问题。

监视系统指标(如网络吞吐量、打开的文件句柄、内存、负载、磁盘使用情况和其他因素)是必不可少的，同时还要密切关注JVM统计数据，包括GC暂停和堆使用情况。仪表板和历史回溯工具能够加速调试过程，可以提供大量的价值。与此同时，应该配置Nagios或PagerDuty等警报系统，以便在出现延迟峰值或磁盘空间不足等症状时发出警告，从而在小问题如滚雪球般越滚越大之前就能解决。

通过Instaclustr控制台中显示的Kafka监控图示例：

关于作者

Ben Bromhead是Instaclustr的首席技术官，该公司提供了一个托管服务平台，提供Apache Cassandra、Apache Kafka、Apache Spark和Elasticsearch等开源技术。

查看英文原文： Apache Kafka: Ten Best Practices to Optimize Your Deployment

创作场景

Apache Kafka：优化部署的 10 种最佳实践