kafka集群规划

OS
一般来说，对于运行Linux中的kafka集群不需要过多的OS以及kernel参数调整，但如下几种情况可以根据具体情况进行参考:

文件描述符(fd): broker节点上fd限制可以参考(number_of_partitions)*(partition_size/segment_size)公式
套接字缓冲区(socket buffer): 该参数可以增加多数据中心之间的数据传输(一般异地集群备份建议调整以增加吞吐)
最大内存映射区域数(vm.max_map_count): 当kafka broker节点拥有太多分区时应该密切关注系统级别的该参数，默认为65535。每一个日志段，分配的分区，都需要一对index/timeindex文件，而每个文件都会消耗一个内存区域(一个日志段使用2个内存映射区域)，因此一个分区至少需要2个内存区域，一个broker上拥有50000分区时，将会消耗100000个内存区域，此时默认的参数就会导致broker 以OutOfMemoryError方式crash掉。
注意:每个分区的日志段的数量取决于段(segment)的大小，负载，以及保留策略

kafka使用大量的文件以及socket和客户端进行通讯，我们都知道，在Linux下，一切皆文件，因此系统需要设置更多的可用文件描述符>。

在大多数的默认系统配置中，单个进程可用使用1024个文件描述符，对于kafka来说太小了，建议调整到至少100000，但是通常和操作 系统以及发行版本有关系，需要根据具体的OS进行调整。

可用通过计算Kafka数据目录中的.index文件来计算当前的mmap编号。.index文件大多数代表了内存映射文件。

1.统计.index文件个数

$ find . -name '*index' | wc -l

2.为每个session设置vm.max_map_count参数，这将计算当前内存映射文件的数量，mmap限制的最小值就是打开文件的ulimit限制
该值要远大于index的数量

$ sysctl -w vm.max_map_count=262144

3.持久化mmap参数

$ echo 'vm.max_map_count=262144' >> /etc/sysctl.conf
$ sysctl -p

网络

低延迟确保节点可以轻松通信，而高带宽有助于集群节点之前的副本移动和恢复(往往在kafka集群中优先瓶颈点都是带宽)。

目前大多数的数据中心基本都是千兆(1 GbE)或万兆网络(10 GbE)，对于大多数集群通常都是足够的。

应该尽量避免集群跨越多个数据中心，即使数据中心在很近的距离同地区，也要避免跨越巨大地理距离的集群。

备注:实际上在分布式系统中分区是肯定会发生的，通过避免跨机房部署能够降低分区的概率

Kafka集群假设所有节点都是相等的，较大的延迟可能会加剧分布式系统中的问题，并使调试和解决变得更加困难。

注意: 如果业务上需要异地进行数据读写，推荐的方法是在每个数据中心中部署一个本地Kafka集群，每个数据中心中的应用程序实例只与它们的本地集群交互，并在集群之间进行镜像(kafka提供了mirror-maker工具)。

Filesystem

现在操作系统中，大部分的系统应该都使用了Ext4或XFS系统，官方也推荐使用这两种文件系统，但是对于具体的文件系统的选择，官方提供了如下几种场景和需要注意的点。

使用各种文件系统创建和挂载选项，在具有大量消息负载的集群上执行了比较测试，XFS带来了更好的本地时间(最好的EXT4配置是160ms vs. 250ms+)，以及更低的平均等待时间。XFS性能在磁盘性能方面的可变性也较小。

不论是使用哪种文件系统，推荐修改默认的挂载参数:

noatime: 此选项禁止在读取文件时更新文件的atime(最后访问时间)属性,这可以消除大量的文件系统写操作，特别是在引导消费者的情况下,Kafka完全不依赖于atime属性，所以禁用它是安全的

$ cat /etc/fstab
UUID="4231b126-7e67-45c4-b8bf-554006291d35"  /export1    xfs    defaults,noatime         0 2

XFS文件系统挂载参数优化:

largeio: 这会影响stat调用报告的首选I/O大小，尽管这可以在较大的磁盘写入上实现更高的性能，但实际上对性能的影响很小或没有影响
nobarrier: 于具有电池后备缓存的基础设备，此选项可以通过禁用定期写刷新来提供更高的性能。 但是，如果基础设备的行为良>好，它将向文件系统报告它不需要刷新，并且此选项将无效。
EXT文件系统挂载参数优化:

注意: 在ext4文件系统下，要获得最佳性能，则需要调整几个参数。这些选项在故障情况下通常是不安全的，并且将导致更多的数据丢失和损坏，对于单个broker故障，可以擦除磁盘并从群集重建副本，在多数情况下，多broker异常意味着潜在的文件系统损坏，无法轻易恢复。

data=writeback: Ext4默认为data = ordered，这使某些写入操作具有很强的顺序，在Kafka场景下其实不需要该参数，此设置消除了排序约束，并且似乎大大减少了延迟
Disabling journaling: 日志记录是一个折衷:它使服务器崩溃后重新引导更快，但它引入了大量额外的锁定，增加了写入性能的差异
commit=num_secs: 这调整了ext4提交到其元数据日志的频率。 将此值设置为较低的值可以减少崩溃期间未刷新数据的丢失。 将此值设置为较高的值将提高吞吐量。
nobh: 此设置控制在使用data=writeback模式时附加的排序保证，可以提高吞吐量和延迟
delalloc: 延迟分配意味着文件系统避免在物理写入发生之前分配任何块，此功能非常适合吞吐量