【Kafka系列】（二）Kafka的基本使用（上）

有的时候博客内容会有变动，首发博客是最新的，其他博客地址可能会未同步,认准https://blog.zysicyj.top

首发博客地址^[1]

文章更新计划^[2]

系列文章地址^[3]

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

操作系统

先说结论，Kafka 部署在 Linux 上要比 Windows 和 Mac 上性能高的多，主要是以下几个原因：

1. 操作系统优化：Linux 操作系统在网络和文件系统性能方面通常比 Windows 和 Mac 更优秀。Linux 内核对网络和磁盘 I/O 的处理更高效，能够更好地利用硬件资源，从而提高 Kafka 的性能。
   
2. 文件系统选择：Linux 上常用的文件系统如 ext4、XFS 等对大规模数据处理和高并发读写有更好的支持。而 Windows 上的 NTFS 文件系统在处理大量小文件和高并发读写时性能相对较差。
   
3. 网络栈性能：Linux 的网络栈在处理高并发连接和大规模数据传输时表现更出色。Linux 内核对网络协议栈的优化更多，能够更好地处理网络数据包，提高 Kafka 的吞吐量和响应速度。
   
4. 硬件资源管理：Linux 操作系统对硬件资源的管理更加灵活和高效。Linux 上的进程调度、内存管理等机制能够更好地利用多核处理器和大内存，提高 Kafka 的并发处理能力。
   
5. 社区支持度
   

I/O 模型

主流的 I/O 模型通常有以下五种类型：

1. 阻塞 I/O（Blocking I/O）：在进行 I/O 操作时，应用程序会被阻塞，直到数据准备好或者操作完成。这种模型是最简单的，但是会导致应用程序的性能下降，因为在等待 I/O 完成时，CPU 无法处理其他任务。
   
2. 非阻塞 I/O（Non-blocking I/O）：在进行 I/O 操作时，应用程序可以继续执行其他任务，而不会被阻塞。但是，如果数据还没有准备好或者操作还没有完成，应用程序需要不断地轮询来检查状态，这会导致 CPU 的资源浪费。
   
3. I/O 多路复用（I/O Multiplexing）：通过使用 select、poll 或者 epoll 等系统调用，应用程序可以同时监视多个文件描述符的状态，当任何一个文件描述符准备好进行 I/O 操作时，应用程序就可以进行相应的读写操作。这种模型可以有效地处理多个连接，提高系统的并发性能。
   
4. 信号驱动 I/O（Signal-driven I/O）：应用程序通过注册信号处理函数，在数据准备好时接收到一个信号，然后进行相应的读写操作。这种模型相比于非阻塞 I/O，减少了轮询的开销，但是仍然需要应用程序不断地检查数据是否准备好。
   
5. 异步 I/O（Asynchronous I/O）：应用程序发起一个 I/O 操作后，可以继续执行其他任务，当数据准备好或者操作完成时，操作系统会通知应用程序进行相应的读写操作。这种模型是最高效的，因为应用程序不需要进行轮询或者阻塞等待，可以充分利用 CPU 的资源。
   

你不必详细了解每一种模型的实现细节，通常情况下我们认为后一种模型会比前一种模型要高级，比如 epoll 就比 select 要好，了解到这一程度应该足以应付我们下面的内容了。

说了这么多，I/O 模型与 Kafka 的关系又是什么呢？实际上 Kafka 客户端底层使用了 Java 的 selector，selector 在 Linux 上的实现机制是 epoll，而在 Windows 平台上的实现机制是 select。因此在这一点上将 Kafka 部署在 Linux 上是有优势的，因为能够获得更高效的 I/O 性能。

零拷贝

Kafka 在 Linux 上支持零拷贝（Zero-copy）的主要原因是 Linux 操作系统提供了一些特性和系统调用，使得零拷贝成为可能。而 Windows 操作系统在设计上与 Linux 有所不同，因此不直接支持零拷贝。

零拷贝是一种优化技术，可以减少数据在内核空间和用户空间之间的拷贝次数，提高数据传输的效率。在传统的拷贝方式中，数据从磁盘读取到内核缓冲区，然后再从内核缓冲区拷贝到用户空间的应用程序缓冲区，这涉及到多次数据拷贝操作，增加了 CPU 和内存的开销。

在 Linux 上，零拷贝的实现主要依赖以下几个特性和系统调用：

1. 文件描述符（File Descriptor）：Linux 使用文件描述符来表示打开的文件，通过文件描述符可以进行文件的读写操作。
   
2. 内核缓冲区（Kernel Buffer）：Linux 内核提供了一块内存区域作为内核缓冲区，用于存放从磁盘读取的数据。
   
3. sendfile 系统调用：sendfile 系统调用可以在内核空间和用户空间之间直接传输数据，而无需经过用户空间缓冲区。
   

通过使用 sendfile 系统调用，Kafka 可以直接将数据从磁盘读取到内核缓冲区，然后通过网络发送给消费者，避免了数据在内核空间和用户空间之间的多次拷贝。

而在 Windows 上，没有类似于 Linux 的 sendfile 系统调用，因此无法直接实现零拷贝。在 Windows 上，数据需要经过内核空间和用户空间之间的多次拷贝，导致性能上的损失。

一句话总结一下，在 Linux 部署 Kafka 能够享受到零拷贝技术所带来的快速数据传输特性。

磁盘

先说结论：

• 追求性价比的公司可以不搭建 RAID，使用普通磁盘组成存储空间即可
• 使用机械磁盘完全能够胜任 Kafka 线上环境

为什么说 Kafka 可以不搭建 RAID 环境

1. 分布式架构 ：Kafka 采用分布式架构，将消息分散存储在多个 Broker 节点上。每个 Broker 节点都是独立的，它们之间相互复制消息，实现数据的冗余和高可用性。因此，即使某个节点的磁盘发生故障，其他节点仍然可以提供服务，不会导致数据丢失。
   
2. 数据复制 ：Kafka 使用副本机制来保证数据的可靠性。每个分区都可以配置多个副本，这些副本分布在不同的 Broker 节点上。当消息写入到 Leader 副本后，Kafka 会将消息复制到其他副本，确保数据的冗余存储。如果某个副本所在的磁盘发生故障，Kafka 会自动选择其他副本作为 Leader，保证数据的可用性。
   
3. 持久化存储 ：Kafka 将消息持久化存储在磁盘上，而不是仅保存在内存中。这样即使 Broker 节点发生故障，消息也不会丢失。Kafka 使用顺序写入的方式将消息追加到磁盘上的日志文件中，这种方式对磁盘的要求相对较低，不需要特别高的磁盘性能。
   
4. 水平扩展：Kafka 支持水平扩展，可以通过增加 Broker 节点来提高系统的吞吐量和容量。在扩展过程中，可以选择在新节点上添加磁盘，而不需要对现有节点进行改动。这种方式可以灵活地根据需求来调整磁盘的配置和容量。
   

为什么说使用机械磁盘完全能够胜任 Kafka 线上环境

Kafka 是一个高吞吐量、低延迟的分布式消息系统，它的性能和稳定性对于线上环境非常重要。虽然 SSD（固态硬盘）在性能方面有明显的优势，但机械磁盘仍然可以胜任 Kafka 线上环境的原因如下：

1. 顺序写入：Kafka 的特点之一是顺序写入，即消息按照顺序追加到日志文件中。机械磁盘在顺序写入方面的性能表现通常比较好，因为它们具有较大的磁道和扇区，可以更好地支持连续写入操作。
   
2. 容量成本低：相比于 SSD，机械磁盘的容量成本更低。对于大规模的 Kafka 集群，存储成本是一个重要的考虑因素。机械磁盘可以提供更大的存储容量，使得 Kafka 能够存储更多的消息数据。
   
3. 持久性和可靠性：机械磁盘通常具有更高的持久性和可靠性。它们在写入数据时，通常会将数据缓存在磁盘的缓存区中，然后再进行持久化写入。这种写入方式可以提供更好的数据可靠性，即使在断电等异常情况下，数据也不容易丢失。
   
4. 成熟稳定：机械磁盘是一种成熟的存储设备，已经在各种应用场景中得到广泛应用。相比之下，SSD 虽然在性能方面有优势，但在稳定性和寿命方面可能存在一些问题。对于对数据可靠性要求较高的线上环境，机械磁盘可能更受信任。
   

需要注意的是，尽管机械磁盘可以胜任 Kafka 线上环境，但在某些特定场景下，如对延迟要求非常高的应用，或者对存储容量要求非常大的应用，可能需要考虑使用 SSD 等更高性能的存储设备。此外，随着技术的发展，未来可能会有更多新型存储设备出现，对于 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。

带宽

举个例子，我们使用以下假设和计算：

1. 带宽资源：假设机房环境是千兆网络（1Gbps），即每秒处理 1Gb 的数据。
2. 带宽利用率：假设 Kafka 服务器最多使用 70%的带宽资源，即每秒最多使用 700Mb 的带宽。
3. 预留资源：为了避免网络丢包，我们额外预留了 2/3 的带宽资源，即单台服务器使用带宽 240Mbps。
4. 数据处理目标：在 1 小时内处理 1TB 的业务数据，即每秒需要处理 2336Mb 的数据。

根据以上计算，我们得出了需要 10 台 Kafka 服务器来完成这个业务目标。这个计算还没有考虑到消息的复制，如果消息需要额外复制两份，那么总的服务器台数还要乘以 3，即需要 30 台服务器。

在实际部署中，你可以根据自己的网络环境和业务需求进行调整和优化。

另外，如果你的环境中还涉及跨机房传输，那么带宽资源的瓶颈可能会更加明显。在跨机房传输的情况下，网络延迟和带宽限制都会对性能产生影响。你可能需要考虑使用更高带宽的网络或者采取其他优化措施来解决这个问题。

总结起来，对于带宽资源的规划，你需要考虑以下几个因素：

1. 网络带宽：根据网络环境确定每秒处理的数据量。
2. 带宽利用率：根据实际情况确定 Kafka 服务器使用的带宽比例。
3. 预留资源：为了避免网络丢包，额外预留一部分带宽资源。
4. 数据处理目标：根据业务需求确定每秒需要处理的数据量。
5. 消息复制：如果消息需要复制，考虑复制的数量。

根据以上因素，你可以计算出所需的 Kafka 服务器数量，并根据实际情况进行调整和优化。

小结