最近了解到微信开源了一个高性能的key-value组件MMKV, 想写一篇文章做一下记录.
MMKV
是基于mmap
内存映射的key-value
组件, 底层序列化/反序列化使用protobuf
实现, 性能高, 稳定性强.
mmap是什么?
-
mmap
是一种内存映射文件的方法, 将一个文件或者其他对象映射到进程的地址空间, 实现文件磁盘地址
和进程虚拟地址空间中一段虚拟地址
的一一对应关系. - 实现这样的映射关系后, 进程就可以采用
指针
的方式读写操作这一段内存, 而系统会自动回写脏页面到对应的文件磁盘上, 即完成了对文件的操作而不必再调用read, write等系统调用函数. - 与此同时, 内核空间对这段区域的修改也直接反应用户空间, 从而可以实现不同进程间的文件共享.
进程的虚拟地址空间
, 由多个虚拟内存区域
构成(text数据段(代码段
)、初始数据段
、BSS数据段
、堆
、栈
和内存映射
), 虚拟内存区域是进程的虚拟地址空间中的一个同质区间, 即具有同样特性的连续地址范围.
为内存映射服务的地址空间处在堆栈之间的空余部分.
linux内核使用 vm_area_struct
结构来表示一个独立的虚拟内存区域, 由于每个不同质的虚拟内存区域功能和内部机制都不同, 因此一个进程使用多个 vm_area_struct
结构来表示不同类型的虚拟内存区域. 各个 vm_area_struct
结构使用链表或者树形结构链接.
vm_area_struct
结构中包含区域起始和终止地址, 以及其他相关信息, 也包含一个 vm_ops
指针, 这可以引出所有针对这个区域可以使用的系统调用函数, 因此, 进程对某一虚拟内存区域的任何操作需要用到的信息, 都可以从 vm_area_struct
中获得.
mmap
函数会创建一个新的 vm_area_struct
结构, 并将其与文件的物理磁盘地址相连.
mmap
内存映射原理
进程启动映射过程,并在虚拟地址空间中为映射创建虚拟映射区域.
-> 进程在用户空间调用库函数mmap
, 原型:void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);
-> 在当前进程的虚拟地址空间中, 寻找一段空闲的连续虚拟地址
-> 为虚拟区分配一个vm_area_struct
结构, 并对这个结构的各个域进行初始化.
-> 将新建的虚拟区结构
插入到进程的虚拟地址区域
链表或者树中.调用内核空间的系统函数
mmap
, 实现文件物理地址和进程虚拟地址的一一映射关系.
-> 为映射分配了新的虚拟地址区域后,通过待映射的文件指针
,在文件描述符表
中找到对应的文件描述符
,通过文件描述符,链接到内核“已打开文件集”中该文件的文件结构体(struct file
),每个文件结构体维护着和这个已打开文件相关各项信息.
-> 通过该文件的文件结构体
,链接到file_operations
模块,调用内核函数mmap
,其原型为:int mmap(struct file *filp, struct vm_area_struct *vma)
,不同于用户空间库函数.
-> 内核mmap
函数通过虚拟文件系统inode
模块定位到文件磁盘物理地址
.
-> 通过remap_pfn_range
函数建立页表,即实现了文件地址
和虚拟地址区域
的映射关系。此时,这片虚拟地址并没有任何数据关联到主存中.
这里可能有点问题(?)
- 进程发起对这片映射空间的
访问
,引发缺页异常(无数据),实现文件内容到物理内存(主存)的拷贝.
注:前两个阶段仅在于创建虚拟区间并完成地址映射,但是并没有将任何文件数据的拷贝至主存。真正的文件读取是当进程发起读或写操作时。
-> 进程的读或写
操作访问虚拟地址空间
这一段映射地址,通过查询页表,发现这一段地址并不在物理页面上。因为目前只建立了地址映射
,真正的硬盘数据还没有拷贝到内存中,因此引发缺页异常
。
-> 缺页异常进行一系列判断,确定无非法操作后,内核发起请求调页
过程。
-> 调页过程先在交换缓存空间(swap cache
)中寻找需要访问的内存页,如果没有则调用nopage
函数把所缺的页从磁盘装入到主存中。
-> 之后进程即可对这片主存进行读或者写
的操作,如果写操作改变了其内容,一定时间后系统会自动回写脏页面
到对应磁盘地址
,也即完成了写入到文件的过程。
注:修改过的脏页面并不会立即更新回文件中,而是有一段时间的延迟,可以调用 msync()
来强制同步, 这样所写的内容就能立即保存到文件里了。
mmap与常规文件操作的区别
常规文件操作为了提高读写效率和保护磁盘,使用了页缓存
机制。
读文件时, 将文件页从磁盘拷贝到页缓存, 由于页缓存处在内核空间,不能被用户进程直接寻址
,所以还需要将页缓存中数据页再次拷贝到内存对应的用户空间中。这样,通过了两次数据拷贝过程,才能完成进程对文件内容的获取任务。
写操作也是一样,待写入的 buffer
在内核空间不能直接访问,必须要先拷贝至内核空间对应的主存,再写回磁盘中(延迟写回),也是需要两次数据拷贝。
使用 mmap
操作文件中, 创建新的虚拟内存区域
, 建立内核空间到用户空间的虚拟地址空间映射这两步,使得磁盘和用户空间的数据可以直接传输, 无需在内核空间作数据拷贝.
总而言之, 常规文件操作需要从磁盘到页缓存再到用户主存的两次数据拷贝。而mmap
操控文件,只需要从磁盘到用户主存的一次数据拷贝过程.
mmap
的关键点是实现了用户空间和内核空间的数据直接交互而省去了空间不同数据不通的繁琐过程。因此 mmap
效率更高.
MMKV的起源
- 在微信客户端的日常运营中,有时会发生因为特殊文字引起系统的 crash,
- 微信的设计的技术方案是在关键代码前后进行计数器的加减,通过检查计数器的异常,来发现引起闪退的异常文字.
- 在会话列表、会话界面等有大量 cell 的地方,希望新加的计时器不会影响滑动性能;
- 另外这些计数器还要永久存储下来——因为闪退随时可能发生.
- 这就需要一个性能非常高的通用 key-value 存储组件, 考虑到这个防 crash 方案最主要的诉求还是实时写入,而 mmap 内存映射文件刚好满足这种需求.
MMKV的原理
-
内存准备
通过 mmap 内存映射文件,提供一段可供随时写入的内存块,App 只管往里面写数据,由操作系统负责将内存回写到文件,不必担心 crash 导致数据丢失。 -
数据组织
数据序列化方面我们选用 protobuf 协议,pb 在性能和空间占用上都有不错的表现。 -
写入优化
考虑到主要使用场景是频繁地进行写入更新,我们需要有增量更新的能力。我们考虑将增量 kv 对象序列化后,append 到内存末尾。 -
空间增长
使用 append 实现增量更新带来了一个新的问题,就是不断 append 的话,文件大小会增长得不可控。我们需要在性能和空间上做个折中。
MMKV的使用
if let mmkv = MMKV.default() {
mmkv.setBool(true, forKey: "bool")
mmkv.setInt32(1, forKey: "int32")
mmkv.setFloat(1.1, forKey: "float")
mmkv.setObject("hello", forKey: "string")
mmkv.setObject(NSDate(), forKey: "date")
let data = "world".data(using: .utf8)
mmkv.setObject(data!, forKey: "data")
let boolValue = mmkv.getBoolForKey("bool")
let intValue = mmkv.getInt32ForKey("int32")
let floatValue = mmkv.getFloatForKey("float")
let stringValue = mmkv.getObjectOf(NSString.self, forKey: "string")
let dateValue = mmkv.getObjectOf(NSDate.self, forKey: "date")
let dataValue = mmkv.getObjectOf(NSData.self, forKey: "data")
}
MMKV的安装
- 更新
repo
库:pod repo update
- 在
Podfile
中添加pod install