Kafka设计（2）持久化

参考文档： http://kafka.apache.org/documentation/#design

持久化

不要害怕文件系统

Kafka重度基于文件系统实现消息存储和缓存。基于“磁盘很慢”的观点，人们会担心持久化结构会引起性能竞争。实际上基于如何使用磁盘，磁盘会比人们认为的更快或更慢，正确设计的磁盘结构通常比网络更快。

关键因素是磁盘吞吐量早在10年前就和磁盘寻址延迟无关了。6块7200转SATA硬盘使用JBOD（磁盘簇）配置组成的RAID-5阵列在顺序写入时能达到600MB/s,在随机写入时只有100KB/s,性能相差了6000倍。线性读写是所有使用模式中最可预测的，被操作系统重度优化。现代操作系统提供read-ahead（预读取，cache）技术预先装载多个大块数据，使用write-behind（异步写入，buffer）技术将多个小的逻辑写入合并到一个大的物理写入。在ACM Queue文章中深入讨论了这个问题。他们发现顺序磁盘访问在部分场景下比随机内存访问还要快。

为了补偿性能差异，现代操作系统越发积极使用内存作为磁盘缓存。现代操作系统会积极的将所有剩余内存用于磁盘缓存，在内存回收时只有很小的性能损耗。所有的读写磁盘都通过统一的缓存。这个功能无法通过使用direct IO关闭，假设一个进程维护一个进程内的数据缓存，数据也很可能被操作系统页面缓存重复存储，造成每份数据存储两次。

此外，Kafka构件在JVM上，任何了解JVM内存使用的人都知道以下两件事：

1. 对象的内存负载很高，经常是数据量的两倍甚至更大。
2. Java垃圾回收在堆内存变大时将越来越不变使用和变慢。

基于以上事实，使用文件系统并基于页面缓存要优于在内存缓存维护数据等方式，通过自动访问所有空闲内存近乎加倍了可用缓存大小，通过以压缩字节结构存储而不是独立对象存储又几乎会倍增内存。这样做可能会在32GB内存的服务器上使用28-30GB的缓存并且不用担心GC负担。此外，即使服务重启缓存也会保留温数据，而进程内缓存在重启后需要重新加载（10GB的缓存可能需要10分钟完成加载）或者它需要完全使用冷缓存启动（将导致严重的启动性能问题）。这同样极大地简化了维护文件和缓存相关性的代码逻辑，这个工作交给了操作系统，它会比一次性的进程内处理更高效正确。如果你的磁盘访问大多是线性读取那么read-ahead将在每次磁盘读取是有效的预加载有用的数据到缓存（cache）。

设计建议很简单：相比较于维护内存数据并在内存耗尽时恐慌的输出数据到磁盘的方式，我们调转了先后顺序。所有数据立即写入到文件系统中的持久化日志，而不必刷新到磁盘，这样做实际意味着数据被传递到了内核的页面缓存。

疑问：数据不像数据库那样刷新到磁盘，如何保证数据不丢失，通过集群？

这种风格的页面缓存为中心的设计在Varnish（HTTP 缓存服务器）设计的文章中进行了描述。

满足常量响应时间

消息系统的持久化数据结构通常是每个消费者队列有一个关联的BTree或其他为随机访问设计的数据结构来维护消息的元数据。BTree是最通用的数据结构，在消息系统中能够支持大量种类的事物和非事物语法。 虽然BTree操作耗时为O(log N),通常O(log N)被认为本质上等于常量时间。但实际上BTree进行磁盘操作时带来相当高的成本。磁盘寻址耗时10毫秒，每块磁盘一次只能有一块进行寻址操作，并发被限制了。并且少数磁盘寻址会导致很高的负载。由于存储系统混合很快的缓存操作和很慢的磁盘操作，BTree结构的观测性能通常在数据增大但缓存大小固定时线性增长而不是常量，例如：增大2倍的数据量将导致满上不止2倍。

直觉上，持久化队列构件在简单的读取和追加文件上，和日志方案很相似。这个结构的优势是所有的操作都是 O(1)复杂度，读取和写入不会相互阻塞。由于性能和数据量完全无关，带来明显的性能优势，服务器现在可以充分利用多个便宜、低转速的1T以上的SATA磁盘。虽然寻址性能较弱，这些磁盘在大量读写时，能够以1/3的价格和3倍的容量带来可接受的性能。

访问近乎无限的磁盘空间而不需要担心性能损耗，这意味着我们可以提供与传统消息系统不同的功能。例如，在Kafka，我们可以保留消息相当长一段时间（比如一周），而不是在消息被消费后就删除。这给消费者带来了极大的灵活性。下文将提及。