Kafka 的生产集群部署

方案背景

假设每天集群需要承载 10 亿数据。一天 24 小时，晚上 12 点到凌晨 8 点几乎没多少数据。

使用二八法则估计，也就是 80%的数据（8 亿）会在 16 个小时涌入，而且 8 亿的 80%的数据（6.4 亿）会在这 16 个小时的 20%时间（3 小时）涌入。

QPS 计算公式：640000000 ÷ (3x60x60) = 60000，也就是说高峰期的时候 Kafka 集群要扛住每秒 6 万的并发。

磁盘空间计算，每天 10 亿数据，每条 50kb，也就是 46T 的数据。保存 2 个副本（在上一篇中也提到过其实两个副本会比较好，因为 follower 需要去 leader 那里同步数据，大数据培训同步数据的过程需要耗费网络，而且需要磁盘空间，但是这个需要根据实际情况考虑），46 2 = 92T，保留最近 3 天的数据。故需要 92 3 = 276T。

QPS 方面

部署 Kafka，Hadoop，MySQL……等核心分布式系统，一般建议直接采用物理机，抛弃使用一些低配置的虚拟机的想法。高并发这个东西，不可能是说，你需要支撑 6 万 QPS，你的集群就刚好把这 6 万并发卡的死死的。加入某一天出一些活动让数据量疯狂上涨，那整个集群就会垮掉。

但是，假如说你只要支撑 6w QPS，单台物理机本身就能扛住 4~5 万的并发。所以这时 2 台物理机绝对绝对够了。但是这里有一个问题，我们通常是建议，公司预算充足，尽量是让高峰 QPS 控制在集群能承载的总 QPS 的 30%左右（也就是集群的处理能力是高峰期的 3~4 倍这个样子），所以我们搭建的 kafka 集群能承载的总 QPS 为 20 万~30 万才是安全的。所以大体上来说，需要 5~7 台物理机来部署，基本上就很安全了，每台物理机要求吞吐量在每秒 4~5 万条数据就可以了，物理机的配置和性能也不需要特别高。

磁盘方面

磁盘数量

需要 5 台物理机的情况，需要存储 276T 的数据，平均下来差不多一台 56T 的数据。这个具体看磁盘数和盘的大小。

SAS 还是 SSD

现在我们需要考虑一个问题：是需要 SSD 固态硬盘，还是普通机械硬盘？

SSD 就是固态硬盘，比机械硬盘要快，那么到底是快在哪里呢？其实 SSD 的快主要是快在磁盘随机读写，就要对磁盘上的随机位置来读写的时候，SSD 比机械硬盘要快。比如说 MySQL 这种就应该使用 SSD 了（MySQL 需要随机读写）。北京大数据培训比如说我们在规划和部署线上系统的 MySQL 集群的时候，一般来说必须用 SSD，性能可以提高很多，这样 MySQL 可以承载的并发请求量也会高很多，而且 SQL 语句执行的性能也会提高很多。

因为写磁盘的时候 Kafka 是顺序写的。机械硬盘顺序写的性能机会跟内存读写的性能是差不多的，所以对于 Kafka 集群来说其实使用机械硬盘就可以了。如果是需要自己创业或者是在公司成本不足的情况下，经费是能够缩减就尽量缩减的。

内存角度

JVM 非常怕出现 full gc 的情况。Kafka 自身的 JVM 是用不了过多堆内存的，因为 Kafka 设计就是规避掉用 JVM 对象来保存数据，避免频繁 full gc 导致的问题，所以一般 Kafka 自身的 JVM 堆内存，分配个 10G 左右就够了，剩下的内存全部留给 OS cache。

那服务器需要多少内存呢。我们估算一下，大概有 100 个 topic，所以要保证有 100 个 topic 的 leader partition 的数据在操作系统的内存里。100 个 topic，一个 topic 有 5 个 partition。那么总共会有 500 个 partition。每个 partition 的大小是 1G（在上一篇中的日志分段存储中规定了.log 文件不能超过 1 个 G），我们有 2 个副本，也就是说要把 100 个 topic 的 leader partition 数据都驻留在内存里需要 1000G 的内存。

我们现在有 5 台服务器，所以平均下来每天服务器需要 200G 的内存，但是其实 partition 的数据我们没必要所有的都要驻留在内存里面，只需要 25%的数据在内存就行，200G * 0.25 = 50G 就可以了（因为在集群中的生产者和消费者几乎也算是实时的，基本不会出现消息积压太多的情况）。所以一共需要 60G（附带上刚刚的 10G Kafka 服务）的内存，故我们可以挑选 64G 内存的服务器也行，大不了 partition 的数据再少一点在内存，当然如果能够提供 128G 内存那就更好。

CPU core

CPU 规划，主要是看你的这个进程里会有多少个线程，线程主要是依托多核 CPU 来执行的，如果你的线程特别多，但是 CPU 核很少，就会导致你的 CPU 负载很高，会导致整体工作线程执行的效率不太高，上一篇的 Kafka 的网络设计中讲过 Kafka 的 Broker 的模型。acceptor 线程负责去接入客户端的连接请求，但是他接入了之后其实就会把连接分配给多个 processor，默认是 3 个，但是一般生产环境建议大家还是多加几个，整体可以提升 kafka 的吞吐量比如说你可以增加到 6 个，或者是 9 个。另外就是负责处理请求的线程，是一个线程池，默认是 8 个线程，在生产集群里，建议大家可以把这块的线程数量稍微多加个 2 倍~3 倍，其实都正常，比如说搞个 16 个工作线程，24 个工作线程。

后台会有很多的其他的一些线程，比如说定期清理 7 天前数据的线程，Controller 负责感知和管控整个集群的线程，副本同步拉取数据的线程，这样算下来每个 broker 起码会有上百个线程。根据经验 4 个 CPU core，一般来说几十个线程，在高峰期 CPU 几乎都快打满了。8 个 CPU core，也就能够比较宽裕的支撑几十个线程繁忙的工作。所以 Kafka 的服务器一般是建议 16 核，基本上可以 hold 住一两百线程的工作。当然如果可以给到 32 CPU core 那就最好不过了。

网卡

现在的网基本就是千兆网卡（1GB / s），还有万兆网卡（10GB / s）。kafka 集群之间，broker 和 broker 之间是会做数据同步的，因为 leader 要同步数据到 follower 上去，他们是在不同的 broker 机器上的，broker 机器之间会进行频繁的数据同步，传输大量的数据。那每秒两台 broker 机器之间大概会传输多大的数据量？

高峰期每秒大概会涌入 6 万条数据，约每天处理 10000 个请求，每个请求 50kb，故每秒约进来 488M 数据，我们还有副本同步数据，故高峰期的时候需要 488M * 2 = 976M/s 的网络带宽，所以在高峰期的时候，使用千兆带宽，网络还是非常有压力的。