【消息队列MQ】【Kafka&Jafka】design-2

源：http://incubator.apache.org/kafka/design.html

Message Persistence and Caching

Don't fear the filesystem!

         Kafka在很大程度上依赖文件系统来实现存储和高速消息缓存。我们普遍认为磁盘是慢的，由此使人们怀疑一个具有持久化功能的系统能否展现足够高的性能。事实上，磁盘的所谓快慢完全取决于我们如何去使用它。一个合适的磁盘结构设计可以足以满足于网络请求。

         问题的关键在于，在过去的十年中磁盘的吐量与其寻道时间关联很大。6块 7200RPM SATA RAID5阵列的写速度差不多是300MB/sec。但是随机读取的速度差不多是50/sec 差不多10000倍的差距。可见线性的读写模式是可预见的最适合。因此，操作系统通过检测和预测进行预读和延迟写。这个问题的进一步讨论在ACM的相关队列论文中有一些介绍。他们发现磁盘顺序访问堪比内存的随机访问。

         现代的操作系统为拟补内存与磁盘效率上的差异，会将主存拿来为磁盘做缓存。几乎所有的现代操作系统都非常乐意做出一点牺牲，在内存空闲的时候恨不得将其全部拿来做磁盘缓存用。所有的磁盘读写将通过这一统一的缓存接口。这一特性一直采纳除非你不直接使用I/O接口。因此，当你操作一份数据时，该数据可能复制到OS的页缓存，也就是说实际上有效的写了两次。

         此外，我们将在JVM之上进行开发，进行过JAVA内存开发的人都知道：

l  对象的存储开销很大，会是实际存储数据的一倍，甚至更糟。

l  JAVA的内存回收机制随着堆的规模增长而略显粗糙并性能下降。

         由于这些原因，使用文件系统和页缓存较好地维护了内存cache和其他的架构。我们需要两倍的可用内存空间以适应全内存的访问需求。就比如，我们需要存储的是一个压缩后的整体架构，而不仅仅是数据对象。为此在一个32GB的内存机器上，我们可能会消耗掉28-30GB的内存空间，这是不用考虑内存回收的。另外，这些缓存可以一直保持着（即被持久化），即使计算机重启，这时需要缓存的重建（10G的cache大约需要10分钟），或者我们直接从头来一遍进行冷启动。

         这大大简化业务逻辑代码，因为这些一致性维护等工作都交给了OS去做。这比一堆数据写入时一锤子买卖要靠谱多了。如果你的磁盘使用有利于线性读取，那么预加载将是一个很好的解决方案。

         这使得设计变得简单：与其我们在内存中维持一坨数据，然后将它刷进文件系统，不如反其道而行。不如直接将其持久化到文件系统。实际上，就是把数据放入OS 的页缓存上，然后让OS flush他到磁盘上。我们只提供一个可配置的flush策略就行了。

         以上的相关论文请参见【here】

2012-08-29 待续