Redis学习笔记：数据类型的内部编码与单线程架构

前言：最近实习工作比较忙，业余时间在看付磊的《Redis开发与运维》，并结合以前的学习总结，整理这一系列学习笔记，希望小伙伴能有所收益，感谢阅读~

一、数据类型与内部编码

Redis提供了五种数据结构，分别是：String（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合），其数据类型及其内部编码如下图：

Redis数据结构.png

从图中可以看到，每种数据结构其底层实现都有2种或3种编码实现，这样设计有以下好处：

可以改进内部编码，而对外的数据结构和命令没有影响；例如，Redis3.2提供了quicklist，结合了ziplist与linkedlist两者的优势，为列表类型提供了一种更为优秀的内部编码实现，而对外部用户来说基本感知不到其变化。
多种内部编码实现可以在不同场景下发挥各自的优势；例如，ziplist节省内存，但是在列表元素较多的情况下，性能会有所下降，这时候Redis会根据配置选项将列表类型的内部实现转换为linkedlist。

二、单线程架构

1、线程模型：

Redis线程模型采用的是单线程架构，并使用I/O多路复用模型来共同实现高性能的内存数据库服务；Redis客户端与服务端的模型可以简化为下图：

redis请求过程.png

Redis客户端与服务端通过RPC通信，其内部设计了一套专用的文本通讯协议 RESP：Redis Serialization Protoco；Redis客户端调用都会经历发送命令、执行命令、返回结果三个过程；其中第二步是需要重点关注的。

Redis采用单线程来处理命令，所以一条命令从客户端发送到服务端不会立即被执行，所以的命令都会进入一个队列（单线程的特性）中，然后逐个被执行；因此，如果多个客户端同执行命令时，其命令的执行顺序是不确定的，但可以确定的是不会有两天命令被同时执行，因此不存在并发问题（线程不安全问题）。

2、I/O多路复用模型

通常来说，单线程的处理能力要比多线程差，那么为什么单线程的Redis仍然可以那么快呢？可以归结为以下几点：

第一，纯内存访问，Redis将所有数据放在内存中，内存的响应时长大约为100纳秒，这是Redis达到每秒万级别访问的基础；
第二，非阻塞I/0，Redis使用epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间，见下图；
第三，单线程避免了线程切换和竞态产生的消耗；

多路复用模型.png

3、总结

单线程能带来以下好处：

单线程可以简化数据结构和算法的实现，而并发数据结构(多线程)实现起来较为困难，而且测试也比较麻烦；
单线程避免了线程上下文切换和竞态产生的消耗，对于服务端开发而已，锁和线程切换是性能杀手。

单线程存在的问题：对于每个命令的执行时间是有要求的。如果执行时间过长，则会造成其他命令的阻塞，对于Redis的高性能服务来说这是致命的问题，因此Redis是面向快速执行场景的数据库。

三、Redis底层实现

根据以上知识可以继续深入理解Redis的底层实现，总结如下：

1、Redis的线程结构：

1)、I/O业务单线程：

Redis的单线程结构是指其主线程是单线程的，包括I/O时间的处理，以及I/O对应的相关请求的业务处理，此外主线程还负责过期键的处理、复制协调、集群协调等等，这些除了I/O事件（内存数据库无IO事件）之外的逻辑会被封装成周期性任务由主线程周期性地处理。因为单线程的设计，对于客户端的所有读写请求，都由一个主线程串行处理，不存在并发问题，避免了频繁的上下文切换和锁竞争，且在网络上使用epoll，利用epool的非阻塞多路复用特性，不需要在IO上付出代价

2)、异步化组件：

RDB文件、持久化AOF文件等操作不放在主线程里面处理，Redis会在适当时候fork子进程来异步处理这些任务，其线程体系结构如下：

线程体系.png

main eventloop：主线程
child process：子进程，用于处理RDB持久化及AOF持久化等任务
job thread ：异步任务处理线程：BIO组件

BIO组件：在Redis中，异步任务处理线程组被封装在BIO组件中，源文件为bio.h和bio.c。bio异步线程启动时在main方法调用，会生成BIO_NUM_OPS(3)个线程，线程函数为bioProcessBackgroundJobs。BIO线程包括三个线程，分别处理三类任务文件句柄关闭任务：

文件句柄的释放（close）对于操作系统来说是一个比较重的操作，在Redis中，当需要重新创建新的文件句柄，废弃的文件句柄失效的时候，这个废弃的文件句柄将由异步任务处理线程来关闭。
AOF持久化任务：Redis对于AOF文件的持久化有三种策略
1. 关闭AOF功能
2. aof_fsync_everysec策略，即每秒一次，实际上并不是一定一秒钟一次
3. aof_fsync_always策略，即每次IO事件处理完毕，都将AOF持久化

这三种策略分别对应不同的业务场景和用户需求，默认的策略为aof_fsync_everysec，这个时候对于aof缓冲区内容持久化工作会交给异步任务处理线程来处理

内存的释放：释放的空间包括：
1. 对象空间的释放
2. DB空间的异步释放
3. slots-leys空间释

3、redis阻塞原因：

内因：
不合理使用API和数据结构

CPU饱和持久化阻塞：fork阻塞、AOF刷盘阻塞、HugePage写操作阻塞

fork阻塞：fork操作发生在RDB和AOF重写时，Redis主线程调用fork操作产生共享内存的子进程，由子进程完成持久化文件重写工作，如果fork操作本身耗时很长，必然会导致主线程阻塞。
AOF刷盘阻塞：在开启AOF持久化功能时，文件刷盘一般采用一秒一次，后台线程每秒对AOF文件做fsync操作，当硬盘压力过大时，fsync操作需要等待，直到写入完成。如果主线程发现距离上一次的fsync成功超过2秒，为了数据安全性它会阻塞直到后台线程执行fsync操作完成。
子进程在执行重新期间利用linux写时复制技术降低内存开销，因此只有写操作时Redis才复制需要修改的内存页，对于开启Transparent HugePages的操作系统，每次写命令引起的复制内存页单位由4K变为2M，放大了512倍，会拖慢写操作的执行时间，导致大量写操作慢查询。

外因：CPU竞争、内存交换、网络问题

四、应用场景分析比较

应用场景分析：Hash、LSM、B+树实际应用开发中，根据需求的不同进行数据存储技术的选型，常见的存储实现有redis、mysql、Hbase，其底层实现的数据结构分别是：hash、B+树、LSM树，各自的特性如下：

哈希存储引擎是哈希表的持久化实现，支持增、删、改以及随机读取操作，但不支持顺序扫描，对应的存储系统为key-value存储系统。对于key-value的插入以及查询，哈希表的复杂度都是O(1)，明显比树的操作O(n)快,如果不需要有序的遍历数据，哈希表就是最佳选举。
B树存储引擎是B树的持久化实现，不仅支持单条记录的增、删、读、改操作，还支持顺序扫描（B+树的叶子节点之间的指针），对应的存储系统就是关系数据库（Mysql等）。
LSM树（Log-Structured Merge Tree）存储引擎和B树存储引擎一样，同样支持增、删、读、改、顺序扫描操作。而且通过批量存储技术规避磁盘随机写入问题。当然凡事有利有弊，LSM树和B+树相比，LSM树牺牲了部分读性能，用来大幅提高写性能，hbase和levelDB的内部实现数据结构就是LSM树。

参考资料：

1、《Redis开发与运维》付磊、张益军[著]

2、个人学习总结