标签：10 架构设计 zk HW kafka follower 机制 LEO leader

六、简述kafka的Rebalance【偏向实战，有难度】

1、背景

kafka日志：在消息量大、高并发时，经常会出现rebalance中

rebalance会影响kafka性能，会阻塞partition的读写操作

2、了解其机制，以避免rebalance的发生

 

 3、Rebalance是什么

coordinator：leader节点所在的broker，作为一个协调者，监控cg中消费者的存活，判断consumer是否消费超时  

 

七、kafka的副本同步机制

注意：LEO从哪落盘、HW从哪消费【更新】、最后已被消费、最先待消费、起始的offset

leader（处理读写请求）和多个follower（负责数据同步），主备模式

根据offset判断消费到了哪里

 

LEO：待写入数据的index

HW：HW前（下面）的数据对消费者可见，能够被消费者消费

第一条未提交的数据

最后一条已提交的数据

 

leader和follower都有HW，LEO会选择ISR中最小的HW和自身LEO进行写入，LEO落盘后，进行+1

当leader挂掉，变为follower后，follower的HW会覆盖当前节点的HW，从而会导致数据的丢失

消息丢失的解决，会在后面讲述

八、简述kafka的架构设计

 

zk管理集群，存储一些元信息，作为znode中的一个节点

topic类似于queue，特点是可以分区

cg中不同的consumer消费同一topic的不同分区【cg是逻辑上的概念，实际上还是一个消费者】

如果指定同一消费者组的多个消费者同时消费某个分区，则多个消费者则会互斥，消息不会被重复发送

九、kafka中zk的作用（老版本）

1、后续zk的作用越来越小

2、哪些作用

无生产者信息，broker、topic、partition

 

十、kafka中高性能的原因

指其读写很快

顺序写、零拷贝

1、顺序写

kafka是一个日志系统，写到文件中

不是存入内存中，消息堆积能力强

硬盘是用磁头随机读写，而kafka是通过顺序写的方式（HBASE）

2、零拷贝

直接从磁盘读入网卡中

通过操作系统来实现

3、不依赖于java堆内存

使用操作系统的pageCache，进行读写

 

标签：10,架构设计,zk,HW,kafka,follower,机制,LEO,leader
来源： https://www.cnblogs.com/liujinhui/p/15795542.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。