1、环境搭建
下载完源码后 在源码目录执行 gradle idea 进行构建, 后导入到idea中 即可
下载scala插件
2、kafka吞吐量大的原因(高吞吐量必然以高延迟为代价):![](https://i-blog.csdnimg.cn/blog_migrate/0331ddfa9b877e96ab13872939f28d6f.png)
1、pagecache
服务端直接把消息写入到pagecache 写入磁盘交给操作系统去实现 rabbitmq是写入到jvm内存,然后再找个时间写入到磁盘
优点
避免了每次直接操作磁盘带来的IO损耗
避免了GC ,对象的内存开销很大,通常是真实数据的几倍,而且Java的垃圾回收会随着堆内内存变多而变得缓慢,
即使kafka挂掉 ,pagecache的数据也会存在
消费者可能每次读的时候直接从page cache读取了 不用每次从磁盘读取
复杂的IO处理交给操作系统实现,操作系统对IO有优化
问题
如果此时宕机 pagecache的数据是否会丢失 kafka提供了同步刷盘的参数fsync 但是会影响性能
但是刷盘任务就应该交给操作系统实现,消息的可靠性由多副本机制来保证
我怎么使用(🤔)
2、顺序写
![](https://gitee.com//WenHaiGo/blogImage/raw/master/img/20200321154210.png)
因为使用了追加的方式 所以磁盘顺序写
这个问题要从机械磁盘的结构说起,机械磁盘内部实际上是一张磁盘,通过机械马达控制当前磁头的位置,追加写入的时候,磁头还是在上次写完的位置,不需要移动,因此也叫顺序写入。 🤔可是磁头只有一个啊,但是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?