使用Scala开发Apache Kafka的TOP 20大好用实践
|
7、配置生产者等待确认。 这就是生产者如何知道消息实际已经发送到brocker上的分区。在Kafka 0.10.x中，设置为acks; 在0.8.x中，它是request.required.acks。Kafka通过复制提供容错功能，因此单个节点的故障或分区leader的更改不会影响可用性。如果将生产者配置为没有ack(也称为“fire and forget”)，则消息可能会无声地丢失。 8、配置生产者重试次数。默认值为3，通常太低。正确的值取决于需求，对于无法容忍数据丢失的应用程序，请考虑Integer.MAX_VALUE(实际上是无穷大)，这可以防止leader分区的brocker无法立即响应生产请求。 9、对于高吞吐量生产者，调整缓冲区大小，特别是buffer.memory和batch.size(以字节为单位)。由于batch.size是按分区设置的，因此生产者性能和内存使用量可与topic中的分区数相关联。这里的值取决于几个因素：生产者数据速率(消息的大小和数量)，生成的分区数以及可用的内存量。请记住，较大的缓冲区并不总是好的，如果生产者由于某种原因而停顿(例如，一个领导者通过确认响应较慢)，在堆上缓存更多数据可能会导致更多垃圾收集。 10、制定应用程序跟踪指标，例如生成的消息数，平均生成的消息大小和消耗的消息数。 第四部分：brocker最佳实践! 11、Topic需要brocker的内存和CPU资源，日志压缩需要brocker上的堆(内存)和CPU周期才能成功完成，并且失败的日志压缩会使brocker处于无限增长的分区风险中。你可以在brocker上使用tunelog.cleaner.dedupe.buffer.size和log.cleaner.threads，但请记住，这些值会影响brocker上的堆使用情况。如果brocker抛出OutOfMemoryError异常，它将关闭并可能丢失数据。缓冲区大小和线程数将取决于要清理的主题分区数量以及这些分区中消息的数据速率和密钥大小。从Kafka 0.10.2.1版本开始，监视日志清理程序日志文件以查找ERROR条目是检测日志清理程序线程问题的最可靠方法。 12、监控brocker的网络吞吐量。确保使用发送(TX)和接收(RX)，磁盘I/O，磁盘空间和CPU使用率来执行此操作。容量规划是维护集群性能的关键部分。 13、在集群中的brocker之间分配分区leader，其需要大量的网络I/O资源。例如，当使用复制因子3运行时，leader必须接收分区数据，并同步传递给所有副本，再传输给想要使用该数据的消费者。因此，在这个例子中，作为领导者，在使用网络I/O方面至少是follower的四倍，leader必须从磁盘读取，follower只需要写。 14、不要忽略监视brocker的同步副本(ISR)缩减，重复不足的分区和不受欢迎的lesder。这些是集群中潜在问题的迹象。例如，单个分区的频繁ISR收缩可能表明该分区的数据速率超过了leader为消费者和副本线程提供服务的能力。 15、根据需要修改Apache Log4j属性。Kafka代理日志记录可能会占用过多磁盘空间。但是，不要完全放弃日志记录，brocker日志可能是在事件发生后重建事件序列的最佳方式，有时也是唯一方式。 16、禁用topic自动创建有关的明确策略，定期清理未使用的topic。例如，如果x天没有看到任何消息，请考虑topic失效并将其从集群中删除，这样可以避免在集群中创建必须管理的其他元数据。 17、对于持续的高吞吐量代理，请提供足够的内存以避免从磁盘系统读取，应尽可能直接从操作系统的文件系统缓存中提供分区数据。但是，这意味着必须确保消费者能够跟上，滞后的消费者将迫使brocker从磁盘读取。 18、对于具有高吞吐量服务级别目标(SLO)的大型集群，请考虑将topic隔离到brocker子集。如何确定要隔离的topic取决于业务需求，例如，如果有多个使用相同集群的联机事务处理(OLTP)系统，则将每个系统的topic隔离到brocker的不同子集以帮助限制事件的潜在爆炸半径。 19、使用较新topic消息格式的旧客户端(反之亦然)会在brocker客户端转换格式时对brocker程序施加额外负担，尽可能避免这种情况。 20、不要认为在本地台式机上测试brocker代表在实际生产环境中的性能。使用复制因子1对分区的环回接口进行测试是与大多数生产环境完全不同的拓扑。通过环回可以忽略网络延迟，并且在不涉及复制时，接收leader确认所需的时间可能会有很大差异。 【编辑推荐】
点赞 0 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
