操作系统
主要是在下面这三个方面上，Linux的表现更胜一筹。
1、I/O模型的使用：
什么是I/O模型呢？你可以近似地认为I/O模型就是操作系统执行I/O指令的方法。
- 主流的I/O模型通常有5种类型：
- 阻塞式I/O：Java中Socket对象
- 非阻塞式I/O：Java中Socket对象
- I/O多路复用：Linux中的系统调用select函数
- 信号驱动I/O：大名鼎鼎的epoll系统调用。I/O模型与Kafka的关系又是什么呢？实际上Kafka客户端底层使用了Java的selector，selector在Linux上的实现机制是epoll，而在Windows平台上的实现机制是select。通情况下第四模型比第三模型要高级，比如epoll就比select要好。因此在这一点上将Kafka部署在Linux上是有优势的，因为能够获得更高效的I/O性能。 异步I/O：Windows系统提供了一个叫做IOCP线程。 2、数据网络传输效率——Kafka需要在磁盘和网络间进行大量数据传输 如果你熟悉Linux,你肯定听过零拷贝(ZeroCopy) 技术，就是当数据在磁盘和网络进行传输时避免昂贵的内核态数据拷贝从而实现快速地数据传输。Linux 平台实现了这样的零拷贝机制。所以，在Linux部署Kafka能够享受到零拷贝技术所带来的快速数据传输特性。 3、社区支持度
磁盘
HDD机械磁盘——成本低且容量大，但易损坏
SSD固态硬盘——性能优势大，不过单价高
磁盘容量
Kafka集群到底需要多大的存储空间？这是一个非常经典的规划问题。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这种通过网络大量进行数据传输的框架而言，带宽特别容易成为瓶颈。事实上，在我接触的真实案例当中，带宽资源不足导致Kafka出现性能问题的比例至少占60%以上。如果你的环境中还涉及跨机房传输，那么情况可能就更糟了。
带宽类型：
1Gbps的千兆网络
10Gbps的万兆网络
节点数评估：
假如我们要一个小时处理1TB的数据，单节点宽带使用70%（700Mb），则Kafka使用1/3（700/3）=240Mb。由此可以得出1秒需要处理多少数据：也就是1000_1000/(60_60)=277MB，记住这是MB不是Mb，277MB*8=2216Mb(MB与Mb之间的转化是1B=8b)。单节点能处理240Mb的数据，现在有2216Mb的数据，我们需要的节点数量为: 2216/240=10(大概需要10台服务)。如果消息要额外复制两份，那么总的服务器数据需要乘以3=30
