磁盘缓存--YYCache 设计思路

为了设计一个比较好的磁盘缓存,我调查了大量的开源库,包括 TMDiskCache、PINDiskCache、SDWebImage、FastImageCache 等,也调查了一些闭源的实现,包括 NSURLCache、Facebook 的 FBDiskCache 等。他们的实现技术大致分为三类:基于文件读写、基于 mmap 文件内存映射、基于数据库。

TMDiskCache, PINDiskCache, SDWebImage 等缓存,都是基于文件系统的,即一个 Value 对应一个文件,通过文件读写来缓存数据。他们的实现都比较简单,性能也都相近,缺点也是同样的:不方便扩展、没有元数据、难以实现较好的淘汰算法、数据统计缓慢。

FastImageCache 采用的是 mmap 将文件映射到内存。用过 MongoDB 的人应该很熟悉 mmap 的缺陷:热数据的文件不要超过物理内存大小,不然 mmap 会导致内存交换严重降低性能;另外内存中的数据是定时 flush 到文件的,如果数据还未同步时程序挂掉,就会导致数据错误。抛开这些缺陷来说,mmap 性能非常高。

NSURLCache、FBDiskCache 都是基于 SQLite 数据库的。基于数据库的缓存可以很好的支持元数据、扩展方便、数据统计速度快,也很容易实现 LRU 或其他淘汰算法,唯一不确定的就是数据库读写的性能,为此我评测了一下 SQLite 在真机上的表现。iPhone 6 64G 下,SQLite 写入性能比直接写文件要高,但读取性能取决于数据大小:当单条数据小于 20K 时,数据越小 SQLite 读取性能越高;单条数据大于 20K 时,直接写为文件速度会更快一些。这和 SQLite 官网的描述基本一致。另外,直接从官网下载最新的 SQLite 源码编译,会比 iOS 系统自带的 sqlite3.dylib 性能要高很多。基于 SQLite 的这种表现,磁盘缓存最好是把 SQLite 和文件存储结合起来:key-value 元数据保存在 SQLite 中,而 value 数据则根据大小不同选择 SQLite 或文件存储。NSURLCache 选定的数据大小的阈值是 16K;FBDiskCache 则把所有 value 数据都保存成了文件。

我的 YYDiskCache 也是采用的 SQLite 配合文件的存储方式,在 iPhone 6 64G 上的性能基准测试结果见下图。在存取小数据 (NSNumber) 时,YYDiskCache 的性能远远高出基于文件存储的库;而较大数据的存取性能则比较接近了。但得益于 SQLite 存储的元数据,YYDiskCache 实现了 LRU 淘汰算法、更快的数据统计,更多的容量控制选项。

磁盘缓存--YYCache 设计思路

https://blog.ibireme.com/2015/10/26/yycache/

iOS缓存设计(阅读笔记)

市面上常见的缓存库分类

基于文件系统 :TMDiskCache, PINDiskCache, SDWebImage

优点:实现都比较简单
缺点:不方便扩展、没有元数据、难以实现较好的淘汰算法、数据统计缓慢。

基于mmap :MMKV, FastImageCache,

优点:直接在内存中操作文件,对比文件 I/O 更快
缺点:热数据的文件不要超过物理内存大小,不然 mmap 会导致内存交换严重降低性能,如果数据还未同步时程序挂掉,就会导致数据错误
(关于mmap详解

基于 SQLite : YapDataBase, FMDB,NSURLCache、FBDiskCache

优点: 支持元数据、扩展方便、数据统计速度快,也很容易实现 LRU 或其他淘汰算法
缺点:单条数据较大的时候读写性能较差。

作者:10m每秒滑行
链接:https://www.jianshu.com/p/10331a0941c4
来源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

上一篇:ConcurrentLinkedQueue代码解析


下一篇:PE文件格式图示