一、Kafka 利用
本文次要总结当 Kafka 集群流量达到 万亿级记录 / 天或者十万亿级记录 / 天 甚至更高后，咱们须要具备哪些能力能力保障集群高可用、高牢靠、高性能、高吞吐、平安的运行。
这里总结内容次要针对 Kafka2.1.1 版本，包含集群版本升级、数据迁徙、流量限度、监控告警、负载平衡、集群扩 / 缩容、资源隔离、集群容灾、集群平安、性能优化、平台化、开源版本缺点、社区动静等方面。本文次要是介绍外围脉络，不做过多细节解说。上面咱们先来看看 Kafka 作为数据中枢的一些外围利用场景。
下图展现了一些支流的数据处理流程，Kafka 起到一个数据中枢的作用。
接下来看看咱们 Kafka 平台整体架构；
1.1 版本升级
1.1.1 开源版本如何进行版本滚动降级与回退
官网地址：http://kafka.apache.org
1.1.1.2 源码革新如何降级与回退
因为在降级过程中，必然呈现新旧代码逻辑交替的状况。集群外部局部节点是开源版本，另外一部分节点是革新后的版本。所以，须要思考在降级过程中，新旧代码混合的状况，如何兼容以及呈现故障时如何回退。
1.2 数据迁徙
因为 Kafka 集群的架构特点，这必然导致集群内流量负载不平衡的状况，所以咱们须要做一些数据迁徙来实现集群不同节点间的流量平衡。Kafka 开源版本为数据迁徙提供了一个脚本工具“bin/kafka-reassign-partitions.sh”，如果本人没有实现主动负载平衡，能够应用此脚本。
开源版本提供的这个脚本生成迁徙打算齐全是人工干预的，当集群规模十分大时，迁徙效率变得十分低下，个别以天为单位进行计算。当然，咱们能够实现一套自动化的平衡程序，当负载平衡实现自动化当前，根本应用调用外部提供的 API，由程序去帮咱们生成迁徙打算及执行迁徙工作。须要留神的是，迁徙打算有指定数据目录和不指定数据目录两种，指定数据目录的须要配置 ACL 平安认证。
官网地址：http://kafka.apache.org
1.2.1 broker 间数据迁徙
不指定数据目录
// 未指定迁徙目录的迁徙打算
{
"version":1,
"partitions":[{"topic":"yyj4","partition":0,"replicas":[1000003,1000004]},
{"topic":"yyj4","partition":1,"replicas":[1000003,1000004]},
{"topic":"yyj4","partition":2,"replicas":[1000003,1000004]}
]
}
指定数据目录
// 指定迁徙目录的迁徙打算
{
"version":1,
"partitions":[{"topic":"yyj1","partition":0,"replicas":[1000006,1000005],"log_dirs":["/data1/bigdata/mydata1","/data1/bigdata/mydata3"]},
{"topic":"yyj1","partition":1,"replicas":[1000006,1000005],"log_dirs":["/data1/bigdata/mydata1","/data1/bigdata/mydata3"]},
{"topic":"yyj1","partition":2,"replicas":[1000006,1000005],"log_dirs":["/data1/bigdata/mydata1","/data1/bigdata/mydata3"]}
]
}
1.2.2 broker 外部磁盘间数据迁徙
生产环境的服务器个别都是挂载多块硬盘，比方 4 块 /12 块等；那么可能呈现在 Kafka 集群外部，各 broker 间流量比拟平衡，然而在 broker 外部，各磁盘间流量不平衡，导致局部磁盘过载，从而影响集群性能和稳固，也没有较好的利用硬件资源。在这种状况下，咱们就须要对 broker 外部多块磁盘的流量做负载平衡，让流量更平均的散布到各磁盘上。
1.2.3 并发数据迁徙
以后 Kafka 开源版本（2.1.1 版本）提供的正本迁徙工具“bin/kafka-reassign-partitions.sh”在同一个集群内只能实现迁徙工作的串行。对于集群内曾经实现多个资源组物理隔离的状况，因为各资源组不会相互影响，然而却不能敌对的进行并行的提交迁徙工作，迁徙效率有点低下，这种有余直到 2.6.0 版本才得以解决。如果须要实现并发数据迁徙，能够抉择降级 Kafka 版本或者批改 Kafka 源码。
1.2.4 终止数据迁徙
以后 Kafka 开源版本（2.1.1 版本）提供的正本迁徙工具“bin/kafka-reassign-partitions.sh”在启动迁徙工作后，无奈终止迁徙。当迁徙工作对集群的稳定性或者性能有影响时，将变得大刀阔斧，只能期待迁徙工作执行结束（胜利或者失败），这种有余直到 2.6.0 版本才得以解决。如果须要实现终止数据迁徙，能够抉择降级 Kafka 版本或者批改 Kafka 源码。
1.3 流量限度
1.3.1 生产生产流量限度
常常会呈现一些突发的，不可预测的异样生产或者生产流量会对集群的 IO 等资源产生微小压力，最终影响整个集群的稳固与性能。那么咱们能够对用户的生产、生产、正本间数据同步进行流量限度，这个限流机制并不是为了限度用户，而是防止突发的流量影响集群的稳固和性能，给用户能够更好的服务。
如下图所示，节点入流量由 140MB/ s 左右突增到 250MB/s，而出流量则从 400MB/ s 左右突增至 800MB/s。如果没有限流机制，那么集群的多个节点将有被这些异样流量打挂的危险，甚至造成集群雪崩。
图片生产 / 生产流量限度官网地址：点击链接
对于生产者和消费者的流量限度，官网提供了以下几种维度组合进行限度（当然，上面限流机制存在肯定缺点，前面在“Kafka 开源版本性能缺点”咱们将提到）：
/config/users/<user>/clients/<client-id> // 依据用户和客户端 ID 组合限流
/config/users/<user>/clients/<default>
/config/users/<user>// 依据用户限流 这种限流形式是咱们最罕用的形式
/config/users/<default>/clients/<client-id>
/config/users/<default>/clients/<default>
/config/users/<default>
/config/clients/<client-id>
/config/clients/<default>在启动 Kafka 的 broker 服务时须要开启 JMX 参数配置，不便通过其余应用程序采集 Kafka 的各项 JMX 指标进行服务监控。当用户须要调整限流阈值时，依据单个 broker 所能接受的流量进行智能评估，无需人工干预判断是否能够调整；对于用户流量限度，次要须要参考的指标包含以下两个：
（1）生产流量指标：ObjectName：kafka.server:type=Fetch,user=acl 认证用户名称 属性：byte-rate（用户在以后 broker 的出流量）、throttle-time（用户在以后 broker 的出流量被限度工夫）（2）生产流量指标：ObjectName：kafka.server:type=Produce,user=acl 认证用户名称 属性：byte-rate（用户在以后 broker 的入流量）、throttle-time（用户在以后 broker 的入流量被限度工夫）
1.3.2 follower 同步 leader/ 数据迁徙流量限度
正本迁徙 / 数据同步流量限度官网地址：链接
波及参数如下：
// 正本同步限流配置共波及以下 4 个参数
leader.replication.throttled.rate
follower.replication.throttled.rate
leader.replication.throttled.replicas
follower.replication.throttled.replicas辅助指标如下：
（1）正本同步出流量指标：ObjectName：kafka.server:type=BrokerTopicMetrics,name=ReplicationBytesOutPerSec（2）正本同步入流量指标：ObjectName：kafka.server:type=BrokerTopicMetrics,name=ReplicationBytesInPerSec
1.4 监控告警
对于 Kafka 的监控有一些开源的工具可用应用，比方上面这几种：
Kafka Manager；
Kafka Eagle；
Kafka Monitor；
KafkaOffsetMonitor；
咱们曾经把 Kafka Manager 作为咱们查看一些根本指标的工具嵌入平台，然而这些开源工具不能很好的融入到咱们本人的业务零碎或者平台上。所以，咱们须要本人去实现一套粒度更细、监控更智能、告警更精准的零碎。其监控覆盖范围应该包含根底硬件、操作系统（操作系统偶然呈现零碎过程 hang 住状况，导致 broker 假死，无奈失常提供服务）、Kafka 的 broker 服务、Kafka 客户端应用程序、zookeeper 集群、上下游全链路监控。
1.4.1 硬件监控
网络监控：
外围指标包含网络入流量、网络出流量、网络丢包、网络重传、处于 TIME.WAIT 的 TCP 连接数、交换机、机房带宽、DNS 服务器监控（如果 DNS 服务器异样，可能呈现流量黑洞，引起大面积业务故障）等。
磁盘监控：
外围指标包含监控磁盘 write、磁盘 read（如果生产时没有延时，或者只有大量延时，个别都没有磁盘 read 操作）、磁盘 ioutil、磁盘 iowait（这个指标如果过高阐明磁盘负载较大）、磁盘存储空间、磁盘坏盘、磁盘坏块 / 坏道（坏道或者坏块将导致 broker 处于半死不活状态，因为有 crc 校验，消费者将被卡住）等。
CPU 监控：
监控 CPU 闲暇率 / 负载，主板故障等，通常 CPU 使用率比拟低不是 Kafka 的瓶颈。
内存 / 替换区监控：
内存使用率，内存故障。个别状况下，服务器上除了启动 Kafka 的 broker 时调配的堆内存以外，其余内存根本全副被用来做 PageCache。
缓存命中率监控：
因为是否读磁盘对 Kafka 的性能影响很大，所以咱们须要监控 Linux 的 PageCache 缓存命中率，如果缓存命中率高，则阐明消费者根本命中缓存。
具体内容请阅读文章：《Linux Page Cache 调优在 Kafka 中的利用》。
系统日志：
咱们须要对操作系统的谬误日志进行监控告警，及时发现一些硬件故障。
1.4.2 broker 服务监控
broker 服务的监控，次要是通过在 broker 服务启动时指定 JMX 端口，而后通过实现一套指标采集程序去采集 JMX 指标。（服务端指标官网地址）
broker 级监控 ：broker 过程、broker 入流量字节大小 / 记录数、broker 出流量字节大小 / 记录数、正本同步入流量、正本同步出流量、broker 间流量偏差、broker 连接数、broker 申请队列数、broker 网络闲暇率、broker 生产延时、broker 生产延时、broker 生产申请数、broker 生产申请数、broker 上散布 leader 个数、broker 上散布正本个数、broker 上各磁盘流量、broker GC 等。
topic 级监控 ：topic 入流量字节大小 / 记录数、topic 出流量字节大小 / 记录数、无流量 topic、topic 流量渐变（突增 / 突降）、topic 生产延时。
partition 级监控 ：分区入流量字节大小 / 记录数、分区出流量字节大小 / 记录数、topic 分区正本缺失、分区生产提早记录、分区 leader 切换、分区数据歪斜（生产音讯时，如果指定了音讯的 key 容易造成数据歪斜，这重大影响 Kafka 的服务性能）、分区存储大小（能够治理单分区过大的 topic）。
用户级监控 ：用户出 / 入流量字节大小、用户出 / 入流量被限度工夫、用户流量渐变（突增 / 突降）。
broker 服务日志监控 ：对 server 端打印的谬误日志进行监控告警，及时发现服务异样。
1.4.3. 客户端监控
客户端监控次要是本人实现一套指标上报程序，这个程序须要实现
org.apache.kafka.common.metrics.MetricsReporter 接口。而后在生产者或者消费者的配置中退出配置项 metric.reporters，如下所示：
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "");
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, IntegerSerializer.class.getName());
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
//ClientMetricsReporter 类实现 org.apache.kafka.common.metrics.MetricsReporter 接口
props.put(ProducerConfig.METRIC_REPORTER_CLASSES_CONFIG, ClientMetricsReporter.class.getName());
...客户端指标官网地址：
http://kafka.apache.org/21/documentation.html#selector_monitoring
http://kafka.apache.org/21/documentation.html#common\_node\_monitoring
http://kafka.apache.org/21/documentation.html#producer_monitoring
http://kafka.apache.org/21/documentation.html#producer\_sender\_monitoring
http://kafka.apache.org/21/documentation.html#consumer_monitoring
http://kafka.apache.org/21/documentation.html#consumer\_fetch\_monitoring
客户端监控流程架构如下图所示：
1.4.3.1 生产者客户端监控
维度： 用户名称、客户端 ID、客户端 IP、topic 名称、集群名称、brokerIP；
指标： 连接数、IO 等待时间、生产流量大小、生产记录数、申请次数、申请延时、发送谬误 / 重试次数等。
1.4.3.2 消费者客户端监控
维度： 用户名称、客户端 ID、客户端 IP、topic 名称、集群名称、生产组、brokerIP、topic 分区；
指标： 连接数、io 等待时间、生产流量大小、生产记录数、生产延时、topic 分区生产提早记录等。
1.4.4 Zookeeper 监控
- Zookeeper 过程监控；
- Zookeeper 的 leader 切换监控；
- Zookeeper 服务的谬误日志监控；
1.4.5 全链路监控
当数据链路十分长的时候（比方：业务利用 -> 埋点 SDk-> 数据采集 ->Kafka-> 实时计算 -> 业务利用），咱们定位问题通常须要通过多个团队重复沟通与排查能力发现问题到底呈现在哪个环节，这样排查问题效率比拟低下。在这种状况下，咱们就须要与上下游一起梳理整个链路的监控。呈现问题时，第一工夫定位问题呈现在哪个环节，缩短问题定位与故障复原工夫。
1.5 资源隔离
1.5.1 雷同集群不同业务资源物理隔离
咱们对所有集群中不同对业务进行资源组物理隔离，防止各业务之间相互影响。在这里，咱们假如集群有 4 个 broker 节点（Broker1/Broker2/Broker3/Broker4），2 个业务（业务 A / 业务 B），他们别离领有 topic 分区散布如下图所示，两个业务 topic 都扩散在集群的各个 broker 上，并且在磁盘层面也存在穿插。
试想一下，如果咱们其中一个业务异样，比方流量突增，导致 broker 节点异样或者被打挂。那么这时候另外一个业务也将受到影响，这样将大大的影响了咱们服务的可用性，造成故障，扩充了故障影响范畴。
针对这些痛点，咱们能够对集群中的业务进行物理资源隔离，各业务独享资源，进行资源组划分（这里把 4 各 broker 划分为 Group1 和 Group2 两个资源组）如下图所示，不同业务的 topic 散布在本人的资源组内，当其中一个业务异样时，不会波及另外一个业务，这样就能够无效的放大咱们的故障范畴，进步服务可用性。
1.6 集群归类
咱们把集群依据业务特点进行拆分为日志集群、监控集群、计费集群、搜寻集群、离线集群、在线集群等，不同场景业务放在不同集群，防止不同业务相互影响。
1.7 扩容 / 缩容
1.7.1 topic 扩容分区
随着 topic 数据量增长，咱们最后创立的 topic 指定的分区个数可能曾经无奈满足数量流量要求，所以咱们须要对 topic 的分区进行扩大。扩容分区时须要考虑一下几点：
必须保障 topic 分区 leader 与 follower 轮询的散布在资源组内所有 broker 上，让流量散布更加平衡，同时须要思考雷同分区不同正本跨机架散布以进步容灾能力；
当 topic 分区 leader 个数除以资源组节点个数有余数时，须要把余数分区 leader 优先思考放入流量较低的 broker。
1.7.2 broker 上线
随着业务量增多，数据量一直增大，咱们的集群也须要进行 broker 节点扩容。对于扩容，咱们须要实现以下几点：
扩容智能评估：依据集群负载，把是否须要扩容评估程序化、智能化；
智能扩容：当评估须要扩容后，把扩容流程以及流量平衡平台化。
1.7.3 broker 下线
某些场景下，咱们须要下线咱们的 broker，次要包含以下几个场景：
一些老化的服务器须要下线，实现节点下线平台化；
服务器故障，broker 故障无奈复原，咱们须要下线故障服务器，实现节点下线平台化；
有更优配置的服务器替换已有 broker 节点，实现下线节点平台化。
1.8 负载平衡
咱们为什么须要负载平衡呢？首先，咱们来看第一张图，下图是咱们集群某个资源组刚扩容后的流量散布状况，流量无奈主动的摊派到咱们新扩容后的节点上。那么这个时候须要咱们手动去触发数据迁徙，把局部正本迁徙至新节点上能力实现流量平衡。
上面，咱们来看一下第二张图。这张图咱们能够看出流量散布十分不平衡，最低和最高流量偏差数倍以上。这和 Kafka 的架构特点无关，当集群规模与数据量达到一定量后，必然呈现当问题。这种状况下，咱们也须要进行负载平衡。
咱们再来看看第三张图。这里咱们能够看出出流量只有局部节点突增，这就是 topic 分区在集群外部不够扩散，集中散布到了某几个 broker 导致，这种状况咱们也须要进行扩容分区和平衡。
咱们比拟现实的流量散布应该如下图所示，各节点间流量偏差十分小，这种状况下，既能够加强集群扛住流量异样突增的能力又能够晋升集群整体资源利用率和服务稳定性，降低成本。
负载平衡咱们须要实现以下成果：
1）生成正本迁徙打算以及执行迁徙工作平台化、自动化、智能化；
2）执行平衡后 broker 间流量比拟平均，且单个 topic 分区均匀分布在所有 broker 节点上；
3）执行平衡后 broker 外部多块磁盘间流量比拟平衡；
要实现这个成果，咱们须要开发一套本人的负载平衡工具，如对开源的 cruise control 进行二次开发；此工具的外围次要在生成迁徙打算的策略，迁徙打算的生成计划间接影响到最初集群负载平衡的成果。参考内容：
1. linkedIn/cruise-control
2. Introduction to Kafka Cruise Control
3. Cloudera Cruise Control REST API Reference
cruise control 架构图如下：
在生成迁徙打算时，咱们须要思考以下几点：
1）抉择外围指标作为生成迁徙打算的根据，比方出流量、入流量、机架、单 topic 分区分散性等；
2）优化用来生成迁徙打算的指标样本，比方过滤流量突增 / 突降 / 掉零等异样样本；
3）各资源组的迁徙打算须要应用的样本全副为资源组外部样本，不波及其余资源组，无穿插；
4）治理单分区过大 topic，让 topic 分区散布更扩散，流量不集中在局部 broker，让 topic 单分区数据量更小，这样能够缩小迁徙的数据量，晋升迁徙速度；
5）曾经平均扩散在资源组内的 topic，退出迁徙黑名单，不做迁徙，这样能够缩小迁徙的数据量，晋升迁徙速度；
6）做 topic 治理，排除长期无流量 topic 对平衡的烦扰；
7）新建 topic 或者 topic 分区扩容时，应让所有分区轮询散布在所有 broker 节点，轮询后余数分区优先散布流量较低的 broker；
8）扩容 broker 节点后开启负载平衡时，优先把同一 broker 调配了同一大流量（流量大而不是存储空间大，这里能够认为是每秒的吞吐量）topic 多个分区 leader 的，迁徙一部分到新 broker 节点；
9）提交迁徙工作时，同一批迁徙打算中的分区数据大小偏差应该尽可能小，这样能够防止迁徙工作中小分区迁徙实现后长时间期待大分区的迁徙，造成工作歪斜；
1.9 平安认证
是不是咱们的集群所有人都能够随便拜访呢？当然不是，为了集群的平安，咱们须要进行权限认证，屏蔽非法操作。次要包含以下几个方面须要做平安认证：
(1) 生产者权限认证；
(2) 消费者权限认证；
(3) 指定数据目录迁徙平安认证；
官网地址：http://kafka.apache.org
1.10 集群容灾
跨机架容灾：
官网地址：http://kafka.apache.org
跨集群 / 机房容灾 ：如果有异地双活等业务场景时，能够参考 Kafka2.7 版本的 MirrorMaker 2.0。
GitHub 地址：https://github.com
准确 KIP 地址：https://cwiki.apache.org
ZooKeeper 集群上 Kafka 元数据恢复 ：咱们会定期对 ZooKeeper 上的权限信息数据做备份解决，当集群元数据异样时用于复原。
1.11 参数 / 配置优化
broker 服务参数优化 ：这里我只列举局部影响性能的外围参数。
num.network.threads
#创立 Processor 解决网络申请线程个数，倡议设置为 broker 当 CPU 外围数 *2，这个值太低经常出现网络闲暇太低而缺失正本。num.io.threads
#创立 KafkaRequestHandler 解决具体申请线程个数，倡议设置为 broker 磁盘个数 *2
num.replica.fetchers
#倡议设置为 CPU 外围数 /4，适当进步能够晋升 CPU 利用率及 follower 同步 leader 数据当并行度。compression.type
#倡议采纳 lz4 压缩类型，压缩能够晋升 CPU 利用率同时能够缩小网络传输数据量。queued.max.requests
#如果是生产环境，倡议配置起码 500 以上，默认为 500。log.flush.scheduler.interval.ms
log.flush.interval.ms
log.flush.interval.messages
#这几个参数示意日志数据刷新到磁盘的策略，应该放弃默认配置，刷盘策略让操作系统去实现，由操作系统来决定什么时候把数据刷盘；#如果设置来这个参数，可能对吞吐量影响十分大；auto.leader.rebalance.enable
#示意是否开启 leader 主动负载平衡，默认 true；咱们应该把这个参数设置为 false，因为主动负载平衡不可控，可能影响集群性能和稳固；生产优化 ：这里我只列举局部影响性能的外围参数。
linger.ms
#客户端生产音讯期待多久工夫才发送到服务端，单位：毫秒。和 batch.size 参数配合应用；适当调大能够晋升吞吐量，然而如果客户端如果 down 机有失落数据危险；batch.size
#客户端发送到服务端音讯批次大小，和 linger.ms 参数配合应用；适当调大能够晋升吞吐量，然而如果客户端如果 down 机有失落数据危险；compression.type
#倡议采纳 lz4 压缩类型，具备较高的压缩比及吞吐量；因为 Kafka 对 CPU 的要求并不高，所以，能够通过压缩，充分利用 CPU 资源以晋升网络吞吐量；buffer.memory
#客户端缓冲区大小，如果 topic 比拟大，且内存比拟短缺，能够适当调高这个参数，默认只为 33554432(32MB)
retries
#生产失败后的重试次数，默认 0，能够适当减少。当重试超过肯定次数后，如果业务要求数据准确性较高，倡议做容错解决。retry.backoff.ms
#生产失败后，重试工夫距离，默认 100ms，倡议不要设置太大或者太小。除了一些外围参数优化外，咱们还须要思考比方 topic 的分区个数和 topic 保留工夫；如果分区个数太少，保留工夫太长，然而写入数据量十分大的话，可能造成以下问题：
1）topic 分区集中落在某几个 broker 节点上，导致流量正本失衡；
2）导致 broker 节点外部某几块磁盘读写超负载，存储被写爆；
1.11.1 生产优化
生产最大的问题，并且经常出现的问题就是生产延时，拉历史数据。当大量拉取历史数据时将呈现大量读盘操作，净化 pagecache，这个将减轻磁盘的负载，影响集群性能和稳固；
能够怎么缩小或者防止大量生产延时呢？
1）当 topic 数据量十分大时，倡议一个分区开启一个线程去生产；
2）对 topic 生产延时增加监控告警，及时发现解决；
3）当 topic 数据能够抛弃时，遇到超大延时，比方单个分区提早记录超过千万甚至数亿，那么能够重置 topic 的生产点位进行紧急解决；【此计划个别在极其场景才应用】
4）防止重置 topic 的分区 offset 到很早的地位，这可能造成拉取大量历史数据；
1.11.2 Linux 服务器参数优化
咱们须要对 Linux 的文件句柄、pagecache 等参数进行优化。可参考《Linux Page Cache 调优在 Kafka 中的利用》。
1.12. 硬件优化
磁盘优化
在条件容许的状况下，能够采纳 SSD 固态硬盘替换 HDD 机械硬盘，解决机械盘 IO 性能较低的问题；如果没有 SSD 固态硬盘，则能够对服务器上的多块硬盘做硬 RAID（个别采纳 RAID10），让 broker 节点的 IO 负载更加平衡。如果是 HDD 机械硬盘，一个 broker 能够挂载多块硬盘，比方 12 块 *4TB。
内存
因为 Kafka 属于高频读写型服务，而 Linux 的读写申请根本走的都是 Page Cache，所以单节点内存大一些对性能会有比拟显著的晋升。个别抉择 256GB 或者更高。
网络
晋升网络带宽：在条件容许的状况下，网络带宽越大越好。因为这样网络带宽才不会成为性能瓶颈，起码也要达到万兆网络（10Gb，网卡为全双工）能力具备绝对较高的吞吐量。如果是单通道，网络出流量与入流量之和的下限理论值是 1.25GB/s；如果是双工双通道，网络出入流量理论值都能够达到 1.25GB/s。
网络隔离打标：因为一个机房可能既部署有离线集群（比方 HBase、Spark、Hadoop 等）又部署有实时集群（如 Kafka）。那么实时集群和离线集群挂载到同一个交换机下的服务器将呈现竞争网络带宽的问题，离线集群可能对实时集群造成影响。所以咱们须要进行交换机层面的隔离，让离线机器和实时集群不要挂载到雷同的交换机下。即便有挂载到雷同交换机上面的，咱们也将进行网络通行优先级（金、银、铜、铁）标记，当网络带宽缓和的时候，让实时业务优先通行。
CPU
Kafka 的瓶颈不在 CPU，单节点个别有 32 核的 CPU 都足够应用。
1.13. 平台化
当初问题来了，后面咱们提到很多监控、优化等伎俩；难道咱们管理员或者业务用户对集群所有的操作都须要登录集群服务器吗？答案当然是否定的，咱们须要丰盛的平台化性能来反对。一方面是为了晋升咱们操作的效率，另外一方面也是为了晋升集群的稳固和升高出错的可能。
配置管理
黑屏操作，每次批改 broker 的 server.properties 配置文件都没有变更记录可追溯，有时可能因为有人批改了集群配置导致一些故障，却找不到相干记录。如果咱们把配置管理做到平台上，每次变更都有迹可循，同时升高了变更出错的危险。
滚动重启
当咱们须要做线上变更时，有时候须要对集群对多个节点做滚动重启，如果到命令行去操作，那效率将变得很低，而且须要人工去干涉，节约人力。这个时候咱们就须要把这种重复性的工作进行平台化，晋升咱们的操作效率。
集群治理
集群治理次要是把原来在命令行的一系列操作做到平台上，用户和管理员不再须要黑屏操作 Kafka 集群；这样做次要有以下长处：
晋升操作效率；
操作出错概率更小，集群更平安；
所有操作有迹可循，能够追溯；
集群治理次要包含：broker 治理、topic 治理、生产 / 生产权限治理、用户治理等
1.13.1 mock 性能
在平台上为用户的 topic 提供生产样例数据与生产抽样的性能，用户能够不必本人写代码也能够测试 topic 是否能够应用，权限是否失常；
在平台上为用户的 topic 提供生产 / 生产权限验证性能，让用户能够明确本人的账号对某个 topic 有没有读写权限；
1.13.2 权限治理
把用户读 / 写权限治理等相干操作进行平台化。
1.13.3 扩容 / 缩容
把 broker 节点高低线做到平台上，所有的上线和下线节点不再须要操作命令行。
1.13.4 集群治理
1）无流量 topic 的治理，对集群中无流量 topic 进行清理，缩小过多无用元数据对集群造成的压力；
2）topic 分区数据大小治理，把 topic 分区数据量过大的 topic（如单分区数据量超过 100GB/ 天）进行梳理，看看是否须要扩容，防止数据集中在集群局部节点上；
3）topic 分区数据歪斜治理，防止客户端在生产音讯的时候，指定音讯的 key，然而 key 过于集中，音讯只集中散布在局部分区，导致数据歪斜；
4）topic 分区分散性治理，让 topic 分区散布在集群尽可能多的 broker 上，这样能够防止因 topic 流量突增，流量只集中到多数节点上的危险，也能够防止某个 broker 异样对 topic 影响十分大；
5）topic 分区生产延时治理；个别有延时生产较多的时候有两种状况，一种是集群性能降落，另外一种是业务方的生产并发度不够，如果是消费者并发不够的化应该与业务联系减少生产并发。
1.13.5 监控告警
1）把所有指标采集做成平台可配置，提供对立的指标采集和指标展现及告警平台，实现一体化监控；
2）把上下游业务进行关联，做成全链路监控；
3）用户能够配置 topic 或者分区流量延时、渐变等监控告警；
1.13.6 业务大屏
业务大屏次要指标：集群个数、节点个数、日入流量大小、日入流量记录、日出流量大小、日出流量记录、每秒入流量大小、每秒入流量记录、每秒出流量大小、每秒出流量记录、用户个数、生产延时、生产延时、数据可靠性、服务可用性、数据存储大小、资源组个数、topic 个数、分区个数、正本个数、生产组个数等指标。
1.13.7 流量限度
把用户流量当初做到平台，在平台进行智能限流解决。
1.13.8 负载平衡
把主动负载平衡性能做到平台，通过平台进行调度和治理。
1.13.9 资源估算
当集群达到肯定规模，流量一直增长，那么集群扩容机器从哪里来呢？业务的资源估算，让集群外面的多个业务依据本人在集群中当流量去摊派整个集群的硬件老本；当然，独立集群与独立隔离的资源组，估算形式能够独自计算。
1.14. 性能评估
1.14.1 单 broker 性能评估
咱们做单 broker 性能评估的目标包含以下几方面：
1) 为咱们进行资源申请评估提供根据；
2) 让咱们更理解集群的读写能力及瓶颈在哪里，针对瓶颈进行优化；
3) 为咱们限流阈值设置提供根据；
4) 为咱们评估什么时候应该扩容提供根据；
1.14.2 topic 分区性能评估
1) 为咱们创立 topic 时，评估应该指定多少分区正当提供根据；
2) 为咱们 topic 的分区扩容评估提供根据；
1.14.3 单磁盘性能评估
1) 为咱们理解磁盘的真正读写能力，为咱们抉择更适合 Kafka 的磁盘类型提供根据；
2) 为咱们做磁盘流量告警阈值设置提供根据；
1.14.4 集群规模限度摸底
1）咱们须要理解单个集群规模的下限或者是元数据规模的下限，摸索相干信息对集群性能和稳定性的影响；
2）依据摸底状况，评估集群节点规模的正当范畴，及时预测危险，进行超大集群的拆分等工作；
1.15 DNS+LVS 的网络架构
当咱们的集群节点达到肯定规模，比方单集群数百个 broker 节点，那么此时咱们生产生产客户端指定 bootstrap.servers 配置时，如果指定呢？是轻易抉择其中几个 broker 配置还是全副都配上呢？
其实以上做法都不适合，如果只配置几个 IP，当咱们配置当几个 broker 节点下线后，咱们当利用将无奈连贯到 Kafka 集群；如果配置所有 IP，那更不事实啦，几百个 IP，那么咱们应该怎么做呢？
计划： 采纳 DNS+LVS 网络架构，最终生产者和消费者客户端只须要配置域名就能够啦。须要留神的是，有新节点退出集群时，须要增加映射；有节点下线时，须要从映射中踢掉，否则这批机器如果拿到其余的中央去应用，如果端口和 Kafka 的一样的话，原来集群局部申请将发送到这个曾经下线的服务器上来，造成生产环境重点故障。
二、开源版本性能缺点
RTMP 协定次要的特点有：多路复用，分包和应用层协定。以下将对这些特点进行具体的形容。
2.1 正本迁徙
无奈实现增量迁徙；【咱们曾经基于 2.1.1 版本源码革新，实现了增量迁徙】
无奈实现并发迁徙；【开源版本直到 2.6.0 才实现了并发迁徙】
无奈实现终止迁徙；【咱们曾经基于 2.1.1 版本源码革新，实现了终止正本迁徙】【开源版本直到 2.6.0 才实现了暂停迁徙，和终止迁徙有些不一样，不会回滚元数据】
当指定迁徙数据目录时，迁徙过程中，如果把 topic 保留工夫改短，topic 保留工夫针对正在迁徙 topic 分区不失效，topic 分区过期数据无奈删除；【开源版本 bug，目前还没有修复】
当指定迁徙数据目录时，当迁徙打算为以下场景时，整个迁徙工作无奈实现迁徙，始终处于卡死状态；【开源版本 bug，目前还没有修复】
迁徙过程中，如果有重启 broker 节点，那个 broker 节点上的所有 leader 分区无奈切换回来，导致节点流量全副转移到其余节点，直到所有正本被迁徙结束后 leader 才会切换回来；【开源版本 bug，目前还没有修复】。
在原生的 Kafka 版本中存在以下指定数据目录场景无奈迁徙结束的状况，此版本咱们也不决定修复次 bug：1. 针对同一个 topic 分区，如果局部指标正本相比原正本是所属 broker 发生变化，局部指标正本相比原正本是 broker 外部所属数据目录发生变化；那么正本所属 broker 发生变化的那个指标正本能够失常迁徙结束，指标正本是在 broker 外部数据目录发生变化的无奈失常实现迁徙；然而旧正本仍然能够失常提供生产、生产服务，并且不影响下一次迁徙工作的提交，下一次迁徙工作只须要把此 topic 分区的正本列表所属 broker 列表变更后提交仍然能够失常实现迁徙，并且能够清理掉之前未实现的指标正本；这里假如 topic yyj1 的初始化正本散布状况如下：{
"version":1,
"partitions":[{"topic":"yyj","partition":0,"replicas":[1000003,1000001],"log_dirs":["/kfk211data/data31","/kfk211data/data13"]}
]
}
// 迁徙场景 1：{
"version":1,
"partitions":[{"topic":"yyj","partition":0,"replicas":[1000003,1000002],"log_dirs":["/kfk211data/data32","/kfk211data/data23"]}
]
}
// 迁徙场景 2：{
"version":1,
"partitions":[{"topic":"yyj","partition":0,"replicas":[1000002,1000001],"log_dirs":["/kfk211data/data22","/kfk211data/data13"]}
]
}
针对上述的 topic yyj1 的散布散布状况，此时如果咱们的迁徙打算为“迁徙场景 1”或迁徙场景 2“，那么都将呈现有正本无奈迁徙结束的状况。然而这并不影响旧正本解决生产、生产申请，并且咱们能够失常提交其余的迁徙工作。为了清理旧的未迁徙实现的正本，咱们只须要批改一次迁徙打算【新的指标正本列表和以后分区已调配正本列表齐全不同即可】，再次提交迁徙即可。这里，咱们仍然以上述的例子做迁徙打算批改如下：{
"version":1,
"partitions":[{"topic":"yyj","partition":0,"replicas":[1000004,1000005],"log_dirs":["/kfk211data/data42","/kfk211data/data53"]}
]
}
这样咱们就能够失常实现迁徙。2.2 流量协定
限流粒度较粗，不够灵便精准，不够智能。
以后限流维度组合
/config/users/<user>/clients/<client-id>
/config/users/<user>/clients/<default>
/config/users/<user>
/config/users/<default>/clients/<client-id>
/config/users/<default>/clients/<default>
/config/users/<default>
/config/clients/<client-id>
/config/clients/<default>存在问题
当同一个 broker 上有多个用户同时进行大量的生产和生产时，想要让 broker 能够失常运行，那必须在做限流时让所有的用户流量阈值之和不超过 broker 的吞吐下限；如果超过 broker 下限，那么 broker 就存在被打挂的危险；然而，即便用户流量没有达到 broker 的流量下限，然而，如果所有用户流量集中到了某几块盘上，超过了磁盘的读写负载，也会导致所有生产、生产申请将被阻塞，broker 可能处于假死状态。
解决方案
(1) 革新源码，实现单个 broker 流量下限限度，只有流量达到 broker 下限立刻进行限流解决，所有往这个 broker 写的用户都能够被限制住；或者对用户进行优先级解决，放过高优先级的，限度低优先级的；
(2) 革新源码，实现 broker 上单块磁盘流量下限限度（很多时候都是流量集中到某几块磁盘上，导致没有达到 broker 流量下限却超过了单磁盘读写能力下限），只有磁盘流量达到下限，立刻进行限流解决，所有往这个磁盘写的用户都能够被限制住；或者对用户进行优先级解决，放过高优先级的，限度低优先级的；
(3) 革新源码，实现 topic 维度限流以及对 topic 分区的禁写性能；
(4) 革新源码，实现用户、broker、磁盘、topic 等维度组合精准限流；
三、kafka 发展趋势
3.1 Kafka 社区迭代打算
3.2 逐渐弃用 ZooKeeper（KIP-500）
3.3 controller 与 broker 拆散，引入 raft 协定作为 controller 的仲裁机制（KIP-630）
3.4 分层存储（KIP-405）
3.5 能够缩小 topic 分区（KIP-694）
3.6 MirrorMaker2 准确一次（KIP-656）
3.7 下载与各版本个性阐明
3.8 Kafka 所有 KIP 地址
四、如何奉献社区
4.1 哪些点能够奉献
http://kafka.apache.org/contributing
4.2 wiki 奉献地址
https://cwiki.apache.org/confluence/dashboard.action#all-updates
4.3 issues 地址
1）https://issues.apache.org/jira/projects/KAFKA/issues/KAFKA-10444?filter=allopenissues
2）https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=all
4.4 次要 committers
http://kafka.apache.org/committers
作者：vivo 互联网服务器团队 -Yang Yijun