Apache Kafka是一个高性能、高可用性、冗余的流消息平台。
Kafka的功能很像发布/订阅消息系统，但具有更高的吞吐量、内置分区、复制和容错能力。对于大规模消息处理应用程序来说，Kafka是一个很好的解决方案。它通常与Apache Hadoop和Spark Streaming一起使用。
操作系统要求
Kafka对操作系统要求的集合。
SUSE Linux企业服务器(SLES)
与CentOS不同，SLES默认情况下会限制虚拟内存。更改此默认值要求，将以下条目添加到/etc/security/limits.conf文件中：
* hard as unlimited* soft as unlimited内核限制
您必须为内核正确配置下面三个设置。
- 文件描述符(File Descriptors)
您可以通过以下步骤在Cloudera Manager中设置文件描述符：转到Kafka > Configuration > Maximum Process File Descriptors 并设置所需的值。Cloudera建议使用100000或更高的数值进行配置。
- 最大内存映射(Max Memory Map)
您必须在特定的内核设置中配置最大内存映射数。Cloudera建议配置32000或更高版本。
- 最大套接字缓冲区大小(Max Socket Buffer Size)
将缓冲区大小设置为大于任何您定义的Kafka send缓冲区。
性能考虑
有关Kafka集群的基本建议的集合。
运行Kafka以获得最佳性能的最简单建议是为Kafka代理使用专用主机，为Kafka集群使用专用的ZooKeeper集群。如果这不是一种选项，请考虑以下有关与Kafka集群共享资源的其他准则：
- 在虚拟机中运行
在现代数据中心中，通常的做法是在虚拟机中运行进程。通常，这可以更好地共享资源。Kafka对I / O吞吐量足够敏感，以至于VM会干扰代理的正常运行。因此，通常不建议在VM中运行Kafka。但是，如果您在虚拟环境中运行Kafka，则需要依靠VM供应商来帮助您优化Kafka的性能。
- 不要使用Brokers或ZooKeeper运行其他进程
由于与其他进程的I / O争用，通常建议避免在与Kafka代理相同的主机上运行其他此类进程。
- 保持Kafka-ZooKeeper连接稳定
Kafka在很大程度上依赖于稳定的ZooKeeper连接。在Kafka和ZooKeeper之间放置不可靠的网络将显示为ZooKeeper脱机到Kafka。不可靠的网络示例包括：
- 不要将Kafka / ZooKeeper节点放在不同的网络上
- 请勿将Kafka / ZooKeeper节点与其他高网络负载置于同一网络上
配额
了解配额以及如何设置配额。
Kafka可以对生产和获取请求时强制执行配额。生产者和消费者可以使用大量数据。这会垄断代理资源，导致网络饱和，并且通常会拒绝向其他客户端和代理本身提供服务。配额可以防止这些问题，并且对于大型的多租户集群非常重要，在该集群中，使用少量数据的少量客户端可能会降低用户体验。
配额是按客户端ID定义的字节速率阈值。客户端ID在逻辑上标识发出请求的应用程序。一个客户端ID可以跨越多个生产者和消费者实例。该配额作为单个实体应用于所有实例。例如，如果客户端ID的生产配额为10 MB / s，则该配额在具有相同ID的所有实例之间共享。
当将Kafka作为服务运行时，配额可以强制执行API限制。默认情况下，每一个唯一的客户端ID接收以每秒字节数固定的配额，如通过集群配置(quota.producer.default，quota.consumer.default)。此配额是根据每个代理定义的。每个客户端在受到限制之前，每个代理每秒最多可以发布或获取 X个字节。
当客户端超过其配额时，代理不会返回错误，而是尝试降低客户端的速度。代理计算使客户端达到其配额所需的延迟量，并将响应延迟该时间量。这种方法使配额违规对客户端(客户端指标之外)透明。这也避免了客户端必须实施特殊的退避和重试行为。
您可以覆盖需要更高或更低配额的客户端ID的默认配额。该机制类似于按主题的日志配置替代。将您的客户端ID覆盖写到ZooKeeper的/config/clients。所有代理均会读取覆盖，这些覆盖将立即生效。您可以更改配额，而不必滚动重启整个集群。
默认情况下，每个客户端ID都会收到一个不受限的配额。以下配置将每个生产者和消费者客户端ID的默认配额设置为10 MB / s。
quota.producer.default=10485760quota.consumer.default=10485760要使用Cloudera Manager设置配额，请打开Kafka Configuration 页面并搜索Quota。使用提供的字段来设置默认使用者配额或默认生产者配额。
JBOD
JBOD是指一种系统配置，其中磁盘是独立使用的，而不是将它们组织到冗余阵列(RAID)中。即使单个磁盘不可靠，使用RAID通常也会导致更可靠的硬盘配置。此类RAID设置在基于商用硬件构建的大规模大数据环境中很常见。启用RAID的配置更昂贵且设置更复杂。在许多环境中，出于以下原因，首选JBOD配置：
- 降低存储成本：建议使用RAID-10来防止磁盘故障。但是，扩展RAID-10配置可能会变得非常昂贵。在每个节点上冗余存储数据意味着必须倍增存储空间需求，因为数据也在节点之间复制。
- 改进的性能：与HDFS一样，RAID-10配置中最慢的磁盘也限制了整体吞吐量。写入需要通过RAID控制器。另一方面，使用JBOD时，由于在没有控制器的情况下跨磁盘进行了隔离写入，因此提高了IO性能。
设置Kafka的用户限制
了解有关Kafka用户的限制以及如何监控它们。
Kafka可以同时打开许多文件。对于大多数类Unix系统，最大打开文件数的默认设置1024是不够的。任何重大负载都可能导致故障并导致错误消息，例如java.io.IOException ...(打开的文件太多)记录在Kafka或HDFS日志文件中。您可能还会注意到以下错误：
ERROR Error in acceptor (kafka.network.Acceptor)
java.io.IOException: Too many open files
Cloudera建议将该值设置为较高的起点，例如32,768。
您可以在Kafka Broker仪表板上监视正在使用的文件描述符的数量。在Cloudera Manager中：
- 转到Kafka服务。
- 选择一个Kafka 代理。
- 打开Charts Library > Process Resources，然后向下滚动到File Descriptors图表。
