基于Linux内核KeyValue存储系统.docVIP

基于Linux内核KeyValue存储系统 　　摘要：Key-Value存储系统在各种互联网服务中被广泛使用，但现有的Key-Value存储系统通常在用户态空间设计和实现，因为频繁的模式切换和上下文切换，导致访问接口、事务处理效率不高，在高并发、低延迟的数据存储需求中尤为突出。针对该问题，给出了一个内核态Key-Value存储系统的实现――KStore：提供内核空间的索引和内存分配机制，并在此基础上，通过基于内核Socket的远程接口以及基于文件系统的本地接口，保证了KStore的低延迟；同时，通过基于内核多线程的并发处理机制，保证了KStore的并发性。实验结果表明，与Memcached相比，KStore在实时性和并发性方面都取得显著优势。 　　关键词：Key-Value存储系统； Linux内核； 文件系统； 内核Socket； 内核线程； Slab内存分配 　　中图分类号： TP311.52 　　文献标志码：A 　　0 引言 　　Key-Value存储系统（以下简称K/V系统）的数据模型简单，兼容各种数据类型[1]，因此广泛应用于社交网络等各种互联网服务中。通过对其应用场景进行总结，可以发现K/V系统一般被用在高并发、对实时性要求高、本地访问的比例高的数据存储场合[2-3]。然而，现有的K/V系统并不能满足以上需求，主要体现在实时性和并发性两个方面： 　　1）现有的K/V系统实时性不足。由于服务器端和客户端是相互独立的进程，当客户端访问数据时，需要通过进程间通信（Inter-Process Communication， IPC）机制与服务器端交互。然而，多数IPC机制涉及进程上下文切换和数据重复拷贝，增加了通信的延迟。以Memcached[4]为例，当客户端存储数据时，需要将数据通过Socket传递给内核，内核将其封装为网络报文并发送到网络中，当报文到达服务器端时，其内核将数据解封，并传递给Memcached进程。可见，在此过程中，数据经过了多次拷贝，并且客户端和Memcached都需要切换上下文，造成额外的开销。 　　2）现有的K/V系统所能处理的并发请求数有限。一些K/V系统采用了单线程模式，只能串行地接收请求、处理请求；如Redis[5]内部只有一个线程负责处理请求，因此所支持的并发量有限。另一些K/V系统采用了多线程模型，但并发控制不高效；如Memcached使用锁来保护共享资源（如索引、内存池等），处理大量请求时会造成频繁的加锁和解锁，降低了系统的性能[6]。 　　对于以上问题，本文认为可以在操作系统内核层面予以解决[7]，即在内核中实现K/V系统。内核态的K/V系统有两个方面的优势： 　　1）可提供高效的访问接口。由于在内核中，因此其客户端可通过系统调用直接与其通信，无需再通过IPC机制中转。 　　2）可直接调用内核态接口。调用内核态接口时无需上下文切换，相比在用户态调用等价的接口，性能更高；并且，相比用户态接口，内核态接口更加丰富和全面，如可以直接操作内存页、线程，调用网络接口等。 　　因此，本文设计和实现了一种内核态的Key-Value存储系统――KStore。首先，本文实现了KStore的核心：索引和内存分配机制，以高效地存储K/V数据；在此基础上，为了保证KStore的实时性，本文基于系统调用实现了高效的访问接口；最后，为了保证KStore的并发性，本文基于多种内核机制实现了并发请求处理机制。 　　libkstore向上层应用程序提供各种常用的Key-Value接口，如Get、Set等。在内部，libkstore将来自应用程序的请求封装为相应的报文，通过系统调用发送到kstore.ko。应用程序无需关注libkstore与kstore.ko的通信细节，只需调用libkstore提供的接口即可透明地访问KStore中的数据。 　　kstore.ko从上到下分为3个层次，分别是请求接收、请求处理、Key-Value存储引擎。 　　1.1 请求接收层 　　该层负责从接口读取libkstore传递过来的请求报文，将其分发到请求处理层。为了支持远程访问和本地访问，该层同时实现了基于Socket的接口和基于file的接口。 　　1.2 请求处理层 　　该层可细分为session和protocol。session层创建多个工作线程，并发地处理上层分发下来的请求；protocol层向session层提供解析协议的接口。 　　1.3 Key-Value存储引擎层 　　该层负责存储数据，可细分为engine、hash、itemx、item、slab。engine层实现了处理各种Key-Value请求的具体代码，并向上提供Key-Value接口，这些接口与libkstore中的接口