5.9 KiB
1. 基本架构:一个键值数据库包含什么?
-
更好的学习方式就是先建立起系统观。
-
这也就是说,如果我们想要深入理解和优化 Redis,就必须要对它的总体架构和关键模块有一个全局的认知,然后再深入到具体的技术点。
-
开始构造 SimpleKV 时,首先就要考虑里面可以存什么样的数据,对数据可以做什么样的操作,也就是数据模型和操作接口。它们看似简单,实际上却是我们理解 Redis 经常被用 于缓存、秒杀、分布式锁等场景的重要基础。
-
理解了数据模型,你就会明白,为什么在有些场景下,原先使用关系型数据库保存的数据,也可以用键值数据库保存。例如,用户信息(用户 ID、姓名、年龄、性别等)通常用 关系型数据库保存,在这个场景下,一个用户 ID 对应一个用户信息集合,这就是键值数据库的一种数据模型,它同样能完成这一存储需求。
-
但是,如果你只知道数据模型,而不了解操作接口的话,可能就无法理解,为什么在有些场景中,使用键值数据库又不合适了。例如,同样是在上面的场景中,如果你要对多个用 户的年龄计算均值,键值数据库就无法完成了。因为它只提供简单的操作接口,无法支持复杂的聚合计算。
-
可以存哪些数据?
-
对于键值数据库而言,基本的数据模型是 key-value 模型。
-
不同键值数据库支持的 key 类型一般差异不大,而 value 类型则有较大差别。
-
我们在对键值数据库进行选型时,一个重要地考虑因素是它支持的 value 类型。
-
例如,Memcached 支持的 value 类型仅为 String 类型,而 Redis 支持的 value 类型包括了 String、哈希表、列表、集合等。Redis 能够在实际业务场景中得到广泛的应用, 就是得益于支持多样化类型的 value。
-
从使用的角度来说,不同 value 类型的实现,不仅可以支撑不同业务的数据需求,而且也隐含着不同数据结构在性能、空间效率等方面的差异,从而导致不同的 value 操作之间存 在着差异。
-
可以对数据做什么操作?
-
我们先来了解下 SimpleKV 需要支持的 3 种基本操作,即 PUT、GET 和 DELETE。
- PUT:新写入或更新一个 key-value 对;
- GET:根据一个 key 读取相应的 value 值;
- DELETE:根据一个 key 删除整个 key-value 对。
-
需要注意的是,有些键值数据库的新写 / 更新操作叫 SET。新写入和更新虽然是用一个操作接口,但在实际执行时,会根据 key 是否存在而执行相应的新写或更新流程。
-
在实际的业务场景中,我们经常会碰到这种情况:查询一个用户在一段时间内的访问记录。这种操作在键值数据库中属于 SCAN 操作,即根据一段 key 的范围返回相应的 value 值。因此,PUT/GET/DELETE/SCAN 是一个键值数据库的基本操作集合。
-
我们就要更进一步,考虑一个非常重要的设计问题:键值对保存在内存还是外存?
- 保存在内存的好处是读写很快,毕竟内存的访问速度一般都在百 ns 级别。但是,潜在的风险是一旦掉电,所有的数据都会丢失。
- 保存在外存,虽然可以避免数据丢失,但是受限于磁盘的慢速读写(通常在几 ms 级别),键值数据库的整体性能会被拉低。
- 因此,如何进行设计选择,我们通常需要考虑键值数据库的主要应用场景。
-
SimpleKV 的基本组件
-
采用什么访问模式?
- 访问模式通常有两种:一种是通过函数库调用的方式供外部应用使用,比如,上图中的 libsimplekv.so,就是以动态链接库的形式链接到我们自己的程序中,提供键值存储功能;
- 另一种是通过网络框架以 Socket 通信的形式对外提供键值对操作,这种形式可以提供广泛的键值存储服务。在上图中,我们可以看到,网络框架中包括 Socket Server 和协议解析。
- 不同的键值数据库服务器和客户端交互的协议并不相同,我们在对键值数据库进行二次开发、新增功能时,必须要了解和掌握键值数据库的通信协议,这样才能开发出兼容的客户端。
- 通过网络框架提供键值存储服务,一方面扩大了键值数据库的受用面,但另一方面,也给键值数据库的性能、运行模型提供了不同的设计选择,带来了一些潜在的问题。
-
如何定位键值对的位置?
- 索引的作用是让键值数据库根据 key 找到相应 value 的存储位置,进而执行操作。
-
不同操作的具体逻辑是怎样的?
- 对于 GET/SCAN 操作而言,此时根据 value 的存储位置返回 value 值即可;
- 对于 PUT 一个新的键值对数据而言,SimpleKV 需要为该键值对分配内存空间;
- 对于 DELETE 操作,SimpleKV 需要删除键值对,并释放相应的内存空间,这个过程由分配器完成。
-
如何实现重启后快速提供服务?