− CPU 和内存比例建议设置为 1:4 ,比如 4C/16GB 、 8C/32GB 、 16C/64GB 。如果开启 TLS 和数据压缩功能,建议将比例提升至 1:2 。
单个 Topic 分区数建议控制在 10 个以内。
Kafka 应用对于可靠性要求较高的场景常采用 3 副本;
− 分区副本数建议为 2 或 3 ,从可靠性考虑,非常关键业务建议设置为 3 。
− 如果想保证数据绝对不丢失, Producer 需要开启重试逻辑,并且设置 ACKS=all ,如果需要增大吞吐量,可以考虑设置较大的 batch.size (默认为 16K )。
− Producer 数量并不是越多越好,需要根据业务需求来确定,通常单个 Topic 的 Producer 个数不超过其分区数。
− 单个 Consumer Group 的 Consumer 的个数最好与 Topic 的分区数成一定比例,这样能够最大化的提升 Consumer 的资源利用率。
如果 Broker 是暴露在开放的网络上(无论是内网还是外网),则需要开启 TLS 和 ACL ,防止中间人攻击和未授权的用户访问。
收起Kafka性能和可靠性的调优涉及Broker、Producer、Topic等组件的多个参数,并且参数之间还存在关联关系。以Topic为例,每个Topic的分区(Partition)数、每个Partition的副本数等都会对性能产生明显的影响。而其中的副本数又是同时与可靠性和性能都相关的参数:例如如果为了保证可靠性设置三副本,并将acks设置为all,则 leader节点会等待所有同步中的副本确认之后再确认这条记录是否发送完成,这就对吞吐量和时延有直接的影响。
因此实际部署过程中需要基于业务吞吐量和可靠性要求进行对比调优,之前已有海外金融、运营商客户实践Kafka/ES + 容器平台 + 外置企业NAS,采用单副本存储,同时支持计算漂移的方案。一方面通过外置企业NAS存储保障数据可靠性,一方面通过计算侧容器平台的漂移能力解决应用的可靠性;同时单副本部署,性能达到最佳值。本次测试其实是完整验证了这一方案的可行性和实际价值,测试结果也充分证明了单副本的性能最优,同时结合容器平台自身的漂移能力,可以实现分钟级的漂移,依靠平台能力提升可靠性。
Kafka是一种高性能、低延迟、高可靠的分布式消息队列,被广泛应用于金融行业中,因此对于Kafka集群的参数调优和持久化存储配置方面的最佳实践非常重要。
以下是一些最佳实践:
(1)调整内存分配:Kafka使用内存作为缓存,因此需要根据实际情况调整内存分配。可以通过调整broker
的heap.size
参数来实现。
(2)调整文件句柄数:Kafka需要大量的文件句柄来处理消息,因此需要根据实际情况调整文件句柄数。可以通过调整broker
的ulimit
参数来实现。
(3)调整网络参数:Kafka需要大量的网络带宽来处理消息,因此需要根据实际情况调整网络参数。可以通过调整broker
的socket.send.buffer.bytes
和socket.receive.buffer.bytes
参数来实现。
(1)选择合适的存储介质:Kafka支持多种存储介质,包括SSD、HDD、SAN等。需要根据实际情况选择合适的存储介质。
(2)调整日志分段大小:Kafka将消息存储在日志中,需要根据实际情况调整日志分段大小。可以通过调整log.segment.bytes
参数来实现。
(3)调整日志保留时间:Kafka需要定期清理过期的日志,需要根据实际情况调整日志保留时间。可以通过调整log.retention.hours
参数来实现。
(4)开启压缩:Kafka支持消息压缩,可以减少存储空间和网络带宽的使用。可以通过调整compression.type
参数来开启压缩。
总之,Kafka集群的参数调优和持久化存储配置是一个复杂的过程,需要根据实际情况进行调整。以上是一些最佳实践,但并不是唯一的解决方案。在实际应用中,需要根据具体情况进行调整。