kafka高吞吐量和日志持久化简单剖析

1、环境搭建

下载完源码后 在源码目录执行 gradle idea 进行构建， 后导入到idea中 即可

下载scala插件

2、kafka吞吐量大的原因（高吞吐量必然以高延迟为代价）：

1、pagecache

服务端直接把消息写入到pagecache 写入磁盘交给操作系统去实现 rabbitmq是写入到jvm内存，然后再找个时间写入到磁盘

优点

1. 避免了每次直接操作磁盘带来的IO损耗

2. 避免了GC ,对象的内存开销很大，通常是真实数据的几倍，而且Java的垃圾回收会随着堆内内存变多而变得缓慢，

3. 即使kafka挂掉 ，pagecache的数据也会存在

4. 消费者可能每次读的时候直接从page cache读取了 不用每次从磁盘读取

5. 复杂的IO处理交给操作系统实现，操作系统对IO有优化

问题

如果此时宕机 pagecache的数据是否会丢失 kafka提供了同步刷盘的参数fsync 但是会影响性能

但是刷盘任务就应该交给操作系统实现，消息的可靠性由多副本机制来保证

我怎么使用（🤔）

2、顺序写

因为使用了追加的方式 所以磁盘顺序写

这个问题要从机械磁盘的结构说起，机械磁盘内部实际上是一张磁盘，通过机械马达控制当前磁头的位置，追加写入的时候，磁头还是在上次写完的位置，不需要移动，因此也叫顺序写入。 🤔可是磁头只有一个啊，但是partiton有多个

可以在server.properties 中设置每个segment的大小 只往最新的segment中写

多个消费者会写partiton怎么办?

3、零拷贝（就是指没有cpu拷贝）

传统

零拷贝

使用了FileChannel的transferto来实现的零拷贝 零拷贝严重依赖操作系统 linux不会限制大小，但是Windows限制每次8m

下面代码对比了零拷贝和传统IO的速度
https://gitee.com/WenHaiGo/code-mark/tree/master/IO/src/zerocopy

4、日志目录

根据偏移量查询 index–>log

如果寻找23对应的日志 就先通过二分法找到22 然后从日志分段文件的656开始找便宜量为23的消息

如果要根据时间来查 ，先去timeindex–>index–>log

kafka-dump-log --files /usr/local/var/lib/kafka-logs/test-2/00000000000000000073.index --print-data-log

5、日志删除

基于时间和基于大小 删除segment

6、日志压缩

没时间看了 凉凉~

问题
1.key是什么？ key会决定消息发送到哪个分区
2、pagecache 是什么 ，如果使用pagecache？ IO流是否都会用到pagecache
3、NIO 和零拷贝到底是什么关系 如何理解NIO？