06 | Kafka线上集群部署方案怎么做？

---

Kafka 核心技术与实战

Kafka的基本使用

06 | Kafka线上集群部署方案怎么做？

线上环境需要仔细地考量各种因素，结合自身的业务需求而制定。下面就分别从操作系统、磁盘、磁盘容量和带宽等方面来讨论一下。

操作系统

Kafka 不是 JVM 系的大数据框架吗？Java 又是跨平台的语言，把 Kafka 安装到不同的操作系统上会有什么区别吗？

Kafka 由 Scala 语言和 Java 语言编写而成，编译之后的源代码就是普通的“.class”文件。本来部署到哪个操作系统应该都是一样的，但是不同操作系统的差异还是给 Kafka 集群带来了相当大的影响。目前常见的操作系统有 3 种：Linux、Windows 和 macOS。

如果考虑操作系统与 Kafka 的适配性，Linux 系统显然要比其他两个特别是 Windows 系统更加适合部署 Kafka。主要是在下面这三个方面上，Linux 的表现更胜一筹。

• I/O 模型的使用
• 数据网络传输效率
• 社区支持度

主流的 I/O 模型通常有 5 种类型：阻塞式 I/O、非阻塞式 I/O、I/O 多路复用、信号驱动 I/O 和异步 I/O。每种 I/O 模型都有各自典型的使用场景，比如 Java 中 Socket 对象的阻塞模式和非阻塞模式就对应于前两种模型；而 Linux 中的系统调用 select 函数就属于 I/O 多路复用模型；大名鼎鼎的 epoll 系统调用则介于第三种和第四种模型之间；至于第五种模型，其实很少有 Linux 系统支持，反而是 Windows 系统提供了一个叫 IOCP 线程模型属于这一种。

I/O 性能。Kafka 客户端底层使用了 Java 的 selector，selector 在 Linux 上的实现机制是 epoll，而在 Windows 平台上的实现机制是 select。因此将 Kafka 部署在 Linux 上是有优势的，因为能够获得更高效的 I/O 性能。

网络传输效率。Kafka 生产和消费的消息都是通过网络传输的，消息保存在磁盘，故 Kafka 需要在磁盘和网络间进行大量数据传输。Linux 平台实现了这样的零拷贝机制，就是当数据在磁盘和网络进行传输时避免昂贵的内核态数据拷贝从而实现快速的数据传输。因此，在 Linux 部署 Kafka 能够享受到零拷贝技术所带来的快速数据传输特性。

零拷贝是指不需要 cpu 参与内存中的数据拷贝操作（内核态数据拷贝操作），对操做系统来讲就是零拷贝了。数据只需要从磁盘复制到内核，再从内核复制到协议引擎，减少了从内核到用户空间，从用户空间到 socket 缓冲两次复制。从磁盘复制到内核缓冲区是通过 DMA 引擎来做而不是 cpu，同样的，从 内核缓冲区到协议引擎也是由 DMA 引擎来做，这样就节省了 cpu 的工作。

社区的支持度。社区目前对 Windows 平台上发现的 Kafka Bug 不做任何承诺。因此，Windows 平台上部署 Kafka 只适合于个人测试或用于功能验证，千万不要应用于生产环境。

磁盘

Kafka 大量使用磁盘不假，可它使用的方式多是顺序读写操作，一定程度上规避了机械磁盘最大的劣势，即随机读写操作慢。从这一点上来说，使用 SSD 似乎并没有太大的性能优势，毕竟从性价比上来说，机械磁盘物美价廉，而它因易损坏而造成的可靠性差等缺陷，又由 Kafka 在软件层面提供机制来保证，故使用普通机械磁盘是很划算的。

关于磁盘选择另一个经常讨论的话题就是到底是否应该使用磁盘阵列（RAID）。使用 RAID 的两个主要优势在于：

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

RAID 就是一种由多块廉价磁盘构成的冗余阵列，在操作系统下是作为一个独立的大型存储设备出现。 RAID 可以充分发挥出多块硬盘的优势，可以提升硬盘速度，增大容量 , 提供容错功能够确保数据安全性，易于管理的优点，在任何一块硬盘出现问题的情况下都可以继续工作，不会受到损坏硬盘的影响。

就 Kafka 而言，一方面 Kafka 自己实现了冗余机制来提供高可靠性；另一方面通过分区的概念，Kafka 也能在软件层面自行实现负载均衡。如此说来 RAID 的优势就没有那么明显了。当然，并不是说 RAID 不好，实际上依然有很多大厂确实是把 Kafka 底层的存储交由 RAID 的，只是目前 Kafka 在存储这方面提供了越来越便捷的高可靠性方案，因此在线上环境使用 RAID 似乎变得不是那么重要了。综合以上的考量，给出的建议是：

• 追求性价比的公司可以不搭建 RAID，使用普通磁盘组成存储空间即可。
• 使用机械磁盘完全能够胜任 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 服务器的数量。假设公司的机房环境是千兆网络，即 1Gbps，现在有个业务，其业务目标或 SLA 是在 1 小时内处理 1TB 的业务数据。那么需要多少台 Kafka 服务器来完成这个业务？

由于带宽是 1Gbps，即每秒处理 1Gb 的数据，假设每台 Kafka 服务器都是安装在专属的机器上，也就是说每台 Kafka 机器上没有混布其他服务，毕竟真实环境中不建议这么做。通常情况下只能假设 Kafka 会用到 70% 的带宽资源，因为总要为其他应用或进程留一些资源。

根据实际使用经验，超过 70% 的阈值就有网络丢包的可能性了，故 70% 的设定是一个比较合理的值，也就是说单台 Kafka 服务器最多也就能使用大约 700Mb 的带宽资源。

这只是它能使用的最大带宽资源，不能让 Kafka 服务器常规性使用这么多资源，故通常要再额外预留出 2/3 的资源，即单台服务器使用带宽 700Mb / 3 ≈ 240Mbps。（2/3 其实是相当保守的，可以结合自己机器的使用情况酌情减少此值。）

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

1T=1024G，1G=1024MB，1024 * 1024/3600(s)=291Mb/s 带宽处理单位是 bit，故每秒处理291 * 8 = 2328mbps 数据。