Kafka万亿元级信息实战演练

一、Kafka运用

文中关键汇总当Kafka群集总流量做到 万亿元级纪录/天或是十万亿级纪录/天  乃至高些后，大家必须具有什么工作能力才可以确保群集高可用性、高靠谱、性能卓越、高吞吐、安全性的运作。

这儿汇总內容关键对于Kafka2.1.1版本号，包含群集版本更新、数据备份转移、总流量限定、监管报警、web服务、群集扩/缩容、資源防护、群集容灾备份、群集安全性、性能优化、平台化、开源系统版本号缺点、小区动态性等层面。文中主要是详细介绍关键多元性，不做太多关键点解读。下边大家先讨论一下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”，假如自身沒有完成全自动web服务，能够应用此脚本制作。

开源系统版本号给予的这一脚本制作转化成转移方案彻底是人工控制的，当群集经营规模十分大时，转移高效率越来越十分不高，一般以日为企业开展测算。自然，我们可以完成一套自动化技术的平衡程序流程，当web服务完成自动化技术之后，基本上应用启用內部给予的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內部几块硬盘的总流量做web服务，让总流量更匀称的遍布到各硬盘上。

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能够承担的总流量开展智能化评定，不用人工控制分辨是不是能够调节；针对客户总流量限定，关键必须参照的指标值包含下列2个：

（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监管

1. Zookeeper过程监管；

2. Zookeeper的leader转换监管；

3. Zookeeper服务项目的不正确日志监管；

1.4.5 全链路监管

当卫星通信系统路十分长的情况下（例如：业务流程运用->埋点SDk->数据收集->Kafka->即时测算->业务流程运用），大家精准定位一般必须历经好几个精英团队不断沟通交流与清查才可以发现问题究竟发生在哪个阶段，那样清查难题高效率较为不高。在这类状况下，大家就必须与上中下游一起整理全部链接的监管。发生难题时，第一时间精准定位发生在哪个阶段，减少难题精准定位与常见故障修复時间。

1.5 資源防护

1.5.1 同样群集不一样业务流程資源物理隔离

大家对全部群集中不一样对业务流程开展資源组物理隔离，防止各业务流程中间互相影响。在这儿，大家假定群集有4个broker连接点（Broker1/Broker2/Broker3/Broker4），两个业务流程（业务流程A/业务流程B），她们各自有着topic系统分区遍布如下图所显示，2个业务流程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 web服务

大家为何必须web服务呢？最先，大家看来第一张图，下面的图是大家群集某一資源组刚扩充后的总流量遍布状况，总流量没法全自动的平摊到大家新扩充后的连接点上。那麼这个时候必须大家手动式去开启数据备份转移，把一部分团本转移至新连接点上才可以完成总流量平衡。

下边，大家看来一下第二张图。这幅图我们可以看得出总流量遍布十分不平衡，最少和最大总流量误差多倍之上。这和Kafka的构架特性相关，当群集经营规模与信息量做到一定量后，必定发生当难题。这类状况下，大家也必须开展web服务。

大家再讨论一下第三张图。这儿我们可以看得出出总流量仅有一部分连接点猛增，这就是topic系统分区在群集內部不足分散化，集中化遍布到某好多个broker造成，这类状况大家也必须开展扩充系统分区和平衡。

大家较为理想化的总流量遍布应当如下图所显示，各连接点间总流量误差十分小，这类状况下，既能够提高群集扛住总流量出现异常猛增的工作能力又可以提高群集总体資源使用率和服务项目可靠性，控制成本。

web服务大家必须完成下列实际效果：

1）转化成团本转移方案及其实行转移每日任务平台化、自动化技术、智能化系统；

2）实行平衡后broker间总流量较为匀称，且单独topic系统分区分布均匀在所有broker连接点上；

3）实行平衡后broker內部几块硬盘间总流量较为平衡；

要完成这一实际效果，大家必须开发设计一套自身的web服务专用工具，如对开源系统的 cruise control开展二次开发；此专用工具的关键关键在转化成转移方案的对策，转移方案的转化成计划方案立即危害到最终群集web服务的实际效果。参照內容：

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连接点后打开web服务时，优先选择把同一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全自动web服务，默认设置true；大家应当把这个基本参数为false，由于全自动web服务不可控性，很有可能危害群集特性和平稳；

生产制造提升：这儿我只例举一部分危害特性的关键主要参数。

linger.ms
#手机客户端生产制造信息等候多长时间時间才发送至服务器端，企业：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，因此 单连接点运行内存大一些对特性会出现较为显著的提高。一般挑选258GB或是高些。

互联网

提高服务器带宽：在标准容许的状况下，服务器带宽越大越好。由于那样服务器带宽才不容易变成特性短板，至少还要做到万兆互联网（ 10Gb，网口为双工）才可以具有相对性较高的货运量。如果是多通道，互联网出总流量与入总流量之和的限制标准偏差是1.25GB/s；如果是双工双通道内存，互联网进出总流量标准偏差都能够做到1.25GB/s。

互联网防护激光打标：因为一个主机房很有可能既布署有线下群集（例如HBase、Spark、Hadoop等）又布署有即时群集（如Kafka）。那麼即时群集和线下群集初始化到同一个网络交换机下的网络服务器将发生市场竞争服务器带宽的难题，线下群集很有可能对即时群集导致危害。因此 大家必须开展网络交换机方面的防护，让线下设备和即时群集不必初始化到同样的网络交换机下。即便有初始化到同样网络交换机下边的，大家也将开展互联网行驶优先（金、银、铜、铁）标识，当服务器带宽焦虑不安的情况下，让即时业务流程优先选择行驶。

CPU

Kafka的短板没有CPU，单连接点一般有32核的CPU都充足应用。

1.13.平台化

如今那么问题来了，前边大家提及许多 监管、提升等方式；难道说大家管理人员或是业务流程客户对群集全部的实际操作都必须登陆集群服务器吗？回答自然是否认的，大家必须丰富多彩的平台化作用来适用。一方面是为了更好地提高大家实际操作的高效率，此外一方面也是为了更好地提高群集的平稳和减少打错的很有可能。

软件配置管理

黑屏操作，每一次改动broker的server.properties环境变量也没有变动纪录追朔，有时候很有可能由于有些人改动了群集配备造成一些常见故障，却找不着有关纪录。如果我们把软件配置管理保证服务平台上，每一次变动都如影随行，另外减少了变动打错的风险性。

翻转重新启动

在我们必须做网上变动时，有时必须对群集对好几个连接点做翻转重新启动，假如到cmd去实际操作，那高效率将越来越很低，并且必须人力去干涉，消耗人力资源。这个时候大家就必须把这类可重复性的工作中开展平台化，提高大家的实际操作高效率。

群集管理方法

群集管理方法主要是把原先在cmd的一系列实际操作保证服务平台上，客户和管理人员不会再必须黑屏操作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 web服务

把全自动web服务作用保证服务平台，根据服务平台开展生产调度和管理方法。

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)更新改造源代码，完成brokerlol上单块硬盘总流量限制限定（许多 情况下全是总流量集中化到某几片硬盘上，造成沒有做到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