访问模式通常有两种：一种是通过函数库调用的方式供外部应用使用，比如，上图中的 libsimplekv.so，就是以动态链接库的形式链接到我们自己的程序中，提供键值存储功能；另一种是通过网络框架以 Socket 通信的形式对外提供键值对操作，这种形式可以提供广泛的键值存储服务
RocksDB 以动态链接库的形式使用，而 Memcached 和 Redis 则是通过网络框架访问
通过网络框架提供键值存储服务，一方面扩大了键值数据库的受用面，但另一方面，也给键值数据库的性能、运行模型提供了不同的设计选择，带来了一些潜在的问题。这个问题称为 I/O 模型设计。不同的 I/O 模型对键值数据库的性能和可扩展性会有不同的影响
如果一个线程既要处理网络连接、解析请求，又要完成数据存取，一旦某一步操作发生阻塞，整个线程就会阻塞住，这就降低了系统响应速度。如果我们采用不同线程处理不同操作，那么，某个线程被阻塞时，其他线程还能正常运行。但是，不同线程间如果需要访问共享资源，那又会产生线程竞争，也会影响系统效率，这又该怎么办呢
索引的作用是让键值数据库根据 key 找到相应 value 的存储位置，进而执行操作
常见的有哈希表、B+ 树、字典树
Memcached 和 Redis 采用哈希表作为 key-value 索引，而 RocksDB 则采用跳表作为内存中 key-value 的索引
键值数据基本都是保存在内存中的，而内存的高性能随机访问特性可以很好地与哈希表 O(1) 的操作复杂度相匹配
SimpleKV 的操作模块就实现了不同操作的具体逻辑：
- 对于 GET/SCAN 操作而言，此时根据 value 的存储位置返回 value 值即可；
- 对于 PUT 一个新的键值对数据而言，SimpleKV 需要为该键值对分配内存空间；
对于 DELETE 操作，SimpleKV 需要删除键值对，并释放相应的内存空间，这个过程由分配器完成。
分配和释放内存
存储模块
常用的内存分配器 glibc 的 malloc 和 free
SimpleKV 重启后能快速重新提供服务，所以，我在 SimpleKV 的存储模块中增加了持久化功能
SimpleKV 就直接采用了文件形式，将键值数据通过调用本地文件系统的操作接口保存在磁盘上。此时，SimpleKV 只需要考虑何时将内存中的键值数据保存到文件中，就可以了
对于每一个键值对，SimpleKV 都对其进行落盘保存。SimpleKV 的数据更加可靠。因为每次都要写盘，SimpleKV 的性能会受到很大影响。
SimpleKV 只是周期性地把内存中的键值数据保存到文件中，可以避免频繁写盘操作的性能影响。SimpleKV 的数据仍然有丢失的风险。Redis 主要通过网络框架进行访问
Redis 数据模型中的 value 类型很丰富
Redis 的持久化模块能支持两种方式：日志（AOF）和快照（RDB）
Redis 支持高可靠集群和高可扩展集群
