Kafka线上环境部署

Kafka线上环境部署

集群环境规划

操作系统选型

I/O模型。当前主流的5种I/O模型：阻塞I/O、非阻塞I/O、I/O多路复用、信号驱动I/O和异步I/O，每一种I/O模型都有典型的使用场景，比如Socket的阻塞模式和非阻塞模式就对应I/O阻塞、非阻塞I/O，Linux的select函数属于I/O多路复用模型，Windows的IOCP属于异步I/O模型，Linux epoll兼具I/O多路复用、信号驱动I/O

Kafka clients底层网络库采用Java的Selector机制，在Linux上的实现是使用epoll，在Windows平台上，Java NIO的Selector底层是使用select模型而非IOCP实现，只有Java NIO2才使用IOCP，因此使用Linux系统能得到更高效的I/O处理能力

Kafka需要频繁通过网络与磁盘进行数据传输，大部分这样的操作都是通过Java的FileChannel.transferTo方法实现，在Linux平台上该方法底层会调用sendfile系统调用，即使用了Linux的零拷贝技术。直到Java 8u60版本Windows平台才正式让FileChannel的transferTo方法调用TransmitFile函数。

磁盘规划

Kafka的每条消息都必须被持久化到底层的存储中，并且只有被规定数量的broker成功接收后才能通知clients消息发送成功，因此消息越快被保存在磁盘上，处理client请求的延时越低，表现出来的用户体验也越好

机械硬盘（HDD）与固态硬盘（SSD）

• 机械硬盘成本低容量大，SSD通常有着极低的寻道时间和存取时间，性能好成本高。Kafka使用顺序写磁盘，因此机械硬盘频繁寻道的时间开销是很低的，这使得使用机械硬盘与使用SSD差距并不大。对于预算有限最求高性价比的公司而言，机械硬盘完全可以胜任

JBOD（Just Bunch Of Disks）与RAID（磁盘阵列）

• 常见的RAID是RAID 10，也称为RAID 1+0，它结合磁盘镜像和磁盘条带化两种技术共同保护数据，即实现了不错的性能也提供了很高的可靠性。但在空间上使用了磁盘镜像，因此整体磁盘使用率只有50%。除了提供数据冗余外，RAID 10

  还可以将数据自动地负载分布到多个磁盘上

  • Kafka在框架层面已经提供了两个特性：通过副本机制提供冗余和高可用性，以及通过分散在各个节点的领导者选举机制来实现负载均衡，因此RAID的优势就显得不那么明显了

  • 对于一般公司或组织而言，选择JBOD方案性价比更高，推荐用户为每个broker都配置多个日志路径，每个路径都独立挂载在不同的磁盘上，这使得多块物理磁盘同时执行物理I/O写操作，可以极大地加速Kafka消息生产速度

  • 尽量不要使用NAS这样的网络存储设备，NAS通常运行在低端的硬件上，这使得性能可能很差，平均延时有很大的不稳定性

  • 追求性价比的公司可以考虑使用JBOD。使用机械硬盘完全可以满足Kafka集群的使用，SSD更好

磁盘容量规划

让我们以一个实际的例子来看下应该如何思考这个问题。假设在业务场景中，clients每天会产生1亿条消息，每条消息保存两份并保存一周时间，平均一条消息的大小是1KB，那么我们需要为Kafka规划的磁盘空间为1亿 * 2 * 1KB / 1000 / 1000 = 200GB的磁盘空间，我们最好再额外预留10%的磁盘空间用于其它数据文件存储，因此这种场景下每天新发送的消息将占用210G左右磁盘空间，还需要保留一周的数据，所以整体磁盘容量规划是210 * 7 = 1.5T，再考虑压缩的情况，如果平均压缩比为0.5，那么整体磁盘容量就是0.75TB

磁盘容量的规划和以下多个因素有关

• 消息留存时间
• 平均消息大小
• 副本数
• 是否启用压缩

内存规划

Kafka会将消息写入page cache，之后由底层文件系统通过"冲刷"将消息持久化到磁盘，consumer在读取消息时也会首先尝试从该区域中查找，如果命中则直接从页缓存中获取。还需将page cache大小与实际线上环境中设置的日志段大小相比较，假设单个日志段文件大小设置为10GB，那么至少应该给予page cac