大家好，这里是 菜农曰，欢迎来到我的频道。
充满寒气的互联网如安在面试中脱颖而出，平常积累很重要，八股文更不能少！下面带来的这篇 Kafka 问答希望能够在你的 offer 上增加一把。
Kafka最初是由Linkedin公司开发的，是一个散布式的、可扩展的、容错的、支撑分区的（Partition）、多副本的（replica）、依据Zookeeper结构的发布-订阅音讯体系，Kafka合适离线和在线音讯消费。它是散布式运用体系中的重要组件之一，也被广泛运用于大数据处理。Kafka是用Scala语言开发，它的Java版别称为Jafka。Linkedin于2010年将该体系贡献给了Apache基金会并成为顶级开源项目之一。
Kafka 是个大家伙，本篇将经过40道问答作为路线，由浅入深，最大程度上覆盖整个 Kafka 的问答内容（预习＋温习一步到位）
Kafka 将音讯以 topic 为单位进行概括，发布音讯的程序称为 Producer，消费音讯的程序称为 Consumer。它是以集群的方法运转，能够由一个或多个服务组成，每个服务叫做一个 Broker，Producer 经过网络将音讯发送到 kafka 集群，集群向顾客供给音讯，broker 在中间起到一个署理保存音讯的中转站。
Kafka 中重要的组件
1）Producer： 音讯出产者，发布音讯到Kafka集群的终端或服务
2）Broker：一个 Kafka 节点就是一个 Broker，多个Broker可组成一个Kafka 集群。
假如某个 Topic 下有 n 个Partition 且集群有 n 个Broker，那么每个 Broker会存储该 Topic 下的一个 Partition
假如某个 Topic 下有 n 个Partition 且集群中有 m+n 个Broker，那么只需 n 个Broker会存储该Topic下的一个 Partition
假如某个 Topic 下有 n 个Partition 且集群中的Broker数量小于 n，那么一个 Broker 会存储该 Topic 下的一个或多个 Partition，这种情况尽量避免，会导致集群数据不均衡
3）Topic：音讯主题，每条发布到Kafka集群的音讯都会归集于此，Kafka是面向Topic 的
4）Partition：Partition 是Topic在物理上的分区，一个Topic能够分为多个Partition，每个Partition是一个有序的不可变的记载序列。单一主题中的分区有序，但无法确保主题中一切分区的音讯有序。
5）Consumer：从Kafka集群中消费音讯的终端或服务
6）Consumer Group：每个Consumer都归于一个Consumer Group，每条音讯只能被Consumer Group中的一个Consumer消费，但能够被多个Consumer Group消费。
7）Replica：Partition 的副本，用来确保Partition的高可用性。
8）Controller： Kafka 集群中的其间一个服务器，用来进行Leader election以及各种 Failover 操作。
9）Zookeeper：Kafka 经过Zookeeper来存储集群中的 meta 音讯
- 使用了 PageCache 缓存
- 磁盘次序写
- 零拷贝技能
- pull 拉方法
- Kafka把Topic中一个Partition大文件分红多个小文件段，经过多个小文件段，就简单定期清除或删去现已消费完结的文件，削减磁盘占用
- 经过索引信息能够快速定位Message和承认response的最大巨细
- 经过将索引元数据全部映射到 memory，能够避免 Segment 文件的磁盘I/O操作
- 经过索引文件稀少存储，能够大幅降低索引文件元数据占用空间巨细
优点
- 高性能、高吞吐量、低推迟：Kafka 出产和消费音讯的速度都抵达每秒10万级
- 高可用：一切音讯持久化存储到磁盘，并支撑数据备份避免数据丢掉
- 高并发：支撑数千个客户端一同读写
- 容错性：答应集群中节点失利（若副本数量为n，则答应 n-1 个节点失利）
- 高扩展性：Kafka 集群支撑热伸缩，无须停机
缺陷
- 没有完好的监控东西集
- 不支撑通配符主题挑选
- 日志聚合：可收集各种服务的日志写入kafka的音讯行列进行存储
- 音讯体系：广泛用于音讯中间件
- 体系解耦：在重要操作完结后，发送音讯，由其他服务体系来完结其他操作
- 流量削峰：一般用于秒杀或抢购活动中，来缓冲网站短时刻内高流量带来的压力
- 异步处理：经过异步处理机制，能够把一个音讯放入行列中，但不当即处理它，在需求的时分在进行处理
主题是一个逻辑上的概念，还能够细分为多个分区，一个分区只归于单个主题，许多时分也会把分区称为主题分区（Topic-Partition）。同一主题下的不同分区包含的音讯是不同的，分区在存储层面能够看做一个可追加的日志文件 ，音讯在被追加到分区日志文件的时分都会分配一个特定的偏移量（offset）。offset 是音讯在分区中的仅有标识，kafka 经过它来确保音讯在分区内的次序性，不过 offset 并不跨过分区，也就是说，kafka确保的是分区有序而不是主题有序。
在分区中又引入了多副本（replica）的概念，经过增加副本数量能够进步容灾才能。同一分区的不同副本中保存的是相同的音讯。副本之间是一主多从的联系，其间主副本担任读写，从副本只担任音讯同步。副本处于不同的 broker 中，当主副本呈现异常，便会在从副本中进步一个为主副本。
- 指明Partition的情况下，直接将指明的值作为Partition值
- 没有指明Partition值但有 key 的情况下，将 key 的 Hash 值与 topic 的Partition值进行取余得到Partition值
- 既没有Partition值又没有 key 值的情况下，第一次调用时随机生成一个整数（后面每次调用在这个整数上自增），将这个值与Topic可用的Partition总数取余得到Parittion值，也就是常说的 round-robin 算法
- 方便在集群中扩展，每个 Partition 可用经过调整以适应它地点的机器，而一个Topic又能够有多个Partition组成，因而整个集群就能够适应恣意巨细的数据了
- 能够进步并发，由于能够以Partition为单位进行读写
- 一条音讯发过来首要会被封装成一个 ProducerRecord 方针
- 对该方针进行序列化处理（能够运用默许，也能够自定义序列化）
- 对音讯进行分区处理，分区的时分需求获取集群的元数据，决议这个音讯会被发送到哪个主题的哪个分区
- 分好区的音讯不会直接发送到服务端，而是放入出产者的缓存区，多条音讯会被封装成一个批次（Batch），默许一个批次的巨细是 16KB
- Sender 线程发动以后会从缓存里面去获取能够发送的批次
- Sender 线程把一个一个批次发送到服务端
在Kafka 中 Producer 能够 Batch的方法推送数据抵达进步功率的效果。Kafka Producer 能够将音讯在内存中累积到必定数量后作为一个 Batch 发送恳求。Batch 的数量巨细能够经过 Producer 的参数进行操控，能够从三个维度进行操控
- 累计的音讯的数量（如500条）
- 累计的时刻距离（如100ms）
- 累计的数据巨细（如64KB）
经过增加 Batch 的巨细，能够削减网络恳求和磁盘I/O的频次，详细参数装备需求在功率和时效性做一个权衡。
Kafka选用大部分音讯体系遵从的传统方法：Producer将音讯推送到Broker，Consumer从Broker获取音讯。
假如选用 Push 方法，则Consumer难以处理不同速率的上游推送音讯。
选用 Pull 方法的好处是Consumer能够自主决议是否批量的从Broker拉取数据。Pull方法有个缺陷是，假如Broker没有可供消费的音讯，将导致Consumer不断在循环中轮询，直到新音讯抵达。为了避免这点，Kafka有个参数能够让Consumer堵塞直到新音讯抵达。
负载均衡是指让体系的负载依据必定的规矩均衡地分配在一切参加工作的服务器上，从而最大极限确保体系全体运转功率与稳定性
负载均衡
Kakfa 的负载均衡就是每个 Broker 都有平等的机会为 Kafka 的客户端（出产者与顾客）供给服务，能够负载分散到一切集群中的机器上。Kafka 经过智能化的分区领导者推举来完结负载均衡，供给智能化的 Leader 推举算法，可在集群的一切机器上均匀分散各个Partition的Leader，从而全体上完结负载均衡。
毛病转移
Kafka 的毛病转移是经过运用会话机制完结的，每台 Kafka 服务器发动后会以会话的方法把自己注册到 Zookeeper 服务器上。一旦服务器运转呈现问题，就会导致与Zookeeper 的会话不能坚持从而超时断连，此刻Kafka集群会推举出另一台服务器来彻底代替这台服务器持续供给服务。
Kafka 是一个运用 Zookeeper 构建的散布式体系。Kafka 的各 Broker 在发动时都要在Zookeeper上注册，由Zookeeper一致和谐管理。假如任何节点失利，可经过Zookeeper从先前提交的偏移量中康复，由于它会做周期性提交偏移量工作。同一个Topic的音讯会被分红多个分区并将其散布在多个Broker上，这些分区信息及与Broker的对应联系也是Zookeeper在保护。
- Kafka 迁移东西：它有助于将署理从一个版别迁移到另一个版别
- Mirror Maker：Mirror Maker 东西有助于将一个 Kafka 集群的镜像供给给另一个
- 顾客查看：对于指定的主题集和顾客组，可显现主题、分区、一切者
Consumer Group 是Kafka独有的可扩展且具有容错性的顾客机制。一个组内能够有多个Consumer，它们同享一个全局仅有的Group ID。组内的一切Consumer和谐在一同来消费订阅主题（Topic）内的一切分区（Partition）。当然，每个Partition只能由同一个Consumer Group内的一个Consumer 来消费。消费组内的顾客能够运用多线程的方法完结，顾客的数量一般不超越分区的数量，且二者最好坚持整数倍的联系，这样不会形成有空闲的顾客。
Consumer 订阅的是Topic的Partition，而不是Message。所以在同一时刻点上，订阅到同一个分区的Consumer必然归于不同的Consumer Group
Consumer Group与Consumer的联系是动态保护的，当一个Consumer进程挂掉或许是卡住时，该Consumer所订阅的Partition会被从头分配到改组内的其他Consumer上，当一个Consumer参加到一个Consumer Group中时，同样会从其他的Consumer平分配出一个或许多个Partition到这个新参加的Consumer。
负载均衡
当发动一个Consumer时，会指定它要参加的Group，运用的装备项是：Group.id
为了坚持Consumer与Consumer Group之间的联系，Consumer 会周期性地发送 hearbeat 到 coodinator（和谐者），假如有 hearbeat 超时或未收到 hearbeat，coordinator 会以为该Consumer现已退出，那么它所订阅的Partition会分配到同一组内的其他Consumer上，这个进程称为 rebalance（再平衡）
出产进程中给分区中的音讯供给一个次序ID号，称之为偏移量，偏移量的首要效果为了仅有地区别分区中的每条音讯。Kafka的存储文件都是依照offset.kafka来命名
何时发生
当出产者企图发送音讯的速度快于Broker能够处理的速度时，一般会发生 QueueFullException
怎么处理
首要先进行判断出产者是否能够降低出产速率，假如出产者不能阻挠这种情况，为了处理增加的负载，用户需求增加足够的 Broker。或许挑选出产堵塞，设置Queue.enQueueTimeout.ms 为 -1，经过这样处理，假如行列已满的情况，出产者将安排而不是删去音讯。或许忍受这种异常，进行音讯丢弃。
Cosumer 消费音讯时，想Broker 发出 fetch 恳求去消费特定分区的音讯，Consumer 能够经过指定音讯在日志中的偏移量 offset，就能够从这个方位开始音讯音讯，Consumer 拥有了 offset 的操控权，也能够向后回滚去从头消费之前的音讯。
也能够运用 seek(Long topicPartition) 来指定消费的方位。
Kafka 中的 Partition 是有序音讯日志，为了完结高可用性，需求选用备份机制，将相同的数据仿制到多个Broker上，而这些备份日志就是 Replica，目的是为了 避免数据丢掉。
一切Partition 的副本默许情况下都会均匀地散布到一切 Broker 上,一旦领导者副本地点的Broker宕机，Kafka 会从追随者副本中推举出新的领导者持续供给服务。
Leader： 副本中的领导者。担任对外供给服务，与客户端进行交互。出产者总是向 Leader副本些音讯，顾客总是从 Leader 读音讯
Follower： 副本中的追随者。被迫地追随 Leader，不能与外界进行交给。仅仅向Leader发送音讯，恳求Leader把最新出产的音讯发给它，从而坚持同步。
Replica 能够确保发布的音讯不会丢掉，确保了Kafka的高可用性。而且能够在发生任何机器过错、程序过错或软件升级、扩容时都能出产运用。
Kafka官方供给了MirrorMaker组件，作为跨集群的流数据同步计划。凭借MirrorMaker，音讯能够跨多个数据中心或云区域进行仿制。您能够在自动/被迫场景中将其用于备份和康复，或许在自动/自动计划中将数据放置得更接近用户，或支撑数据本地化要求。
它的完结原理比较简单，就是经过从源集群消费音讯，然后将音讯出产到方针集群，即普通的音讯出产和消费。用户只需经过简单的Consumer装备和Producer装备，然后发动Mirror，就能够完结集群之间的准实时的数据同步.
-
AR：分区中一切副本称为 AR -
ISR：一切与主副本坚持必定程度同步的副本（包含主副本）称为 ISR -
OSR：与主副本滞后过多的副本组成 OSR
Leader 会保护一个与自己基本坚持同步的Replica列表，该列表称为ISR，每个Partition都会有一个ISR，而且是由Leader动态保护。所谓动态保护，就是说假如一个Follower比一个Leader落后太多，或许超越必定时刻未发起数据仿制恳求，则Leader将其从ISR中移除。当ISR中一切Replica都向Leader发送ACK（Acknowledgement承认）时，Leader才commit。
能够经过装备unclean.leader.election ：
- true：答应 OSR 成为 Leader，可是 OSR 的音讯较为滞后，可能会呈现音讯不共同的问题
- false：会一直等候旧 leader 康复正常，降低了可用性
- Broker有必要能够保护和ZooKeeper的衔接，Zookeeper经过心跳机制查看每个结点的衔接。
- 假如Broker是个Follower，它有必要能及时同步Leader的写操作，延时不能太久。
Kafka能够接纳的最大音讯默许为1000000字节，假如想调整它的巨细，可在Broker中修正装备参数：Message.max.bytes的值
但要注意的是，修正这个值，还要一同注意其他对应的参数值是正确的，否则就可能引发一些体系异常。首要这个值要比消费端的fetch.Message.max.bytes（默许值1MB，表明顾客能读取的最大音讯的字节数）参数值要小才是正确的设置，否则Broker就会由于消费端无法运用这个音讯而挂起。
Kafka的Producer有三种ack机制，参数值有0、1 和 -1
- 0： 相当于异步操作，Producer 不需求Leader给予回复，发送完就以为成功，持续发送下一条（批）Message。此机制具有最低推迟，可是持久性可靠性也最差，当服务器发生毛病时，很可能发生数据丢掉。
- 1： Kafka 默许的设置。表明 Producer 要 Leader 承认已成功接纳数据才发送下一条（批）Message。不过 Leader 宕机，Follower 没有仿制的情况下，数据就会丢掉。此机制供给了较好的持久性和较低的推迟性。
- -1： Leader 接纳到音讯之后，还有必要要求ISR列表里跟Leader坚持同步的那些Follower都承认音讯已同步，Producer 才发送下一条（批）Message。此机制持久性可靠性最好，但延时性最差。
在Kafka中，Producers将音讯推送给Broker端，在Consumer和Broker建立衔接之后，会自动去 Pull（或许说Fetch）音讯。这种方法有些优点，首要Consumer端能够依据自己的消费才能当令的去fetch音讯并处理，且能够操控音讯消费的进展（offset）；此外，顾客能够操控每次消费的数，完结批量消费。
Kafka 供给了两套 Consumer API，分为 High-level API 和 Sample API
Sample API
这是一个底层API，它坚持了一个与单一 Broker 的衔接，而且这个API 是彻底无状况的，每次恳求都需求指定 offset 值，因而这套 API 也是最灵敏的。
High-level API
该API封装了对集群中一系列Broker的拜访，能够透明地消费下一个Topic，它自己保护了已消费音讯的状况，即每次消费的都会下一个音讯。High-level API 还支撑以组的方法消费Topic，假如 Consumers 有同一个组名，那么Kafka就相当于一个行列音讯服务，而各个 Consumer 均衡地消费相应Partition中的数据。若Consumers有不同的组名，那么此刻Kafka就相当于一个广播服务，会把Topic中的一切音讯广播到每个Consumer
Topic 中的多个 Partition 以文件夹的方法保存到 Broker，每个分区序号从0递加，且音讯有序。Partition 文件下有多个Segment（xxx.index，xxx.log），Segment文件里的巨细和装备文件巨细共同。默许为1GB，但能够依据实际需求修正。假如巨细大于1GB时，会翻滚一个新的Segment而且以上一个Segment最后一条音讯的偏移量命名。
Kafka创立Topic将分区放置到不同的Broker时遵从以下规矩：
- 副本因子不能大于Broker的个数。
- 第一个分区（编号为0）的第一个副本放置方位是随机从Broker List中挑选的。
- 其他分区的第一个副本放置方位相对于第0个分区顺次往后移。也就是假如有3个Broker，3个分区，假定第一个分区放在第二个Broker上，那么第二个分区将会放在第三个Broker上；第三个分区将会放在第一个Broker上，更多Broker与更多分区依此类推。剩余的副本相对于第一个副本放置方位其实是由
nextReplicaShift决议的，而这个数也是随机发生的。
概念
保存期内保存了Kafka群会集的一切已发布音讯，超越保期的数据将被按整理战略进行整理。默许保存时刻是7天，假如想修正时刻，在server.properties里更改参数log.retention.hours/minutes/ms 的值便可。
整理战略
-
删去：
log.cleanup.policy=delete表明启用删去战略，这也是默许战略。一开始仅仅标记为delete，文件无法被索引。只需过了log.Segment.delete.delay.ms这个参数设置的时刻，才会真实被删去。 -
紧缩：
log.cleanup.policy=compact表明启用紧缩战略，将数据紧缩，只保存每个Key最后一个版其他数据。首要在Broker的装备中设置log.cleaner.enable=true启用 cleaner，这个默许是关闭的。
Kafka一个Message由固定长度的header和一个变长的音讯体body组成。将Message存储在日志时选用不同于Producer发送的音讯格局。每个日志文件都是一个log entries（日志项）序列：
- 每一个log entry包含一个四字节整型数（Message长度，值为1+4+N）。
- 1个字节的magic，magic表明本次发布Kafka服务程序协议版别号。
- 4个字节的CRC32值，CRC32用于校验Message。
- 最终是N个字节的音讯数据。每条音讯都有一个当前Partition下仅有的64位offset。
Kafka没有约束单个音讯的巨细，但一般推荐音讯巨细不要超越1MB，一般一般音讯巨细都在1～10KB之间。
多租户技能（multi-tenancy technology）是一种软件架构技能，它是完结如安在多用户的环境下共用相同的体系或程序组件，而且仍可确保各用户间数据的隔离性。
处理计划
经过装备哪个主题能够出产或消费数据来启用多租户，也有对配额的操作支撑。管理员能够对恳求定义和强制配额，以操控客户端运用的Broker资源。
日志分段（Segment）战略
-
log.roll.hours/ms：日志翻滚的周期时刻，抵达指定周期时刻时，强制生成一个新的Segment，默许值168h（7day）。 -
log.Segment.bytes：每个Segment的最大容量。抵达指定容量时，将强制生成一个新的Segment。默许值1GB（-1代表不约束）。 -
log.retention.check.interval.ms：日志片段文件查看的周期时刻。默许值60000ms。
日志改写战略
Kafka的日志实际上是开始是在缓存中的，然后依据实际参数装备的战略定期一批一批写入到日志文件中，以进步吞吐量。
-
log.flush.interval.Messages：音讯抵达多少条时将数据写入到日志文件。默许值为10000。 -
log.flush.interval.ms：当抵达该时刻时，强制执行一次flush。默许值为null。 -
log.flush.scheduler.interval.ms：周期性查看，是否需求将信息flush。默许为很大的值。
Kafka动态保护了一个同步状况的副本的集合（a set of In-SyncReplicas），简称ISR，在这个集合中的结点都是和Leader坚持高度共同的，任何一条音讯只需被这个集合中的每个结点读取并追加到日志中，才会向外部通知“这个音讯现已被提交”。
kafka 经过装备 producer.type 来承认是异步还是同步，默许是同步
同步仿制
Producer 会先经过Zookeeper识别到Leader，然后向 Leader 发送音讯，Leader 收到音讯后写入到本地 log文件。这个时分Follower 再向 Leader Pull 音讯，Pull 回来的音讯会写入的本地 log 中，写入完结后会向 Leader 发送 Ack 回执，等到 Leader 收到一切 Follower 的回执之后，才会向 Producer 回传 Ack。
异步仿制
Kafka 中 Producer 异步发送音讯是依据同步发送音讯的接口来完结的，异步发送音讯的完结很简单，客户端音讯发送过来以后，会先放入一个 BlackingQueue 行列中然后就返回了。Producer 再敞开一个线程 ProducerSendTread 不断从行列中取出音讯，然后调用同步发送音讯的接口将音讯发送给 Broker。
Producer的这种在内存缓存音讯，当累计抵达阀值时批量发送恳求，小数据I/O太多，会拖慢全体的网络推迟，批量推迟发送事实上进步了网络功率。可是假如在抵达阀值前，Producer不可用了，缓存的数据将会丢掉。
音讯发送时
音讯发送有两种方法：同步 - sync 和 异步 - async。默许是同步的方法，能够经过 producer.type 特点进行装备，kafka 也能够经过装备 acks 特点来承认音讯的出产
-
0：表明不进行音讯接纳是否成功的承认 -
1：表明当 leader 接纳成功时的承认 -
-1：表明 leader 和 follower 都接纳成功的承认
当 acks = 0 时，不好 Kafka 进行音讯接纳承认，可能会由于网络异常，缓冲区满的问题，导致音讯丢掉
当 acks = 1 时，只需 leader 同步成功而 follower 没有完结同步，假如 leader 挂了，就会形成数据丢掉
音讯消费时
Kafka 有两个音讯消费的 consumer 接口，分别是 low-level 和 hign-level
-
low-level：顾客自己保护 offset 等值，能够完结对 kafka 的彻底操控 -
high-level：封装了对 partition 和 offset，运用简单
假如运用高级接口，可能存在一个顾客提取了一个音讯后便提交了 offset，那么还没来得及消费就现已挂了，下次消费时的数据就是 offset + 1 的方位，那么原先 offset 的数据就丢掉了。
流处理就是连续、实时、并发和以逐条记载的方法处理数据的意思。Kafka 是一个散布式流处理渠道，它的高吞吐量、低延时、高可靠性、容错性、高可扩展性都使得Kafka非常合适作为流式渠道。
- 它是一个简单的、轻量级的Java类库，能够被集成到任何Java运用中
- 除了Kafka之外没有任何其他的依赖，使用Kafka的分区模型支撑水平扩容和确保次序性
- 支撑本地状况容错，能够执行非常快速有用的有状况操作
- 支撑 eexactly-once 语义
- 支撑一次处理一条记载，完结 ms 级的推迟
活锁的概念：顾客持续的坚持心跳，但没有进行音讯处理。
为了预防顾客在这种情况一直持有分区，一般会使用 max.poll.interval.ms活泼检测机制，假如调用 Poll 的频率大于最大距离，那么顾客将会自动脱离消费组，以便其他顾客接管该分区
Kafka 的消费单元是 Partition，同一个 Partition 运用 offset 作为仅有标识确保次序性，但这仅仅确保了在 Partition 内部的次序性而不是 Topic 中的次序，因而我们需求将一切音讯发往一致 Partition 才能确保音讯次序消费，那么能够在发送的时分指定 MessageKey，同一个 key 的音讯会发到同一个 Partition 中。
以上就是本篇的全部内容，不要空谈，不要贪懒，和小菜一同做个吹着牛X做架构的程序猿吧~点个重视做个伴，让小菜不再孤单。我们下文见！
今日的你多尽力一点，明天的你就能少说一句求人的话！
我是小菜，一个和你一同变强的男人。
微信公众号已敞开，菜农曰，没重视的同学们记住重视哦！
