|
|
|
|
|
|
|
|
## 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 需要删除键值对，并释放相应的内存空间，这个过程由分配器完成。
|
|
|
|
|
|
- 如何实现重启后快速提供服务？
|
|
|
- SimpleKV 采用了常用的内存分配器 glibc 的 malloc 和 free，因此，SimpleKV 并不需要特别考虑内存空间的管理问题。
|
|
|
- 因此，分配器是键值数据库中的一个关键因素。Redis 的内存分配器提供了多种选择，分配效率也不一样。
|
|
|
- SimpleKV 只是周期性地把内存中的键值数据保存到文件中，这样可以避免频繁写盘操作的性能影响。但是，一个潜在的代价是 SimpleKV 的数据仍然有丢失的风险。
|
|
|
- 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
