Kafka实战(七) - 优雅地部署 Kafka 集群

既然是集群，必然有多个Kafka节点，只有单节点构成的Kafka伪集群只能用于平常测试，不可能知足线上生产需求。
真正的线上环境须要考量各类因素，结合自身的业务需求而制定。看一些考虑因素（如下顺序，但是分了顺序的哦）

1 操做系统 - OS

可能你会问Kafka不是JVM上的大数据框架吗？Java又是跨平台的语言，把Kafka安装到不一样的操做系统上会有什么区别吗？
区别至关大！

确实，Kafka由Scala/Java编写，编译后源码就是“.class”文件。
原本部署到哪一个OS应该同样，可是不一样OS的差别仍是给Kafka集群带来了至关大的影响。
毋庸置疑，部署在Linux上的生产环境是最多的。

考虑操做系统与Kafka的适配性，Linux系统显然要比其余两个特别是Windows系统更加适合部署Kafka。可具体缘由你能谈笑风生吗？

1.1 I/O模型

I/O模型能够近似认为I/O模型就是OS执行I/O指令的方法。
主流的I/O模型一般有5种类型：

1. 阻塞式I/O
   e.g. Java中Socket的阻塞模式
2. 非阻塞式I/O
   e.g. Java中Socket的非阻塞模式
3. I/O多路复用
   e.g. Linux中的系统调用select函数
4. 信号驱动I/O
   e.g. epoll系统调用则介于第三种和第四种模型之间
5. 异步I/O
   e.g. 不多有Linux支持，反而Windows系统提供了一个叫IOCP线程模型属于该类

我在这里不详细展开每一种模型的实现细节，由于那不是本文重点。

言归正传，I/O模型与Kafka的关系几何？
Kafka Client 底层使用了Java的selector，而selector

• 在Linux上的实现机制是epoll
• 在Windows平台上的实现机制是select

所以在这一点上将Kafka部署在Linux上是有优点的，可以得到更高效的I/O性能。

1.2 数据网络传输效率

Kafka生产和消费的消息都是经过网络传输的，而消息保存在哪里呢？
确定是磁盘！
故Kafka须要在磁盘和网络间进行大量数据传输。
Linux有个零拷贝（Zero Copy）技术，就是当数据在磁盘和网络进行传输时避免昂贵内核态数据拷贝从而实现快速数据传输。Linux平台实现了这样的零拷贝机制，但有些使人遗憾的是在Windows平台上必需要等到Java 8的60更新版本才能“享受”到。

一句话，在Linux部署Kafka可以享受到零拷贝技术所带来的快速数据传输特性带来的极致快感。

1.3 社区生态

社区目前对Windows平台上发现的Kafka Bug不作任何承诺。所以，Windows平台上部署Kafka只适合于我的测试或用于功能验证，千万不要应用于生产环境。

2 磁盘

2.1 灵魂拷问：机械硬盘 or 固态硬盘

• 前者便宜且容量大，但易坏！
• 后者性能优点大，可是贵！

建议是使用普通机械硬盘便可。

• Kafka虽然大量使用磁盘，可可能是顺序读写操做，必定程度上规避了机械磁盘最大的劣势，即随机读写慢。从这一点上来讲，使用SSD并无太大性能优点，机械磁盘物美价廉
• 而它因易损坏而形成的可靠性差等缺陷，又由Kafka在软件层面提供机制来保证

2.2 是否应该使用磁盘阵列（RAID）

使用RAID的两个主要优点在于：

• 提供冗余的磁盘存储空间
• 提供负载均衡

不过就Kafka而言

• Kafka本身实现了冗余机制提供高可靠性
• 经过分区的设计，也能在软件层面自行实现负载均衡

如此说来RAID的优点也就没有那么明显了。虽然实际上依然有不少大厂确实是把Kafka底层的存储交由RAID的，只是目前Kafka在存储这方面提供了愈来愈便捷的高可靠性方案，所以在线上环境使用RAID彷佛变得不是那么重要了。
综上，追求性价比的公司能够不搭建RAID，使用普通磁盘组成存储空间便可。使用机械磁盘彻底可以胜任Kafka线上环境。

2.3 磁盘容量

集群到底须要多大？
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

总之在规划磁盘容量时你须要考虑下面这几个元素：

• 新增消息数
• 消息留存时间
• 平均消息大小
• 备份数
• 是否启用压缩

3 带宽

对于Kafka这种经过网络进行大数据传输的框架，带宽容易成为瓶颈。
普通的以太网络，带宽主要有两种：1Gbps的千兆网络和10Gbps的万兆网络，特别是千兆网络应该是通常公司网络的标准配置了
以千兆网络为例，说明带宽资源规划。

真正要规划的是所需的Kafka服务器的数量。
假设机房环境是千兆网络，即1Gbps，如今有业务，其目标或SLA是在1小时内处理1TB的业务数据。
那么问题来了，你到底须要多少台Kafka服务器来完成这个业务呢？

计算

带宽1Gbps，即每秒处理1Gb数据
假设每台Kafka服务器都是安装在专属机器，即每台Kafka机器上没有混入其余服务
一般状况下你只能假设Kafka会用到70%的带宽资源，由于总要为其余应用或进程留一些资源。超过70%的阈值就有网络丢包可能性，故70%的设定是一个比较合理的值，也就是说单台Kafka服务器最多也就能使用大约700Mb带宽。

这只是它能使用的最大带宽资源，你不能让Kafka服务器常规性使用这么多资源，故一般要再额外预留出2/3的资源，即
单台服务器使用带宽700Mb / 3 ≈ 240Mbps
这里的2/3实际上是至关保守的，能够结合机器使用状况酌情减小该值

有了240Mbps，能够计算1小时内处理1TB数据所需的服务器数量了。
根据这个目标，每秒须要处理2336Mb的数据，除以240，约等于10台服务器。
若是消息还须要额外复制两份，那么总的服务器台数还要乘以3，即30台。

总结

与其盲目上马一套Kafka环境而后过后费力调整，不如在一开始就思考好实际场景下业务所需的集群环境。在考量部署方案时须要通盘考虑，不能仅从单个维度上进行评估。

参考

• Linux内核模型架构
• Kafka核心技术与实战