Day727.键值数据库的基本架构 -Redis 核心技术与实战

键值数据库的基本架构

Hi，我是阿昌，今天学习记录的是关于键值数据库的基本架构。

Redis 是典型的键值数据库，所以准备构建一个简单的键值数据库。

这样子更好的学习方式就是先建立起“系统观”。

把这个简单的键值数据库称为 SimpleKV。

开始构造 SimpleKV 时，首先就要考虑里面可以存什么样的数据，对数据可以做什么样的操作，也就是数据模型和操作接口。

它们看似简单，实际上却是我们理解 Redis 经常被用于缓存、秒杀、分布式锁等场景的重要基础。

理解了数据模型，你就会明白，为什么在有些场景下，原先使用关系型数据库保存的数据，也可以用键值数据库保存。

例如，用户信息（用户 ID、姓名、年龄、性别等）通常用关系型数据库保存，在这个场景下，一个用户 ID 对应一个用户信息集合，这就是键值数据库的一种数据模型，它同样能完成这一存储需求。

但是，如果只知道数据模型，而不了解操作接口的话，可能就无法理解，为什么在有些场景中，使用键值数据库又不合适了。

例如，同样是在上面的场景中，如果你要对多个用户的年龄计算均值，键值数据库就无法完成了。

因为它只提供简单的操作接口，无法支持复杂的聚合计算。

一、可以存哪些数据？

对于键值数据库而言，基本的数据模型是 key-value 模型。

例如，“hello”: “world”就是一个基本的 KV 对，其中，“hello”是 key，“world”是 value。SimpleKV 也不例外。

在 SimpleKV 中，key 是 String 类型，而 value 是基本数据类型，例如 String、整型等。

但是，SimpleKV 毕竟是一个简单的键值数据库，对于实际生产环境中的键值数据库来说，value 类型还可以是复杂类型。

不同键值数据库支持的 key 类型一般差异不大，而 value 类型则有较大差别。

在对键值数据库进行选型时，一个重要的考虑因素是它支持的 value 类型。

例如，Memcached 支持的 value 类型仅为 String 类型，而 Redis 支持的 value 类型包括了 String、哈希表、列表、集合等。

Redis 能够在实际业务场景中得到广泛的应用，就是得益于支持多样化类型的 value。

从使用的角度来说，不同 value 类型的实现，不仅可以支撑不同业务的数据需求，而且也隐含着不同数据结构在性能、空间效率等方面的差异，从而导致不同的 value 操作之间存在着差异。

二、可以对数据做什么操作？

知道了数据模型，接下来，就要看它对数据的基本操作了。

SimpleKV 是一个简单的键值数据库，因此，基本操作无外乎增删改查。

先来了解下 SimpleKV 需要支持的 3 种基本操作，即 PUT、GET 和 DELETE。

• PUT：新写入或更新一个 key-value 对；
• GET：根据一个 key 读取相应的 value 值；
• DELETE：根据一个 key 删除整个 key-value 对。

有些键值数据库的新写 / 更新操作叫 SET。

新写入和更新虽然是用一个操作接口，但在实际执行时，会根据 key 是否存在而执行相应的新写或更新流程。

在实际的业务场景中，经常会碰到这种情况：

查询一个用户在一段时间内的访问记录。这种操作在键值数据库中属于 SCAN 操作，即根据一段 key 的范围返回相应的 value 值。

因此，PUT/GET/DELETE/SCAN 是一个键值数据库的基本操作集合。

此外，实际业务场景通常还有更加丰富的需求，例如，在黑白名单应用中，需要判断某个用户是否存在。

如果将该用户的 ID 作为 key，那么，可以增加 EXISTS 操作接口，用于判断某个 key 是否存在。

对于一个具体的键值数据库而言，可以通过查看操作文档，了解其详细的操作接口。

当然，当一个键值数据库的 value 类型多样化时，就需要包含相应的操作接口。

例如，Redis 的 value 有列表类型，因此它的接口就要包括对列表 value 的操作。

数据模型和操作接口就构造完成了，这是的基础工作。

接下来呢，考虑一个非常重要的设计问题：

键值对保存在内存还是外存？保存在内存的好处是读写很快，毕竟内存的访问速度一般都在百 ns 级别。

但是，潜在的风险是一旦掉电，所有的数据都会丢失。

保存在外存，虽然可以避免数据丢失，但是受限于磁盘的慢速读写（通常在几 ms 级别），键值数据库的整体性能会被拉低。

因此，如何进行设计选择，我们通常需要考虑键值数据库的主要应用场景。

比如，缓存场景下的数据需要能快速访问但允许丢失，那么，用于此场景的键值数据库通常采用内存保存键值数据。

Memcached 和 Redis 都是属于内存键值数据库。

对于 Redis 而言，缓存是非常重要的一个应用场景。

接下来，来了解下 SimpleKV 的基本组件。

大体来说，一个键值数据库包括了访问框架、索引模块、操作模块和存储模块四部分（见下图）。

三、采用什么访问模式？

访问模式通常有两种：

• 一种是通过函数库调用的方式供外部应用使用，比如，上图中的 libsimplekv.so，就是以动态链接库的形式链接到自己的程序中，提供键值存储功能；
• 另一种是通过网络框架以 Socket 通信的形式对外提供键值对操作，这种形式可以提供广泛的键值存储服务。

在上图中，可以看到，网络框架中包括 Socket Server 和协议解析。

不同的键值数据库服务器和客户端交互的协议并不相同，在对键值数据库进行二次开发、新增功能时，必须要了解和掌握键值数据库的通信协议，这样才能开发出兼容的客户端。

实际的键值数据库也基本采用上述两种方式，例如，RocksDB 以动态链接库的形式使用，而 Memcached 和 Redis 则是通过网络框架访问。

通过网络框架提供键值存储服务，一方面扩大了键值数据库的受用面，但另一方面，也给键值数据库的性能、运行模型提供了不同的设计选择，带来了一些潜在的问题。

举个例子，当客户端发送一个如下的命令后，该命令会被封装在网络包中发送给键值数据库：

PUT hello world

键值数据库网络框架接收到网络包，并按照相应的协议进行解析之后，就可以知道，客户端想写入一个键值对，并开始实际的写入流程。

此时，会遇到一个系统设计上的问题，简单来说，就是网络连接的处理、网络请求的解析，以及数据存取的处理，是用一个线程、多个线程，还是多个进程来交互处理呢？该如何进行设计和取舍呢？

一般把这个问题称为 I/O 模型设计。不同的 I/O 模型对键值数据库的性能和可扩展性会有不同的影响。

举个例子，如果一个线程既要处理网络连接、解析请求，又要完成数据存取，一旦某一步操作发生阻塞，整个线程就会阻塞住，这就降低了系统响应速度。

如果采用不同线程处理不同操作，那么，某个线程被阻塞时，其他线程还能正常运行。

但是，不同线程间如果需要访问共享资源，那又会产生线程竞争，也会影响系统效率，这又该怎么办呢？

所以，这的确是个“两难”选择，需要我们进行精心的设计。

四、如何定位键值对的位置？

当 SimpleKV 解析了客户端发来的请求，知道了要进行的键值对操作，此时，SimpleKV 需要查找所要操作的键值对是否存在，这依赖于键值数据库的索引模块。

索引的作用是让键值数据库根据 key 找到相应 value 的存储位置，进而执行操作。

索引的类型有很多，常见的有哈希表、B+ 树、字典树等。不同的索引结构在性能、空间消耗、并发控制等方面具有不同的特征。

如果看过其他键值数据库，就会发现，不同键值数据库采用的索引并不相同，例如，Memcached 和 Redis 采用哈希表作为 key-value 索引，而 RocksDB 则采用跳表作为内存中 key-value 的索引。

一般而言，内存键值数据库（例如 Redis）采用哈希表作为索引，很大一部分原因在于，其键值数据基本都是保存在内存中的，而内存的高性能随机访问特性可以很好地与哈希表 O(1) 的操作复杂度相匹配。

SimpleKV 的索引根据 key 找到 value 的存储位置即可。

但是，和 SimpleKV 不同，对于 Redis 而言，很有意思的一点是，它的 value 支持多种类型，当通过索引找到一个 key 所对应的 value 后，仍然需要从 value 的复杂结构（例如集合和列表）中进一步找到我们实际需要的数据，这个操作的效率本身就依赖于它们的实现结构。

Redis 采用一些常见的高效索引结构作为某些 value 类型的底层数据结构，这一技术路线为 Redis 实现高性能访问提供了良好的支撑。

五、不同操作的具体逻辑是怎样的？

SimpleKV 的索引模块负责根据 key 找到相应的 value 的存储位置。对于不同的操作来说，找到存储位置之后，需要进一步执行的操作的具体逻辑会有所差异。

SimpleKV 的操作模块就实现了不同操作的具体逻辑：

• 对于 GET/SCAN 操作而言，此时根据 value 的存储位置返回 value 值即可；
• 对于 PUT 一个新的键值对数据而言，SimpleKV 需要为该键值对分配内存空间；
• 对于 DELETE 操作，SimpleKV 需要删除键值对，并释放相应的内存空间，这个过程由分配器完成。

不知道你注意到没有，对于 PUT 和 DELETE 两种操作来说，除了新写入和删除键值对，还需要分配和释放内存。

六、如何实现重启后快速提供服务？

SimpleKV 采用了常用的内存分配器 glibc 的 malloc 和 free，因此，SimpleKV 并不需要特别考虑内存空间的管理问题。

但是，键值数据库的键值对通常大小不一，glibc 的分配器在处理随机的大小内存块分配时，表现并不好。

一旦保存的键值对数据规模过大，就可能会造成较严重的内存碎片问题。

因此，分配器是键值数据库中的一个关键因素。

对于以内存存储为主的 Redis 而言，这点尤为重要。

Redis 的内存分配器提供了多种选择，分配效率也不一样。

SimpleKV 虽然依赖于内存保存数据，提供快速访问，但是，我也希望 SimpleKV 重启后能快速重新提供服务，所以，我在 SimpleKV 的存储模块中增加了持久化功能。

不过，鉴于磁盘管理要比内存管理复杂，SimpleKV 就直接采用了文件形式，将键值数据通过调用本地文件系统的操作接口保存在磁盘上。此时，SimpleKV 只需要考虑何时将内存中的键值数据保存到文件中，就可以了。

• 一种方式是，对于每一个键值对，SimpleKV 都对其进行落盘保存，这虽然让 SimpleKV 的数据更加可靠，但是，因为每次都要写盘，SimpleKV 的性能会受到很大影响。

• 另一种方式是，SimpleKV 只是周期性地把内存中的键值数据保存到文件中，这样可以避免频繁写盘操作的性能影响。但是，一个潜在的代价是 SimpleKV 的数据仍然有丢失的风险。和 SimpleKV 一样，Redis 也提供了持久化功能。

七、总结

可以看到，前面两步是从应用的角度进行设计的，也就是应用视角；

后面四步其实就是 SimpleKV 完整的内部构造，可谓是麻雀虽小，五脏俱全。

SimpleKV 包含了一个键值数据库的基本组件，对这些组件有了了解之后，后面在Redis 这个丰富版的 SimpleKV 时，就会轻松很多。

为了支持更加丰富的业务场景，Redis 对这些组件或者功能进行了扩展，或者说是进行了精细优化，从而满足了功能和性能等方面的要求。

从这张对比图中，可以看到，从 SimpleKV 演进到 Redis，有以下几个重要变化：

• Redis 主要通过网络框架进行访问，而不再是动态库了，这也使得 Redis 可以作为一个基础性的网络服务进行访问，扩大了 Redis 的应用范围。
• Redis 数据模型中的 value 类型很丰富，因此也带来了更多的操作接口，例如面向列表的 LPUSH/LPOP，面向集合的 SADD/SREM 等。
• Redis 的持久化模块能支持两种方式：日志（AOF）和快照（RDB），这两种持久化方式具有不同的优劣势，影响到 Redis 的访问性能和可靠性。
• SimpleKV 是个简单的单机键值数据库，但是，Redis 支持高可靠集群和高可扩展集群，因此，Redis 中包含了相应的集群功能支撑模块。

SimpleKV和Redis的对比：

• 【数据结构】上缺乏广泛的数据结构支持：比如支持范围查询的SkipList，和Stream等等数据结构
• 【高可用】上缺乏，哨兵或者master-slaver模式的高可用设计
• 【横向扩展】上缺乏集群和分片功能
• 【在内存安全性】上，缺乏内存过载时候的key淘汰算法的支持
• 【内存利用率】没有充分对数据结构优化提高内存利用率，例如使用压缩性的数据结构
• 【功能扩展】需要具备后续功能的拓展
• 【不具备事务性】无法保证多个操作的原子性

---