分布式思考：我们需要磁盘吗？

## 前言

历史上看，是先有单机系统，然后再向分布式演变。我们很多分布式的设计，都源自单机的很多经验。这是没错的，因为分布式本来就是众多单机参与的一个集群系统。我们当然要借鉴单机的经验和单机的基础。

但是，分布式源自单机，但不能思想受限于单机。

我的观点：分布式要学习和复用单机的知识，但在一些领域，要勇敢跳出单机的思维限制。

再看一个思考：我们需要磁盘存储吗？

## 单机需要磁盘的意义

这个可以通过之前的文章，分布式下：我们需要fsync吗？里知道，单机下，我们必须用到磁盘。

## 分布式下不同的想法

分布式下，我们需要磁盘吗？

如果你的数据集dataset，完全能被内存所容纳，根据上面这个文章的分析，我们可以知道：我们完全可以不用磁盘。

但是，你会问，如果dataset超过内存的大小，你能不用磁盘吗？

我不能，我必须用到磁盘，但是，这个用法和传统的单机是不同的。

对于单机，所有内存里的数据都必须落盘。

对于分布式集群，只有冷数据需要落盘，热数据，完全可以不落盘。

所谓热数据，就是经常访问的数据。而经常访问的热数据，很多时候，内存已经足够容纳。所以，站在热数据的角度，我们完全可以不落盘。

这带来什么好处？

热数据只所以热，是因为它会多次读写，经常改变，所以如果它落盘，它会占磁盘访问的很大比例。

但如果热数据不落盘，我们就省掉了很大的磁盘开销。如果90%的访问都发生在10%的数据集上，而且我们的内存足以容纳这10%的热数据，那么90%的读写，都和磁盘完全无关。

而且站在分布式角度，我们也不用担心数据丢失，不像单机系统下，必须对这90%的访问（但只针对10%的小额数据），也考虑写盘。传统数据库中，虽然热数据的占比不大，但占用的磁盘IO并不少，这是不划算的。

如果磁盘是整个系统的瓶颈（而且对于数据库系统而言，这是很常见的），这也就意味着，原来的capacity，现在提高了十倍（这里有点夸张或者只是存粹很粗的估计，关键是写、写放大和cache的管理）。这对于未来我的另外一个想法至关重要（后面会有一个专文描述这个观点）。

## BunnyRedis作为案例

BunnyRedis 就是如上设计的。它的热数据，永远只在内存里，不写盘。同时，它假设所有的key都在内存里，所以，如果在内存里找不到这个key，它也可以直接回应客户，没有找到Not Found，这样，就进一步省掉了一个读盘查询操作，同时提高了客户端的Latency和Throughput。（但有trade-off，我们需要用内存存储冷数据的key，但我们假设key是足够小的，一般几个或几十个字节而已，所以，这个代价值得付出）

而且，BunnyRedis里的Kafka还存着一批同样的数据，bunny-redis更不用担心丢数据。但正如上文分析的，Kafka其实也可以不存盘，只要当前的Kafka热数据保存到被所有bunny-redis进程consume掉，那么这些Kafka热数据，从某种角度也可以作为冷数据丢掉（但必须提供一个新的Kafka Log的备份机制，或者整个dataset的snapshot保存，当前还无此功能，所以当前BunnyRedis文档是建议全保留Kafka Log，而且建议在HDD上保留，非常经济）。