摘要
咱们上一节解说了Kafka架构-底层原理:从根底的partition外面的offset引申到LEO和HW;以及对于Leader partition跟follower partition而言,他们的LEO跟HW是如何更新的的？以及高水位HW在leader选举切换时候，存在的数据失落跟数据不统一问题，以及通过leader epoch版本号的概念引入解决下面问题，因为HW的变更还跟leadder partition外面的ISR列表有关联，又解说了:ISR列表设计的0.9.x之前版本形式以及0.9.x之后的版本通过follower音讯数比leader音讯数目少形式更新LSR列表，以及依据工夫来更新ISR列表。而后这些都解说结束之后，咱们解说了Kafka的日志是如何存储存储到对应目录列表的，而后怎么基于存储日志疾速找到对应offset的数据的二分查找法；这些都解说结束之后，解说了Kafka底层集群外面节点如何通信？以及集群节点如果进行管控，Leader选举，线上解体以及数据清理。
这些理解之后，咱们便可进行Kafka理论线上生产规划以及搭建。次要阐明以下：
1、基于理论业务进行kafka集群如何布局？须要思考哪些问题？
2、Kafka集群生产参数配置：包含Kafka本人内核参数、操作系统参数、JVM和GC参数。
3、Kafka单点搭建用于测试、Kafka集群搭建
4、具备环境之后，咱们须要进行一些运维工作:Kafka的测试。
思维导图
内容
1、基于理论业务进行Kafka集群生产规划(电商零碎每日10亿数据量)
基于理论生产业务的时候,咱们布局kafka集群的时候,思考方向是:基于每天数据量计算出零碎的大略QPS,依据QPS能够计算出须要多少台物理机器；依据每天数据量预估整体数据量大小，在联合Kafka本身的原理，保留工夫长短，以及多冗余正本机制避免数据失落来预估整体数据量大小来布局机器测硬盘大小。这些都做完之后，就须要具体到一台物理机或者虚拟机了,次要思考:cpu(每台机器的线程数)、内存(Kafka本身底层原理)、磁盘(kafka底层原理剖析)、网络(依据数据量)
1、QPS
基于10亿数据量:10亿数据量 依据2-8准则,80%的数据是在非凌晨0-8点的16小时产生，并且其中80%的申请都是在20%的工夫内，所以:100.80.8=6亿数据在:1620%=3小时；QPS=600000000/360*60近似为6万。
2、存储量
总存储量=工夫*每天存储量。
每天10亿数据量，咱们假如每条数据大小大略是1kb,其实很多时候均匀是达不到1kb的数据。咱们粗略预计下:假如一个英文字母是1个字节byte,1个中文汉子是2个字节byte,那么1kb能够包容1024个英文字符/512个汉子；10亿数据量,是10亿kb大小数据，kafka假如咱们依照2个正本，数据默认保留7天，则 整体数据量=1027=140亿kb近似依照12TB数据量算。
3、物理机
1、物理机数量
物理机数量个别依据qps计算，因为qps是6万左右，个别一台机器大略抗并发是3万左右，因为在机器资源短缺状况下，个别为了应答秒杀这种场景,计算的qps=总体qps*30%;所以咱们的最大qps为20万qps左右，所以咱们的机器大略在6-7台机器，这里咱们抉择6台机器。
2、物理机cpu
经验值
是状况而定，咱们为了减少kafka的吞吐量的话,咱们将会把解决申请的线程数量调整为默认的2～3倍
Kafka Broker过程运行起来线程数预估
依据Kafka多路复用的Reeactor模型解决申请时候，是须要一个Accepptor线程，Processor线程用来将申请写入到申请队列，默认是3个；而后具体进行申请解决的是一个Handler线程池，默认线程数量是8个；以及后盾数据清理线程几controller选举等线程。依照2～3倍准则,咱们的线程数:24-36；而后加上日志清理线程，或者Controller感知线程等,咱们将预估线程忙碌的时候，线程数量为一两百。
cpu核跟线程数的经验值
1、CPU 4核，一般来说几十个线程，在高峰期CPU简直都快打满了，
2、CPU 8核，也就可能比拟拮据的撑持几十个线程忙碌的工作，
3、个别是倡议16核，靠谱，基本上能够达到一两百线程的工作。
broker个别都会启动几十个甚至上百个线程，大家看过broker端的原理了，各种解决申请的线程，后盾线程，几十个线程频繁工作，个别都倡议是16核CPU，甚至32核CPU
3、物理机内存
因为Kafka写数据是:写入os_cache+磁盘程序写，kafka读取数据:零拷贝+页缓冲技术(os_cache)
所以咱们发现Kafka是大量依附os_cache，而不是JVM外面的内存；所以咱们布局机器内存的时候，次要是思考os_cache内存大小，辅助思考下机器内存大小。
kafka jvm堆内存，你感觉须要很大吗？
理解了kafka原理之后，kafka并没有在本人的jvm堆内存里放入过多的数据，他跟rabbitmq是不一样的，rabbitmq是数据过去优先写入jvm堆内存里去缓冲一下，肯定工夫之后，rabbitmq再一次性把jvm堆内存里的缓冲一批数据给刷入磁盘中。rabbitmq那种机制跟原理的话会导致jvm堆内存中寄存大量的数据，须要给jvm堆内存开拓比拟大的空间了。
然而kafka正好相同的，他接管到了这个数据之后不是间接写jvm堆内存的，而是采纳本人的二进制紧凑的数据格式，给写入到磁盘文件里去，然而是先写入os cache（操作系统治理的一块内存缓冲空间）kafka并没有应用过多的jvm堆内存空间，所以的话你不须要给kafka jvm堆内存调配过大的空间，基本上来说几个G就够了。
充分利用os_cache进步性能：
咱们思考下os_cache调配多大；
准则: broker治理的每个parition的最新正在写的日志段文件的数据都能够驻留在os cache中，这样能够保障每个parition正在写的数据，最有可能被生产的数据，就能够间接从os cache里来读了。
剖析:
假如整个Kafka的集群外面有100个topic，假如每个topic是6个partition，每个partiton是2个正本，然而其实不会从partition的正本读取数据，你只须要思考的是leader partirion,所以一共100 * 6 =600个leader partition，均匀到6台机器下来，假如每台机器是放100个partition，每个partition的最新正在写的日志段文件的大小是默认的1GB.
所以说单台机器上，最新的正在写的日志段文件的大小100个partition 1GB的日志段文件 = 600GB。如果最佳的状况，单台机器能够有600GB的内存的给os cache的话，就能够每个partiton最新的数据都在os cache里，比如说一个日志段文件有1GB，可能都对应几百万条数据了，这些数据咱们也不会变频繁生产，最多也就是1%-10%数据生产，所以600(1%-10%)也就是6G以上所以咱们大略64G的机器内存即可。
JVM的堆内存
kafka本身的jvm是用不了过多堆内存的，因为kafka设计就是躲避掉用jvm对象来保留数据，防止频繁fullgc导致的问题，所以个别kafka本身的jvm堆内存，调配个6G左右就够了，剩下的内存全副留给os cache
4、物理机网络带宽
生产环境的机器布局，无论是MySQL、Redis、RocketMQ、Elasticsearch、Kafka、Hadoop、Flink，Yarn，其实布局的思路都是相似的，思考的其实是从技术实质和底层的原理登程来思考：
1、申请量有多大、
2、数据量有多大、
3、内存应该调配多大（须要理解底层工作机制，怎么应用内存的？）、
4、线程数量有多少、
5、网络数据传输量有多大（个别决定了你的网卡大小抉择）
当初个别就是千兆网卡（1GB / s），还有万兆网卡（10GB / s），网卡决定了什么呢？比方你要计算一下，kafka集群之间，broker和broker之间是会做数据同步的，因为leader要同步数据到follower下来，他们是在不同的broker机器上的，broker机器之间会进行频繁的数据同步，传输大量的数据。
所以在这种状况下，须要计算下每秒两台broker机器之间大略会传输多大的数据量？高峰期每秒大略会涌入6万条数据，假如每一条数据大小是1kb，大略来说每秒就是60mb/s的数据量，每秒60mb/s的湖，他会在broker之间来传输，你就算多估算一些，每秒大略也就传输个几百mb/s的数据，就足够了。
实际上每台机器能用的网卡的带宽还达不到极限，因为kafka只能用其中一部分的带宽资源，比方700mb/s，然而个别不能允许kafka占用这么多带宽，因为防止说占用这么多带宽，万一再多一点，就容易把网卡打满
所以说，个别限度kafka每秒带宽资源就是300mb / s，如果你给物理机应用的千兆网卡，那么其实他每秒最多传输数据是几百mb，是够了，可能也就是几十mb，或者一两百mb，基本上都够了，能够足够传输。
5、物理机磁盘
磁盘类型
SSD磁盘的性能相比于机械硬盘的话次要在磁盘随即写下面，在磁盘程序写的状况下,磁盘程序写跟随即写差不多，所以因为Kafka是基于os cahce+磁盘程序写机制,因为磁盘程序写的性能跟写内存差不多，并且SSD的在磁盘随机写上会比机械硬盘成果好,在磁盘程序写上SSD跟机械硬盘差不多,所以咱们应用机械硬盘即可
磁盘大小
总共13T数据,因为很多数据是没有1kb大小的，所以咱们预估是12TB数据，6台机器，则:每台机器加上2快1TB的磁盘,总共2TB。
2、Kafka集群生产参数设置
1、内核参数
内存参数的话次要是Kafka Broker利用的本身配置文件,上面是一些惯例参数：
broker.id：Kafka利用的惟一标示；这个是每个broker都必须本人设置的一个惟一id。
log.dirs：这个极为重要，kafka的所有数据就是写入这个目录下的磁盘文件中的，如果说机器上有多块物理硬盘，那么能够把多个目录挂载到不同的物理硬盘上，而后这里能够设置多个目录，这样kafka能够把数据写的压力扩散到多块物理硬盘，多个硬盘的磁头能够并行写，这样能够晋升吞吐量。
zookeeper.connect： 因为你要晓得的是，Kafka他肯定要去应用zookeeper的。所以须要配置底层**这个是连贯kafka底层的zookeeper集群的地址。
Listeners：这是broker监听客户端发动申请的端口号，在Kafka新版本外面，通过listeners去配置broker。通过哪个端口去监听客户端发送过去申请的。
unclean.leader.election.enable：1.0版本之前都是true：意思是容许非ISR列表的follower选举为新的leader。这个是什么意思呢？比如说你的一个follower，他可能落后于这个leader。然而呢？leader此时挂了。之前老版本也是容许非ISR列表外面的follower选举为leader。这个时候可能会失落一些数据这样子。1.0之后。默认设置为false:意思就是只能选举ISR列表里的follower成为新的leader。unclean指代不洁净的leader选举，也就是指代不在ISR列表外面的follower选举。
delete.topic.enable**：默认true，容许删除topic。
log.retention.hours**： 设置一下日志要保留数据多少个小时，这个就是底层的磁盘文件，默认保留7天的数据。
log.retention.bytes: 这个设置如果分区的数据量超过了这个限度，就会主动清理数据，默认-1不依照这个策略来清理，这个个别不罕用
min.insync.replicas： 这个跟acks=-1配合起来应用，意思就是说必须要求ISR列表里有几个follower，而后acks=-1就是写入数据的时候，必须写入这个数量指定的follower才能够，个别是能够思考如果一个leader两个follower，三个正本，那么这个设置为2，能够容忍一台机器宕机，保障高可用，然而写入数据的时候必须ISR里有2个正本，而且必须正本都写入才算胜利。
如果你就一个leader和follower，也就是说你只有双正本，而后min.insync.replicas = 2。如果有一台机器宕机，导致follower没了，此时ISR列表里就一个leader的话，你就不能写入了,因为你设置的参数:min.insync.replicas = 2 也就是要求ISR列表外面至多有哦2个正本。然而咱们将参数：min.insync.replicas = 2设置为2也是有情理的，如果你只有一个正本了，此时还能够写入数据的话，就会导致写入到leader之后，万一leader也宕机了，此时数据必然失落。
一般来说为了防止数据占用磁盘空间过大，个别都是kafka设置双正本，一个leader和一个follower就够了，如果你设置的三正本的话,数据在集群里要乘以3倍的空间来寄存，十分消耗磁盘空间，而且对你的整体集群的性能耗费也会更大。（因为leader收到写入数据时候，须要传给一个follower还是2个follower，你要传给2个follower的花，你须要占用更多的网络带宽，而且你传给两个follower的话，必然会导致你须要生产更多的cpu执行）。会减轻更多数据资源的耗费，所以说：咱们Kafak集群部署的时候，应用双正本就能够了。
双正本的状况下，咱们就思考下是否容许数据失落？如果容许数据失落的话，将参数：min.insync.replicas=1，acks=-1（一条数据必须写入ISR里所有正本才算胜利），你写一条数据只有写入leader就算胜利了，不须要期待同步到follower才算写胜利。然而此时如果一个follower宕机了，你写一条数据到leader之后，如果leader也宕机，会导致数据的失落。
所以说，一般来说在双正本的场景下，咱们为了防止数据失落，min.insync.replicas=2，acks=-1，每次写入必须保障ISR里2个正本都写胜利才能够，如果其中一个正本没了，会导致你就没法写入，必须阻塞期待kafka复原。这样就能够保证数据的不失落。然而对吞吐量有肯定影响。
业务场景思考：
你是要计算为客户筹备的财务数据报表，十分严格的数据必须精准的话，精准到每一分钱，你还是得设置成2；
如果做日志剖析的话，你将其设置为1即可。只须要写入到一个正本之后，就认为写入胜利。
num.network.threads： 这个是负责转发申请给理论工作线程的网络申请解决线程的数量（也就是processor线程数），这个默认是3，高负载场景下能够设置大一些。
num.io.threads： 这个是管制理论解决申请的Handler线程池外面线程数量，默认是8，高负载场景下能够设置大一些。
要本人做一些压测，在不同的线程数量的条件下，对整体的生产和生产的吞吐量别离是多少，还得看一下线程越多的时候，对CPU的简单有多大，整体看一下，如果减少一些线程，吞吐量晋升很多，而且CPU负载还能承受。
message.max.bytes：（这个肯定要设置，不然的话，写入数如果比拟大的话，写入数据将会写失败）这个是broker默认能承受的音讯的最大大小，默认是977kb，太小了，能够设置的大一些，个别倡议设置大一些，很多大音讯可能大到几mb，这个设置个10mb，能够思考。
下面是一些比拟惯例的参数：，除了下面的参数外，咱们还须要思考os cache刷新数据到磁盘的参数。
log.flush.interval.messages:指代os cache中打到多少数据时候，刷新数据到磁盘。
log.flush.interval.ms: 指代每多长时间刷新数据到磁盘。
线上的罕用的一个配合，高负载高吞吐的状况下，倡议设置为1分钟
2、操作系统参数
咱们当初须要设置操作系统参数：
文件个数预计： kafka会频繁的创立和批改文件，Kafka上文件的数量大概是：分区数量 （分区总大小 / 日志段大小） 3(.index .timeindex .log)；
比方一个broker上大略有100个分区，每个分区大略是10G的数据，日志段大小是默认的1G，那么就是100 10（分区里的日志段文件数量） 3 = 3000个文件
这个阐明Kafka会频繁地在机器上创立文件，所以你须要设置下一下参数： 把文件描述符开大一点。 这样的话能够容许Kafka创立大量的文件。
ulimit -n 100000： 这个能够设置很大的描述符限度，容许创立大量的文件
磁盘flush工夫：默认是5秒，默认状况下，Kafka是先把数据写入到os cache;而后每隔一段时间，会将os cache外面的数据刷入到磁盘外面。 os cache刷入磁盘，能够设置为几分钟，比方1分钟才刷入磁盘，这样能够大幅度晋升单机的吞吐量。
参考: https://www.cnblogs.com/zengk...。
sysctl -a | grep dirty
vm.dirty_background_bytes = 0vm.dirty_background_ratio = 5 vm.dirty_bytes = 0vm.dirty_expire_centisecs = 3000vm.dirty_ratio = 10vm.dirty_writeback_centisecs = 500vm.dirty_writeback_centisecs： 下面设置的是500，意思是每隔5秒唤醒一次刷磁盘的线程；cat /proc/sys/vm/dirty_writeback_centisecs查看这个值，默认个别是500（单位是1/100秒）。这个参数示意5s的工夫pdflush就会被唤起去刷新脏数据。
vm.dirty_expire_centisecs： 下面设置的是3000 代表：os cache里的数据在3秒后会被刷入磁盘；这个能够设置大一些，设置为：1分钟~2分钟都能够，特地大规模的企业和公司，如果你能够接管机器宕机的时候，数据适当能够失落一些，kafka里的数据能够适当失落一些，然而为了晋升集群的吞吐量的话。能够设置为1分钟~2分钟都能够，然而机器宕机的话，os cahce数据清空，而后数据失落。
你大数据分析类的利用的话，次要是出一些数据报表，不要求数据100%精准的话，容许适当丢一些数据，此时的话，这里给他调大一些是没问题的。
3、JVM跟GC参数
Kafka除了本人内核参数外，还须要思考下JVM参数设置：
批改bin/kafka-start-server.sh中的jvm设置
export KAFKA_HEAP_OPTS=”-Xmx6g -Xms6g -XX:MetaspaceSize=96m -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50 -XX:MaxMetaspaceFreeRatio=80”
-Xmx6g -Xms6g: 这个是设置堆内存大小的。这个肯定要配置的。
-XX:+UseG1GC： 垃圾回收器应用G1垃圾回收器。
-XX:MetaspaceSize: 参考https://www.jianshu.com/p/b44...
3、Kafka集群搭建
1、zk集群搭建
zookeeper进行集群或者单点搭建的话，参考另一篇文章:https://segmentfault.com/a/11...
未完待续......