既然是集群, 必然有多个 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 种类型:
阻塞式 I/O
e.g. Java 中 Socket 的阻塞模式
非阻塞式 I/O
e.g. Java 中 Socket 的非阻塞模式
I/O 多路复用
e.g. Linux 中的系统调用 select 函数
信号驱动 I/O
e.g. epoll 系统调用则介于第三种和第四种模型之间
异步 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 核心技术与实战
来源: http://www.jianshu.com/p/207089f68916