（redis笔记一）怎么构造一个键值数据库？

此笔记为极客时间学习笔记与心得

一，构造一个键值数据库需要什么？

首先要考虑里面可以存什么样的数据，对数据可以做什么样的操作，也就是数据模型和操作接口。它们看似简单，实际上却是我们理解 Redis 经常被用于缓存、秒杀、分布式锁等场景的重要基础。

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

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

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

例如，同样是在上面的场景中，如果你要对多个用户的年龄计算均值，键值数据库就无法完成了。因为它只提供简单的操作接口，无法支持复杂的聚合计算

二，首先键值数据库可以存哪些数据？

对于键值数据库而言，基本的数据模型是 key-value 模型。
例如，“hello”: “world”就是一个基本的 KV 对，其中，“hello”是 key，“world”是 value。
key 是 String 类型， value 是基本数据类型，例如 String、整型等
实际生产环境中的键值数据库来说，value 类型还可以是复杂类型。

不同键值数据库支持的 key 类型一般差异不大，而 value 类型则有较大差别.
Redis 支持的 value 类型包括了 String、哈希表、列表、集合等。Redis 能够在实际业务场景中应用广泛，得益于支持多样化类型的 value。

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

三，可以对数据做什么操作？

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

PUT：新写入或更新一个 key-value 对；
GET：根据一个 key 读取相应的 value 值；
DELETE：根据一个 key 删除整个 key-value 对
有些键值数据库的新写 / 更新操作叫 SET。
新写入和更新虽然是用一个操作接口，但在实际执行时，
会根据 key 是否存在而执行相应的新写或更新流程

当一个键值数据库的 value 类型多样化时，就需要包含相应的操作接口。例如，Redis 的 value 有列表类型，因此它的接口就要包括对列表 value 的操作。后面会具体介绍，不同操作对 Redis 访问效率的影响.

四，一个非常重要的设计问题：键值对保存在内存还是外存？

保存在内存的好处是读写很快，毕竟内存的访问速度一般都在百 ns 级别。但是一旦掉电，所有的数据都会丢失。

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

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

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

五，采用什么访问模式？

访问模式通常有两种：

一种是通过函数库调用的方式供外部应用使用，上图中的 libsimplekv.so
就是以动态链接库的形式链接到我们自己的程序中，提供键值存储功能；

另一种是通过网络框架以 Socket 通信的形式对外提供键值对操作，这种形
式可以提供广泛的键值存储服务。在上图中，网络框架中包括
 Socket Server 和协议解析。

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

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

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

#PUT hello world

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

此时，我们会遇到一个系统设计上的问题，就是网络连接的处理、网络请求的解析，以及数据存取的处理，是用一个线程、多个线程，还是多个进程来交互处理呢？该如何进行设计和取舍呢？我们一般把这个问题称为 I/O 模型设计。不同的 I/O 模型对键值数据库的性能和可扩展性会有不同的影响。

举个例子，如果一个线程既要处理网络连接、解析请求，又要完成数据存取，一旦某一步操作发生阻塞，整个线程就会阻塞住，这就降低了系统响应速度。如果我们采用不同线程处理不同操作，那么，某个线程被阻塞时，其他线程还能正常运行。但是，不同线程间如果需要访问共享资源，那又会产生线程竞争，也会影响系统效率，这又该怎么办呢？所以，这的确是个“两难”选择，需要我们进行精心的设计。

你可能经常听说 Redis 是单线程，那么，Redis 又是如何做到“单线程，高性能”的呢？后面我再和你好好聊一聊。(最新版redis也改已多线程)

六，如何定位键值对的位置？

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

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

索引的类型有很多，常见的有哈希表、B+ 树、字典树等。
不同的索引结构在性能、空间消耗、并发控制等方面具有不同的特征。如果你看过其他键值数据库，就会发现，不同键值数据库采用的索引并不相同，例如，Memcached 和 Redis 采用哈希表作为 key-value 索引，而 RocksDB 则采用跳表作为内存中 key-value 的索引。

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

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

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

这一张并没有结束～