Apache Kafka 确定会像它的同名小说家同样不负众望，由于它能激奋新来者、挑战深度，若能更全面的理解它还会产生丰厚的回报。抛开文学，书归正传。遵循 kafka 最新的最佳实践，必定可让这个强大的数据流平台的管理变得很是、很是容易，并且还会至关有效。mysql
这里有 10 个具体的技巧，能够帮助您优化 Kafka 部署并更容易管理：ios
设置日志配置参数以使日志易于管理sql
了解 kafka 的 (低) 硬件需求apache
充分利用 Apache ZooKeeper缓存
以正确的方式设置复制和冗余安全
注意主题配置服务器
使用并行处理微信
带着安全性思惟配置和隔离 Kafka网络
经过提升限制避免停机app
保持低网络延迟
利用有效的监控和警报
让咱们详细分析一下这些最佳实践。
Kafka 为用户提供了大量的日志配置选项，虽然默认设置是合理的，但定制日志行为以知足您的特定需求将确保它们不会成为长期的管理挑战。这包括设置日志保留策略、清理、压缩和压缩活动。
可使用 Log.segment.bytes、log.segment.ms、log.cleanup.policy (或主题级等价参数) 来控制日志行为。若是在应用场景中您不须要之前的日志，那么您可使用 Kafka 删除某个文件大小的日志文件，或者经过设置 cleanup.policy 在一段时间以后再“删除”。您还能够将其设置为“compact”，以便在须要时保留日志。注意，要了解运行日志清理会消耗 CPU 和 RAM 资源；在将 Kafka 用于任什么时候间长度的操做日志时，必定要平衡压缩的频率和维持性能的须要。
压缩是 Kafka 确保每一个消息键 (在单个主题分区的数据日志中) 至少保留最后一个已知值的过程。压缩操做处理主题中的每一个键，以保留其最后的值，清理全部其余重复项。在删除的状况下，该 键保存成“null”值 (它被称为“墓碑（tombstone）”，由于它能生动地表示已删除)。
图 1 Kafka 提交日志压缩过程
请参考 Kafka 操做日志文档：
日志：
https://kafka.apache.org/documentation/#log
压缩基础知识：
https://kafka.apache.org/documentation/#design_compactionbasics
虽然许多不熟悉 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 Kafka 的基准测试：每秒 200 万次写 (在 3 台廉价的机器上)
https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines
在 AWS 上的 Apache Kafka 负载测试
https://grey-boundary.io/load-testing-apache-kafka-on-aws/
性能测试
https://cwiki.apache.org/confluence/display/KAFKA/Performance+testing
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 集群
在这里，一个具备三个分区 (P一、P二、P3) 和三个复制因子 (R一、R二、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
有关主题级别配置的完整介绍，请参阅这里的内容:
https://kafka.apache.org/documentation/#topicconfigs
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 部署的两个主要关注点是 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]";
一种常常发生的状况是：代理看起来从过多的负载降下来了，但其实是一个 (尽管仍然有压力)“打开的文件太多”的良性错误。编辑 /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 监控图示例：
https://www.infoq.com/articles/apache-kafka-best-practices-to-optimize-your-deployment
推荐阅读：
大数据基础系列之kafka011生产者缓存超时，幂等性和事务实现
分享给你的小伙伴吧～
本文分享自微信公众号 - 浪尖聊大数据（bigdatatip）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。