目录
1、kafka霸道性能之揭开日志底层存储的面纱
2、HW?LEO?你俩一起搞事情?
3、ISR机制底层如何设计?
这是2020年的第一篇文章,新的开始,与君共勉。前文小白简单的去剖析了肌霸先生kafka的一些肌肉群,但是呢,只是远远地看了几眼,今天我们将深层次的从ISR机制,HW,高水位,LEO,日志存储等绕来绕去的名词去真正的靠近肌肉,大饱眼福,撕开Kafka的外衣,文明看肉,肌肉的肉。上文的链接是这个【舔一舔 · 肌霸Kafka】,也欢迎一起去回味一下。文中若有错误之处,欢迎大家留言讨论,谢谢大家。
1、kafka读写霸道性能之揭开日志底层存储的面纱
回顾上文我们知道,Kafka利用操作系统的Page Cache加上磁盘顺序写的机制,将自己的读写能力提升到了极致,高吞吐,低延迟。前文也简单的介绍了partition,日志,kafka的消息格式等,那么这里我们就来看看kafka的日志到底怎样的模样,有什么玄妙?
kafka上创建的一个topic都对应着多个partition,我们假设下topic的命名是orderPush,并且该topic有3个partition,每个partition有三个副本。
kafka有个配置参数log.dirs,所有的数据就是写入到这个目录下面,并且partition这样命名的,orderPush-0,orderPush-1,orderPush-2,分别对应着一个目录。每个目录中都很多个分段文件segment,写入文件会按照顺序写的规则去写入例如 00000000000000000000.log,默认大小为1G,就像我们平时用的logback文件一样,一旦写满,就自动滚动到下一个文件。
记住:kafka永远是顺序写入,文件结尾追加写。
每一个log文件都对应俩个索引文件,一个是位移索引,后缀为.index,0.8版本之后又加入了时间戳索引,后缀为.timeindex,通过索引文件都能够快速地定位到消息。kafak为了节省索引的空间,采取了稀疏索引的策略,参数log.index.interval.bytes定义了log文件每写入多少字节,就会写入一条索引。
读取消息时,采用二分查找法定位到对应的索引,然后根据物理地址和物理位置去定位消息。
02
HW?LEO?你俩一起搞事情?
还记得之前我们讨论过的【舔一舔 · 肌霸Kafka】,kafka通过ISR机制来保证数据的高可用,不丢失,in sync replicas。我们接着讨论的是俩个看起来很酷(hui)炫(se)炸(nan)天(dong)的几个offset,这几个名词都和kafka写入日志紧紧相关,可以说我们理解了他们,才是真正的开始去理解kafka的写入,高可用机制,ISR机制如何运转。
我们需要去理解和掌握上的就是这几个offset是如何变化的。
03
ISR机制底层如何设计
ISR机制是保证数据写入不丢失高可用的核心机制,Kafka是如何为leader Partition维护ISR列表的呢?什么样的follower partition才有资格放入ISR列表中呢?
不过我们也可以思考一下,在线上环境如果配置这样的参数的话,其实也有问题的,一般高并发场景下,大数据量都是瞬间涌入,可能就会导致有些follower Partition因为机器原因或者full GC原因,会偶尔跟不上数据,如果这样的情况重复出现,就会导致某些follower Partition 频繁被踢出ISR列表。这样子其实不是很好。
所以后面版本Kakfa有引入了新的参数,replica.lag.time.max.ms,默认10s,根据时间来判断,落后超过多长时间就剔除,这样子和之前的方案比起来,只要在一定时间内follower partition追上数据同步,就不会频繁被踢出。
时间过得好快,这是2020年的第一篇文章,技术真的需要去耐心钻研,我们的面“肌”之旅还没有结束,本文主要对ISR机制的一些技术点做了剖析,若文中有误,欢迎批评指正。一起成长,一起去积累我们的技术肌肉,我们的目标是什么?大!大!大!