kafka消息快的原因

大家都知道技术选型上，kafka适合做大数据收集，比如kafka+storm流式计算。
kafka被设计的特点是快，那原因是什么昵？

1.上述消息存储结构的设计kafka消息存储设计

2.page cache

3.生产消费分布式读写

4.批量

存储结构，就是持久化存储用的磁盘，大数据分小文件（segment单元）存储，方便根据offset二分快速查找定位小文件，设计有稀疏索引文件，方便快速查找具体message。
批量可以减少网络请求的次数，这是消息中间件通用的优化点

page cache（参考博文）

在命令行输入cat /proc/meminfo，其中Cached就是Page Cache。Linux总会把系统中还没被应用使用的内存挪来给Page Cache，这是有OS管理的。

image

Page Cache中每个文件是一种多叉搜索树，就跟数据库的索引类似，节点由4k大小的Page组成，可以通过文件的偏移量快速定位到某个Page。

[图片上传中...(image-1ab9a6-1511006412683-0)]

当写操作发生时，它只是将数据写入Page Cache中，并将该页置上dirty标志。

当读操作发生时，它会首先在Page Cache中查找，如果有就直接返回了，没有的话就会从磁盘读取文件写入Page Cache再读取。

可见，只要生产者与消费者的速度相差不大，消费者会直接读取之前生产者写入Page Cache的数据，大家在内存里完成接力，根本没有磁盘访问。

既然linux操作系统有page cache，为什么应用还要引入应用缓存？

Page cache针对文件系统，特点顺序和4k，但是应用层的缓存大多缓存的是中间结果，是经过计算或者裁剪组合后的。所以说这是操作系统不知业务应用，提供的方法论级别的设计。

kafka使用page cache还有一个好处是，Page Cache又不需要GC，是操作系统级别的缓存，即使Kafka重启了，Page Cache数据依然还在。相应的，操作系统crash，会带来数据丢失（那些还没有被真正写盘的数据）。

真正写盘的是fluher内核线程，OS管理

至于写盘的内核线程，如何flush策略，是另一个话题。这也说明想高效使用kafka的化，使用单独的机器部署server端，调整操作系统的page cache相关参数是可以调优的。

消息的写入

写入会在log文件的尾部添加，文件的写入是利用的操作系统的page缓存批量刷盘，所以kafka服务器的操作系统底层要支持，这是kafka吞吐量高能原因之一，写入文件还有两个两个配置参数，消息达到指定数目M，时间超过S秒。这个是broker端的控制

rather than maintain as much as possible in-memory and flush it all out to the filesystem in a panic when we run out of space, we invert that. All data is immediately written to a persistent log on the filesystem without necessarily flushing to disk. In effect this just means that it is transferred into the kernel's pagecache

批量操作

这个是消息中间件都会考虑添加的一个功能，cmq云上服务。这个是producor端的控制

消息的删除

删除的策略，保留N天的数据，会有定时任务定时清理。