本文分享Kafka最佳实践可以使得管理这个功能强大的数据流平台变得更加容易，而且更加有效。以下是十个有助于保持Kafka部署优化并更易于管理的特定提示：
- 设置日志配置参数以保持日志可管理
- 了解Kafka的（低）硬件要求
- 充分利用Apache ZooKeeper
- 以正确的方式设置复制和冗余
- 注意主题配置
- 使用并行处理
- 在考虑安全性的情况下配置和隔离Kafka
- 通过提升Ulimit避免中断
- 保持较低的网络延迟
- 利用有效的监控和警报
让我们详细了解这些最佳实践。
设置日志配置参数以保持日志可管理
Kafka为用户提供了大量日志配置选项，虽然默认设置合理，但根据您的特定需求自定义日志行为将确保它们不会长期成为管理挑战。
这包括设置日志保留策略，清理，压缩和压缩活动。可以使用log.segment.bytes，log.segment.ms和log.cleanup.policy（或主题级别等效）参数来控制日志行为。
如果在你不需要历史日志，可以通过将cleanup.policy设置为“delete”来让Kafka删除特定文件大小的日志文件或在一段设定的时间后删除；或在需要时保留日志还可以将其设置为“compact” 。重要的是要了解运行日志清理会消耗CPU和RAM资源，一定要平衡压缩的频率和维持性能的需要。
压缩是Kafka确保至少保留每个消息密钥的最后已知值（在单个主题分区的数据日志内）的过程。压缩操作适用于主题中的每个键，以保留其最后一个值，清除所有其他重复项。在删除的情况下，密钥留有'null'值（它表示为'tombstone'，因为它表示，五颜六色，删除）。
了解Kafka的（低）硬件要求
虽然许多不熟悉Kafka的团队会高估其硬件需求，但该解决方案实际上具有较低的开销和横向扩展友好的设计。这使得可以使用廉价的商品硬件并且仍然非常成功地运行Kafka：
- CPU：除非需要SSL和日志压缩，否则Kafka不需要功能强大的CPU。此外，使用的内核越多，并行化就越好。在大多数情况下，压缩不是一个因素，应使用LZ4编解码器来提供最佳性能。
- RAM：在大多数情况下，Kafka可以使用6 GB的RAM以最佳方式运行堆空间。对于特别重的生产负载，请使用32 GB或更高的机器。额外的RAM将用于支持OS页面缓存并提高客户端吞吐量。虽然Kafka可以使用较少的RAM运行，但是当可用内存较少时，其处理负载的能力受到阻碍。
- 磁盘：在RAID设置中使用多个驱动器时，Kafka蓬勃发展。由于Kafka的顺序磁盘I / O范例，SSD不具备很多优势，因此不应使用NAS。
- 网络和文件系统：建议使用XFS，如果情况允许，则将群集保留在单个数据中心。此外，提供尽可能多的网络带宽。
充分利用Apache ZooKeeper
Apache ZooKeeper集群是运行Kafka的关键依赖项。但是当与Kafka一起使用ZooKeeper时，需要记住一些重要的最佳实践。ZooKeeper节点的数量应最多为5。1个节点适用于开发环境，3个节点足以满足大多数生产Kafka集群的需求。
虽然大型Kafka部署可能需要5个ZooKeeper节点来减少延迟，但必须考虑节点上的负载。有7个或更多节点同步并处理请求，负载变得巨大，性能可能会受到显着影响。
另请注意，最近版本的Kafka对Zookeeper的负载比早期版本低得多，后者使用Zookeeper来存储消费者偏移。最后，正如Kafka的硬件需求一样，为ZooKeeper提供最强大的网络带宽。使用最好的磁盘，分别存储日志，隔离ZooKeeper进程和禁用交换也可以减少延迟。下表突出显示了在不同Kafka版本中依赖于Zookeeper的一些控制台操作。早期版本0.8.0在适当的管理意味着Kafka部署的弹性。
一个重要的做法是将Kafka的默认复制因子从2增加到3，这在大多数生产环境中都是合适的。
这样做可以确保一个代理的丢失不会引起关注，即使不太可能丢失两个代理也不会中断可用性。
另一个考虑因素是数据中心机架区。例如，如果使用AWS，Kafka服务器应该位于同一区域，但利用多个可用区域来实现冗余和弹性。以正确的方式设置复制和冗余要考虑机架rack部署的Kafka配置参数是：broker.rack=rack-id如Apache Kafka 文档中所述：创建主题，重新分配修改或副本时，将遵循机架rack约束，确保副本尽可能多地复制到rack机架（分区将跨越 min(racks，复制因子) 不同的机架）。
注意主题Topic配置
主题配置对Kafka集群的性能产生巨大影响。由于对复制因子或分区计数等设置的更改可能具有挑战性，因此您需要在第一次时以正确的方式设置这些配置，然后在需要更改时简单地创建新主题（在临时环境中测试新主题）。
使用复制因子为3，并对处理大型消息时要周到。
如果可能，将大型消息分解为有序的部分，或者仅使用指向数据的指针（例如指向S3的链接）。如果这些方法不是选项，请在生产者端启用压缩。默认日志段大小为1 GB，如果您的消息较大，则应该仔细查看用例。
分区计数也是一个至关重要的设置，将在下一节中详细讨论。
主题配置具有“服务器默认”属性。这些可以在主题创建时或稍后的时间被覆盖，以便具有特定于主题的配置。如上所述，最重要的配置之一是复制因子。该示例演示了从控制台创建主题的复制因子为三个和三个分区以及其他“主题级别”配置：
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 /客户端和Kafka / ZooKeeper身份验证支持，以及TLS支持以保护具有公共Internet客户端的系统。
虽然TLS确实为吞吐量和性能带来了成本，但它有效且有价值地隔离并保护了Kafka经纪商的流量。隔离Kafka和ZooKeeper对安全至关重要。除了极少数情况，ZooKeeper永远不应该连接到公共互联网，并且只应与Kafka（或其他用于其的解决方案）进行通信。防火墙和安全组应该隔离Kafka和ZooKeeper，而代理驻留在拒绝外部连接的单个专用网络中。中间件或负载平衡层应该使Kafka与公共Internet客户端隔离。Kafka的安全选项和协议：
- SSL / SASL：对经纪人，经纪人，经纪人和工具的客户认证。
- SSL：客户端与代理之间，代理与工具之间的数据加密
- SASL类型：SASL / GSSAPI（Kerberos），SASL / PLAIN，SASL / SCRAM-SHA-512 / SCRAM-SHA-256，SASL_AUTHBEARER
- Zookeeper安全性：客户端（经纪人，工具，生产者，消费者）的身份验证，使用ACL进行授权。
使用SASL_SSL进行安全性设置的示例配置：
Broker configuration |
通过提升Ulimit避免中断
这种情况经常发生：经纪人经常会因为负载太大而宕机，但实际上是一种良性（尽管仍然有压力）“太多打开文件”错误。
通过编辑/etc/sysctl.conf并配置Ulimit以允许128,000或更多打开的文件，您可以避免发生此错误。增加CentOS上的ulimit的一个例子：
- 创建一个新文件 /etc/security/limits.d/nofile.conf
- 输入内容：
* soft nofile 128000 * hard nofile 128000
- 重新启动系统或重新登录。
- 通过发出以下命令验证。
ulimit -a
*请注意，有多种方法可以增加ulimit。您可以按照任何合适的方法进行自己的Linux发行版。
保持较低的网络延迟
为了实现Kafka部署的低延迟，请确保代理在地理位置最靠近客户端的区域，并确保在选择云提供商提供的实例类型时考虑网络性能。如果带宽阻碍了你，那么更大更强大的服务器可能是值得的投资。
利用有效的监控和警报
按照上述做法，在创建Kafka群集时可以避开许多问题，但是您仍然需要保持警惕，以便在问题出现之前认识并妥善解决任何打嗝问题。监控系统指标（如网络吞吐量，打开文件句柄，内存，负载，磁盘使用情况和其他因素）至关重要，因为要密切关注JVM统计信息，包括GC暂停和堆使用情况。能够加速调试过程的仪表板和历史工具可以提供很多价值。同时，应该配置Nagios或PagerDuty等警报系统，以便在出现延迟峰值或磁盘空间不足等症状时发出警告，以便在问题出现之前解决小问题。