原文地址：https://time.geekbang.org/col…
集体博客地址：http://njpkhuan.cn/archives/r…
你好，我是蒋德钧。
咱们晓得，Redis 是典型的键值数据库，所以明天，我筹备手把手地带你构建一个简略的键值数据库。为啥要这么做呢？
还记得我在开篇词说过吗？Redis 自身比较复杂，如果咱们一上来就间接钻研一个个具体的技术点，比方“单线程”“缓存”等，尽管能够间接学习到具体的内容，甚至立马就能解决一些小问题，然而这样学，很容易迷失在细枝末节里。
从我本人的教训来看，更好的学习形式就是先建设起“零碎观”。这也就是说，如果咱们想要深刻了解和优化 Redis，就必须要对它的总体架构和要害模块有一个全局的认知，而后再深刻到具体的技术点。这也是咱们这门课保持的一种讲课形式。
我置信，通过这样一个过程，咱们在实践中定位和解决问题时，就会轻松很多，而且你还能够把这个学习形式迁徙到其余的学习流动上。我心愿你能彻底把握这个学习思路，让本人的学习、工作效率更高。
说远了，还是回到咱们明天的课程主题上。明天，在结构这个简略的键值数据库时，咱们只须要关注整体架构和外围模块。这就相当于医学上在正式解剖人体之前，会先解剖一只小白鼠。咱们通过分析这个最简略的键值数据库，来迅速抓住学习和调优 Redis 的要害。
我把这个简略的键值数据库称为 SimpleKV。须要留神的是，GitHub 上也有一个名为 SimpleKV 的我的项目，这跟我说的 SimpleKV 不是一回事，我说的只是一个具备要害组件的键值数据库架构。
好了，你是不是曾经筹备好了，那咱们就一起来结构 SimpleKV 吧。
开始结构 SimpleKV 时，首先就要思考外面能够存什么样的数据，对数据能够做什么样的操作，也就是数据模型和操作接口。它们看似简略，实际上却是咱们了解 Redis 常常被用于缓存、秒杀、分布式锁等场景的重要根底。
了解了数据模型，你就会明确，为什么在有些场景下，原先应用关系型数据库保留的数据，也能够用键值数据库保留。例如，用户信息（用户 ID、姓名、年龄、性别等）通常用关系型数据库保留，在这个场景下，一个用户 ID 对应一个用户信息汇合，这就是键值数据库的一种数据模型，它同样能实现这一存储需要。
然而，如果你只晓得数据模型，而不理解操作接口的话，可能就无奈了解，为什么在有些场景中，应用键值数据库又不适合了。例如，同样是在下面的场景中，如果你要对多个用户的年龄计算均值，键值数据库就无奈实现了。因为它只提供简略的操作接口，无奈反对简单的聚合计算。
那么，对于 Redis 来说，它到底能做什么，不能做什么呢？只有先搞懂它的数据模型和操作接口，咱们能力真正把“这块好钢用在刀刃上”。
接下来，咱们就先来看能够存哪些数据。
能够存哪些数据？
对于键值数据库而言，根本的数据模型是 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 操作之间存在着差别。
只有深刻地了解了这背地的原理，咱们能力在抉择 Redis value 类型和优化 Redis 性能时，做到熟能生巧。
能够对数据做什么操作？
晓得了数据模型，接下来，咱们就要看它对数据的基本操作了。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 的操作。前面我也会具体介绍，不同操作对 Redis 拜访效率的影响。
说到这儿呢，数据模型和操作接口咱们就结构实现了，这是咱们的根底工作。接下来呢，咱们就要更进一步，思考一个十分重要的设计问题：键值对保留在内存还是外存？
保留在内存的益处是读写很快，毕竟内存的访问速度个别都在百 ns 级别。然而，潜在的危险是一旦掉电，所有的数据都会失落。
保留在外存，尽管能够防止数据失落，然而受限于磁盘的慢速读写（通常在几 ms 级别），键值数据库的整体性能会被拉低。
因而，如何进行设计抉择，咱们通常须要思考键值数据库的次要利用场景。比方，缓存场景下的数据须要能快速访问但容许失落，那么，用于此场景的键值数据库通常采纳内存保留键值数据。Memcached 和 Redis 都是属于内存键值数据库。对于 Redis 而言，缓存是十分重要的一个利用场景。前面我会重点介绍 Redis 作为缓存应用的要害机制、劣势，以及常见的优化办法。
为了和 Redis 保持一致，咱们的 SimpleKV 就采纳内存保留键值数据。接下来，咱们来理解下 SimpleKV 的根本组件。
大体来说，一个键值数据库包含了拜访框架、索引模块、操作模块和存储模块四局部（见下图）。接下来，咱们就从这四个局部动手，持续构建咱们的 SimpleKV。
采纳什么拜访模式？
拜访模式通常有两种：一种是 通过函数库调用的形式供内部利用应用 ，比方，上图中的 libsimplekv.so，就是以动态链接库的模式链接到咱们本人的程序中，提供键值存储性能；另一种是 通过网络框架以 Socket 通信的模式对外提供键值对操作，这种模式能够提供宽泛的键值存储服务。在上图中，咱们能够看到，网络框架中包含 Socket Server 和协定解析。
不同的键值数据库服务器和客户端交互的协定并不相同，咱们在对键值数据库进行二次开发、新增性能时，必须要理解和把握键值数据库的通信协议，这样能力开发出兼容的客户端。
理论的键值数据库也根本采纳上述两种形式，例如，RocksDB 以动态链接库的模式应用，而 Memcached 和 Redis 则是通过网络框架拜访。前面我还会给你介绍 Redis 现有的客户端和通信协议。
通过网络框架提供键值存储服务，一方面扩充了键值数据库的受用面，但另一方面，也给键值数据库的性能、运行模型提供了不同的设计抉择，带来了一些潜在的问题。
举个例子，当客户端发送一个如下的命令后，该命令会被封装在网络包中发送给键值数据库：
PUT hello world键值数据库网络框架接管到网络包，并依照相应的协定进行解析之后，就能够晓得，客户端想写入一个键值对，并开始理论的写入流程。此时，咱们会遇到一个零碎设计上的问题，简略来说，就是网络连接的解决、网络申请的解析，以及数据存取的解决，是用一个线程、多个线程，还是多个过程来交互解决呢？该如何进行设计和取舍呢？咱们个别把这个问题称为 I/O 模型设计。不同的 I/O 模型对键值数据库的性能和可扩展性会有不同的影响。
举个例子，如果一个线程既要解决网络连接、解析申请，又要实现数据存取，一旦某一步操作产生阻塞，整个线程就会阻塞住，这就升高了零碎响应速度。如果咱们采纳不同线程解决不同操作，那么，某个线程被阻塞时，其余线程还能失常运行。然而，不同线程间如果须要访问共享资源，那又会产生线程竞争，也会影响零碎效率，这又该怎么办呢？所以，这确实是个“两难”抉择，须要咱们进行精心的设计。
你可能常常据说 Redis 是单线程，那么，Redis 又是如何做到“单线程，高性能”的呢？前面我再和你好好聊一聊。
如何定位键值对的地位？
当 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 的存储模块了。
如何实现重启后疾速提供服务？
SimpleKV 采纳了罕用的内存分配器 glibc 的 malloc 和 free，因而，SimpleKV 并不需要特地思考内存空间的治理问题。然而，键值数据库的键值对通常大小不一，glibc 的分配器在解决随机的大小内存块调配时，体现并不好。一旦保留的键值对数据规模过大，就可能会造成较重大的内存碎片问题。
因而，分配器是键值数据库中的一个关键因素。对于以内存存储为主的 Redis 而言，这点尤为重要。Redis 的内存分配器提供了多种抉择，调配效率也不一样，前面我会具体讲一讲这个问题。
SimpleKV 尽管依赖于内存保留数据，提供快速访问，然而，我也心愿 SimpleKV 重启后能疾速从新提供服务，所以，我在 SimpleKV 的存储模块中减少了长久化性能。
不过，鉴于磁盘治理要比内存治理简单，SimpleKV 就间接采纳了文件模式，将键值数据通过调用本地文件系统的操作接口保留在磁盘上。此时，SimpleKV 只须要思考何时将内存中的键值数据保留到文件中，就能够了。
一种形式是，对于每一个键值对，SimpleKV 都对其进行落盘保留，这尽管让 SimpleKV 的数据更加牢靠，然而，因为每次都要写盘，SimpleKV 的性能会受到很大影响。
另一种形式是，SimpleKV 只是周期性地把内存中的键值数据保留到文件中，这样能够防止频繁写盘操作的性能影响。然而，一个潜在的代价是 SimpleKV 的数据依然有失落的危险。
和 SimpleKV 一样，Redis 也提供了长久化性能。不过，为了适应不同的业务场景，Redis 为长久化提供了诸多的执行机制和优化改良，前面我会和你逐个介绍 Redis 在长久化机制中的要害设计思考。
小结
至此，咱们结构了一个简略的键值数据库 SimpleKV。能够看到，后面两步咱们是从利用的角度进行设计的，也就是利用视角；前面四步其实就是 SimpleKV 残缺的外部结构，堪称是麻雀虽小，五脏俱全。
SimpleKV 蕴含了一个键值数据库的根本组件，对这些组件有了理解之后，前面在学习 Redis 这个丰盛版的 SimpleKV 时，就会轻松很多。
为了反对更加丰盛的业务场景，Redis 对这些组件或者性能进行了扩大，或者说是进行了精密优化，从而满足了性能和性能等方面的要求。
从这张比照图中，咱们能够看到，从 SimpleKV 演进到 Redis，有以下几个重要变动：
- Redis 次要通过网络框架进行拜访，而不再是动静库了，这也使得 Redis 能够作为一个基础性的网络服务进行拜访，扩充了 Redis 的利用范畴。
- Redis 数据模型中的 value 类型很丰盛，因而也带来了更多的操作接口，例如面向列表的 LPUSH/LPOP，面向汇合的 SADD/SREM 等。在下节课，我将和你聊聊这些 value 模型背地的数据结构和操作效率，以及它们对 Redis 性能的影响。
- Redis 的长久化模块能反对两种形式：日志（AOF）和快照（RDB），这两种长久化形式具备不同的优劣势，影响到 Redis 的拜访性能和可靠性。
- SimpleKV 是个简略的单机键值数据库，然而，Redis 反对高牢靠集群和高可扩大集群，因而，Redis 中蕴含了相应的集群性能撑持模块。
通过这节课 SimpleKV 的构建，我置信你曾经对键值数据库的根本构造和重要模块有了整体认知和深刻理解，这其实也是 Redis 单机版的外围根底。针对刚刚提到的几点 Redis 的重大演进，在接下来的课程中，我会顺次进行重点解说。与此同时，我还会联合实战场景，让你不仅可能了解原理，还能真正学以致用，晋升实战能力。