上文中讲到参数配置,本文主要针对磁盘操作系统带宽分析线上部署Kafka的方案。
操作系统
Kafka主要是scala编写的运行在JVM之上的，我们知道JVM有一个特性叫做一次编译到处运行的特点那么为什么我们还要对操作系统进行选择呢。主要有如下三点考虑。
- I/O 模型
什么是 I/O 模型呢？你可以近似地认为 I/O 模型就是操作系统执行 I/O 指令的方法。
主流的 I/O 模型通常有 5 种类型：阻塞式 I/O、非阻塞式 I/O、I/O 多路复用、信号驱动I/O 和异步 I/O。
每种 I/O 模型都有各自典型的使用场景。通常我们认为后面比前面效率要高。
说了这么多，I/O 模型与 Kafka 的关系又是什么呢？实际上 Kafka 客户端底层使用了 Java的 selector，selector 在 Linux 上的实现机制是 epoll，而在 Windows 平台上的实现机制I/O 模型的使用是 select。epoll 大约在第四位 而select在第三位。具体详细信息这里就不介绍了。因此在这一点上将 Kafka 部署在Linux 上是有优势的，因为能够获得更高效的 - 数据传输速率
我们知道Kafka 使用网络传输数据，将接收到的数据存到磁盘中。即Kafka 需要在磁盘和网络间进行大量数据传输。
如果熟悉Linux 可能会听过零拷贝技术。就是当数据在磁盘和网络进行传输时避免昂贵的内核态数据拷贝从而实现快速地数据传输, 而windosWindows 平台上必须要等到 Java 8 的 60 更新版本才能享受到这个福利。 - 社区支持度
在众多操作系统中Linux系统社区支持度是最高的也就意味着，你所遇到的问题其他人很有可能遇到过并且有了解决方案和对bug修复也是最快的
磁盘
上面也提到了 Kafka 会将接收到的数据写入硬盘, 所以硬盘的好坏直接影响着Kafka集群的效率。
预算足够的话直接SSD没有什么好想的,应为SSD 比机械硬盘数据的读写速率和可靠性都要强多了。缺点就是贵。
如果预算方面紧张的话也可以用机械硬盘来实现为什么呢。
首先关于数据可靠性的方面Kafka通过实现多副本和多分区负载均衡的方式从软件的方面弥补了这个缺点。
关于数据的读写速率 Kafka 使用的方式多是顺序读写操作，一定程度上规避了机械磁盘最大的劣势，即随机读写操作慢，速度的差距没有想象中的大。
关于磁盘的方面有一个比较重要的问题就是怎么去预估集群需要的存储空间呢。
下面给出一个例子仅供参考。
假设你所在公司有个业务每天需要向Kafka 集群发送 1 亿条消息，每条消息保存两份以防止数据丢失，另外消息默认保存两周时间。现在假设消息的平均大小是 1KB，那么你能说出你的 Kafka 集群需要为这个业务预留多少磁盘空间吗？
我们来计算一下：每天 1 亿条 1KB 大小的消息，保存两份且留存两周的时间，那么总的空间大小就等于 1 亿 * 1KB * 2 / 1000 / 1000 = 200GB。一般情况下 Kafka 集群除了消息数据还有其他类型的数据，比如索引数据等，故我们再为这些数据预留出 10% 的磁盘空间，因此总的存储容量就是 220GB。既然要保存两周，那么整体容量即为 220GB * 14，大约 3TB 左右。Kafka 支持数据的压缩，假设压缩比是 0.75，那么最后你需要规划的存储空间就是 0.75 * 3 = 2.25TB
带宽
对于Kafka这样的通过网络进行大量数据传输的框架来说带宽很容易成为性能瓶颈。
像上面的磁盘例子一样我们同样也来举一个例子算下需要的带宽。
假设你公司的机房环境是千兆网络，即 1Gbps，现在你有个业务，其业务目标或 SLA 是在 1 小时内处理 1TB 的业务数据。那么问题来了，你到底需要多少台 Kafka 服务器来完成这个业务呢？
让我们来计算一下，由于带宽是 1Gbps，即每秒处理 1Gb 的数据，假设每台 Kafka 服务器都是安装在专属的机器上，也就是说每台 Kafka 机器上没有混布其他服务，毕竟真实环境中很少有这么做的。有人测试过大约使用的带宽超过70%容易出现丢包的风险。也就是说单台 Kafka 服务器最多也就能使用大约 700Mb 的带宽资源。稍等，这只是它能使用的最大带宽资源，你不能让 Kafka 服务器常规性使用这么多资源,因为总要给其他系统应用留一些就1/2 的资源(假设一半一半吧)，即单台服务器使用带宽 700Mb / 2 = 350Mbps。有了 350Mbps，我们就可以计算 1 小时内处理 1TB 数据所需的服务器数量了。根据这个目标，我们每秒需要处理 2336Mb(10241024/36008) 的数据，除以 350，约等于 7 台服务器。如果消息有副本的话假设有2个副本则还需要额外复制两份，那么总的服务器台数还要乘以 3，即 21 台。
