fatcache是来自Twitter, 基于SSD上面实现的cache, 使用mc的协议，数据存储在SSD (Ps:memcached是将数据放在内存中)。 fatcache的数据放在SSD(其实机械盘也可以，只是性能不佳), 所以相对于内存cache, 如memcached、redis，能容纳更多数据。 所以叫fat-cache（Ps: 这个是我自己意淫的）, 中文翻译: "死胖子缓存"
- 通过slab管理数据，跟memcached类似，但稍有不同.
- 通过索引查找数据.
- 单线程
- 针对写SSD做了优化
更多的特性在后续详细介绍，这里不能说太多(PS: 不然这节会很长, Orz)。
对于SSD开发来说, 有两种不同的理解:
-
SSD是更快的磁盘，用作存储, 能保证数据的强一致性。
-
SSD是内存的扩展，当作慢内存使用, 作为cache，不要求数据的强一致性。
NOTE: fatcache从名字来看就是作为cache,只是更大更肥的cache。 (PS: 因为放在SSD，正常能容纳更多的数据)
##### a) 为什么选择SSD而不是直接使用内存? #####
-
内存虽然比SSD快了很多, 但是同等密度的容量，价格也高出很多，高帅富就全放内存就好了。
-
虽然时间推移, 数据会越来越多, 需要不断对内存不断横向扩容
-
对于数据来说, 只有很少的一部分数据会被经常访问, 我暂时叫热数据 当冷数据(访问比较少)比例大大高于热数据时, 这种存储方式就很不划算
fatcache比较适合使用在符合下面条件的场景:
- 数据量比较大，屁大的数据内存能放下，成本又不高的，别来凑热闹了好么!!!
- 请求性能可以接收会比全内存差一点，又比DB好一点的地方，这个位置挺好，又挺尴尬的.
也就是很适合那种数据全部放在内存成本太高，放大部分在DB，DB访问压力比较大的尴尬场景. (PS： 这样的条件还看不懂的，也不适合用)
-
fatcache的实际存储数据在SSD，一小部分cache在内存, mc全部内存
-
fatcache多了一层索引。 索引除了快速判断key是否存在，同时用来记录数据所在位置，快速读取value
-
mc 哈希表存储真实数据, fatcache哈希表只存储索引信息
-
fatcache是单线程
-
fatcache不支持二进制协议
-
slab实现上有所区别
-
批量写, fatcache每次写磁盘都是slab为单位, 默认1M, 减少大量的小IO写, 同时避免写放大
-
随机写转化为顺序写
NOTE: fatcache是随机读, 在性能上, 写的性能远好于读, 具体的性能可以参考: Performance
[<下一节 配置参数>](./configure.md)