Redis本身的内容比较复杂。如果你上来，你应该研究一个细节点，比如连接池和数据结构。虽然可以直接了解某一点的详细来源内容，甚至尽快解决一些意外，但是容易淹没在失眠的细节中，整体控制不了Redis。
最好先设置“架构”。如果你想掌握Redis，你必须能够理解它的一般结构，然后深入具体的技术点。
要构建像Redis这样的KV数据库，首先要考虑的是：
模型可以存储哪些数据？比如用户信息(用户ID、姓名、年龄、性别等。)，通常使用MySQL。在一个用户ID对应一组用户信息的场景中，它是KV DB的数据模型之一，也可以满足这种存储需求。接口如何操作数据？如果计算多个用户的平均年龄，则KV DB不能胜任。因为只提供简单的操作界面，不支持复杂的聚合计算。所以，首先要了解数据模型和操作界面，才能物尽其用。
数据模型
KV DB，最基础的数据模型是KV模型。选择KV DB时，一个主要因素是它支持的V型：Memcached只支持String V类型，而Redis支持的V类型还包括hash、list、set等。因此，Redis可以得到更广泛的应用。
对于crud boy来说，不同的V类型意味着它可以支持各种服务的数据需求。
===
操作界面
不管是什么数据库，基本操作都逃不开积垢：
PUT:写入或更新新的KV对GET:根据一键读取对应的V值DELETE:根据一键删除整个KV对SCAN操作：根据一段K范围返回内存中对应的V值
内存 or 外存？
，读写快，100 ns级别。风险在于，一旦断电，所有数据都将丢失在外部存储中。虽然可以避免数据丢失，但由于磁盘读写速度较慢(几毫秒级别)，KV DB的整体性能会有所下降。因此，需要根据KV DB的应用场景来选择模型。如果缓存场景中的数据需要快速访问但允许丢失，则使用内存来存储KV数据。
00-1010被函数库调用供外部使用，如libsimpleKV.so，即以动态链接库的形式链接到我们自己的程序，提供KV存储功能，如RocksDB。通过网络框架，提供带有Socket通信的KV对操作可以提供Memcached和Redis等广泛的KV存储服务。通过网络框架提供千伏存储服务：
拓展KV DB的生态为KV DB的性能和运营模式提供了不同的选择，带来了潜在的问题。例如，当客户端发送以下命令时，该命令将被封装在网络数据包中并发送到KV DB:
PUT java边缘
KV网络框架收到网络包并按照对应的协议解析后，就知道客户端要写键值对了，实际写就开始了。
输入输出模型设计了网络连接的处理、客户端请求的分析和数据访问。我们应该选择什么样的线程模型？
线程不仅要处理网络连接、分析请求，还要完成数据访问。一旦某一步操作被阻塞，整个线程都会被阻塞，这会降低系统的响应速度。多线程处理不同的操作，所以当一个线程被阻塞时，其他线程仍然可以正常运行。但是如果不同的线程需要访问共享资源，就会发生线程竞争，影响系统效率。所以这里也需要精心设计。
00-1010，知道了要进行的KV对操作，就得找出要操作的KV对是否存在，这取决于KV DB的索引模块：让KV DB根据键找到对应V的存储位置。
不同Kvdbs采用的索引：
Memcached和Redis使用哈希表RocksDB和跳表通用内存KV DB(如Redis)使用哈希表作为索引，主要是因为其KV基本存储在内存中，而内存的高性能随机访问特性与哈希表O(1)的复杂度相匹配。
Redis的V支持多种类型。当通过索引找到K对应的一个V时，仍然需要从V的复杂结构(如集合或列表)中进一步找到想要的数据，而这个操作本身的效率取决于它的实现结构。Redis使用一些高效的索引结构作为一些V类型的底层数据结构。
00-1010找到v的存放位置后的不同操作：
GET/SCAN根据V的存储位置返回V值PUT为KV对分配内存空间DELETE删除KV对，释放内存空间。在此过程中，
访问模式选型
KV DB的KV对大小不同。如果分配器在处理随机内存块分配时表现不佳，一旦KV对的数据量过大，可能会导致严重的内存碎片。因此，分配器是KV DB中的关键。对于基于内存存储的Redis来说更为重要。Redis的内存分配器提供了多种选择，分配效率也不一样。
虽然KV DB依靠内存存储数据并提供快速访问，但它也希望KV DB重启后能再次快速提供服务，因此在其存储模块中增加了持久化功能。
由于磁盘管理比内存管理复杂，KV DB直接采用文件形式，通过调用本地文件系统的操作界面，将KV数据保存在磁盘中。此时，KV数据库只需考虑何时将内存中的KV数据保存到文件中：
每个KV对都保存在磁盘中，使得数据更加可靠，但每次写入磁盘时，性能受到很大影响，内存中的KV对会定期保存到文件中，避免频繁写入磁盘。但是，存在数据丢失的风险。因此，Redis提供了持久性功能，以及各种执行机制和性能优化点。
Kv-redis架构