1.1 Kafka Broker 工作流程
1.1.1 Zookeeper 存储的 Kafka 信息
1.1.2 Kafka Broker 总体工作流程
1）每一个broker上线时，会在zk中举行注册
2）每个broker中都有一个controller，controller会争先抢占zk中 controller节点的注册权，谁先抢到，谁推选时说了算。如果broker0中的controller中抢到了，那它就是说了算的人。该controller一直监听ids节点是否有挂掉的节点。
3）推选规则是：在ISR中存活为前提，按照AR中排在前面的优先，比方 ar[1,0,2] ,isr[1,0,2],那么Leader会按照1，0，2 举行顺序的轮询。
4）推选出来的新节点，注册到zk中，将信息记录在zk中。
5）其他contorller将zk中的信息同步下来。
6）假定broker中的leader挂掉了，会举行重新的推选。
7）客户端发送消息给Leader，Leader记录数据，落盘，形成Log，Log底层使用的是Segment，Segment底层每一个G，是一个单独的文件，1G内的数据要想查找迅速又分成了两个文件 log和index.
1.2 Kafka 副本
1.2.1副本基本信息 --副本又叫副本因子
（1）Kafka 副本作用：进步数据可靠性。
（2）Kafka 默认副本 1 个，生产环境一般设置为 2 个，保证数据可靠性；太多副本会增加磁盘存储空间，增加网络上数据传输，降低效率。
（3）Kafka 中副天职为：Leader 和 Follower。Kafka 生产者只会把数据发往 Leader， 然后 Follower 找 Leader 举行同步数据。
（4）Kafka 分区中的全部副本（包含Leader）统称为 AR（Assigned Repllicas）。
AR = ISR + OSR
ISR，表示和 Leader 保持同步的 Follower 集合。如果 Follower 长时间未向 Leader 发送通信哀求或同步数据，则该 Follower 将被踢出 ISR。该时间阈值由 replica.lag.time.max.ms 参数设定，默认 30s。Leader 发生故障之后，就会从 ISR 中推选新的 Leader。
OSR，表示 Follower 与 Leader 副本同步时，延长过多的副本.
1.2.2 Leader 和 Follower 故障处置惩罚细节
LEO演示-- 每一个副本最后的偏移量offset + 1
HW(高水位线 High Water) 演示：全部副本中，最小的LEO
由于数据同步的时间先进入Leader,随后同步给Follower，如果Follower挂掉了，Leader和其他的Follower 继续往前存储数据，挂掉的节点从ISR集合中剔除，此时挂掉的Follower又重启了，它会先从上一次挂掉的节点的HW开始同步数据，直到追上最后一个Follower为止,此时会重新回归ISR。
1.3 文件存储与读取
1.3.1 文件存储机制
1）Topic 数据的存储机制
Topic是逻辑上的概念，而partition是物理上的概念，每个partition对应于一个log文件，该log文件中存储的就是Producer生产的数据。Producer生产的数据会被不断追加到该log文件末端，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个partition分为多个segment。每个segment包括：“.index”文件、“.log”文件和.timeindex等文件。这些文件位于一个文件夹下，该文件夹的命名规则为：topic名称+分区序号，比方：first-0。
（2）Topic 数据到底存储在什么位置？
（1）启动生产者，并发送消息。
bin/kafka-console-producer.sh -- bootstrap-server bigdata01:9092 --topic first
>hello world
（2）查看 bigdata01的/opt/installs/kafka3/datas/first-1（first-0、first-2）路径上的文件。
cd /opt/installs/kafka3/datas/first-1/
进入查看：ls
00000000000000000092.index
00000000000000000092.log
00000000000000000092.snapshot
00000000000000000092.timeindex
leader-epoch-checkpoint
partition.metadata
（3）直接查看 log 日志
（4）查看 index 和 log 信息，发现乱码，以是必要通过工具查看 index 和 log 信息。
kafka-run-class.sh kafka.tools.DumpLogSegments --files ./00000000000000000000.index
kafka-run-class.sh kafka.tools.DumpLogSegments --files ./00000000000000000000.timeindex
1.3.2 高效读写数据 （面试题）
1）Kafka 本身是分布式集群，可以采用分区技能，并行度高。
2）读数据采用希罕索引，可以快速定位要消费的数据。
希罕索引（Sparse Index）是数据库索引的一种形式，它并不为表中的每一行都创建一个索引条目，而是选择性地为某些行创建索引条目。这种索引方式特殊适用于大型数据集，尤其是在数据分布非常广大概有大量重复值的环境下，旨在减少索引的大小，从而进步查询性能和降低存储本钱，希罕索引只包含表中部分记录的索引信息，而不是每个记录都有对应的索引项。
3）顺序写磁盘
Kafka 的 producer 生产数据，要写入到 log 文件中，写的过程是一直追加到文件末端， 为顺序写。（官网有数据表明，同样的磁盘，顺序写能到 600M/s，而随机写只有 100K/s。这与磁盘的机器机构有关，顺序写之以是快，是因为其省去了大量磁头寻址的时间。）
4）页缓存 + 零拷贝技能
零拷贝：Kafka的数据加工处置惩罚操作交由Kafka生产者和Kafka消费者处置惩罚。Kafka Broker应用层不关心存储的数据，以是就不消 走应用层，传输效率高。
PageCache页缓存：Kafka重度依靠底层操作系统提供的PageCache功 能。当上层有写操作时，操作系统只是将数据写入 PageCache。当读操作发生时，先从PageCache中查找，如果找不到，再去磁盘中读取。实际上PageCache是把尽可能多的空闲内存都当做了磁盘缓存来使用，如果消费者过来消费，直接从页缓存中，通过网卡发送给消费者，根本就没有去kafka的业务系统中获取数据，以是速率比力快。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
