2. REDIS基本架构

简单键值数据库构建（SimpleKV）

---

• 1. 存哪些数据（数据模型）

- 基本模型 key-value
  - 重要考虑因素是支持的value类型（redis能得到广泛应用，就是支持多样化类型value）

• 2. 对数据可以做什么操作（操作接口）

- PUT(SET): 新写入或更新一个key-value
- GET：根据一个key读取相应value
- DELETE： 根据一个key删除整个key-value
- SCAN：根据一段key的范围返回相应的value值（如这么一个场景：需要查询一个用户在一段时间内的访问记录）

• 3. 保存（内存还是外存）

内存：读写很快（访问速度百ns级别），潜在风险一旦断电数据丢失
外存：磁盘读写（几ms级别），整体性能会拉低
备注：不同场景具体分析（REDIS为内存键值数据库，此处SimpleKV同redis）

• 4. SimpleKV基本组件

一个键值数据库包括访问框架，索引模块，操作模块和存储模块

image.png

• 4.1访问模式

一种是通过函数库调用方式供外部应用使用，比如上图中 libsimplekv.so, 就是以动态链接库形式链接到我们自己程序，提供键值存储（比如RocksDB）
另一种是通过网络框架以socket通信形式对外提供键值对操作（比如Memcached和Redis）

• 4.1.1 网络框架提供键值存储服务的利与弊

利：扩大键值数据库受用面，降低使用成本
弊：给键值数据库性能/运行模型提供了不同设计选择，带来潜在问题：
1. I/O模型设计：比如客户端发送一个 PUT请求，那么我们会遇到第一个问题：网络连接的处理，请求解析，数据存取处理，是用单线程/多线程还是多进程。如何取舍（具体redis如何做到单线程，高性能，后面会写到）

• 4.2 索引模块（如何定位键值对位置）

1. 常见索引类型：哈希表，B+树，字典树
2. Memcached和Redis采用哈希表作为key-value索引，RocksDB采用跳表作为内存中索引
3. redis为什么采用哈希表作为索引：键值数据基本保存在内存中，内存的高性能随机访问特性可以很好的与哈希表O(1)操作复杂度匹配

• 4.3 操作模块（基于SimpleKV来说）

1. 对于GET/SCAN，根基value存储位置返回值即可
2. 对于PUT/SET，分配内存空间
3. 对于DELETE，删除键值对，释放相应内存空间（分配器来做）

• 4.4 存储模块（内存管理）

1. 采用glibc的malloc和free内存分配器（glibc在处理随机大小内存块时，表现不好，一旦保存键值对数据规模过大，可能造成较严重的内存碎片问题）
2. SimpleKV的持久化，可以将键值数据保存到文件中（后续会说到redis中持久化机制关键设计考虑）

---

• 5. 从SimpleKV到Redis

image.png

变化有：
1. redis通过网络框架访问
2. redis数据模型value类型更丰富，如面向列表的LPUSH/LPOP，面向集合的SADD/SREM
3. redis持久化支持的两种方式：日志（AOF）和快照（RDB）
4. redis支持高可靠集群和高可扩展集群