计划背景
假如每天集群须要承载 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 的网络带宽，所以在高峰期的时候，应用千兆带宽，网络还是十分有压力的。