Redis高效性探索--线程IO模型，通信协议

Redis线程IO模型

• Redis是单线程，这个毋庸置疑
• Redis单线程能做到这么高的效率？不用怀疑，还有很多其他的服务都是单线程但是也有超高的效率，比如Node.js，Nginx也是单线程。
• Redis单线程高效原因：
  • Redis所有数据都存储在内存中，所有运算都是内存级别的运算，正是因为Redis是单线程，所有要小心使用，我们业务中可能会有一些耗时的操作keys（死亡命令）时间复杂度O(n)，这种一定要谨慎使用，会造成Redis卡顿
• Redis单线程如何处理这么多客户端的并发连接？
  • 多路复用解决此问题，利用操作系统底层的select系列事件轮询API，非阻塞IO的形式，就是java中NIO的理念同样可以在Redis中复用

非阻塞IO

• 当我们通过套接字（socket）利用网络协议进行数据交换（读写）的时候，默认是阻塞的状态，比如read方法要传递进去一个参数n，标识最多读取n个字节后在返回，如果一个字节都没有，线程就会卡主，直到新的数据到来或者连接关闭，read方法才可以返回，线程才能继续处理其他的事务。Write方法一般不阻塞，除非内核为套接字分配的缓冲区已经满，write方法会阻塞，直到缓冲区空闲，在将剩下的写入，如下是redis中socket读写的一个流程。

• 非阻塞IO在套接字对象上提供了一个选项Non_blocking，当这个选项打开时候，读写方法不会阻塞，而是能读多少读多少，能写多少写多少。能读多少取决于内核为套接字分配的读缓冲区内部的数据字节数。写多少取决于内核为套接字分配的写缓冲区空闲空间字节数。读方法和写方法都会通过返回值来告知程序实际读写了多少字节
• 有了非阻塞IO意味着线程无在IO操作时无需阻塞，可以瞬间完成，然后继续别的事件

事件轮询（多路复用）

• 上文中提到的线程读取数据时候，并不是一次性读完，而是取决于缓冲区大小，读取了一部分就返回，那么线程如何知道什么时候才继续读，也就是当数据来了，线程如何得到通知。写也是一样，如果缓冲区满，写不完，剩下的数据什么时候才继续写，线程也需要得到通知。
• 事件轮询API就是用来解决这个问题。最简单的时间轮询API是select函数。操作系统级别的API。
  • 输入是读写描述符列表read_fds&write_fds，输出是与之对应的可读写事件，还提供了timeout参数，
  • 没有事件需要执行的时候最多等待timeout时间线程处于阻塞状态
  • 一旦期间有任何事件到来就可以返回。时间过了之后没有任何事件到来也立刻返回
• 例如RedisClient执行一个 查询命令，client通过socket在select上注册一个read_fds，其他客户端的任何操作也是想select中注册事件，这个时间按定时任务执行，当轮到你执行的时候才执行你的socket事件。如下图

• 每个套接字socket都有对应的读写文件描述符，伪代码描述如下

read_events, write_events = select(read_fds, write_fds, timeout);
for event in read_events:
	handle_read(event.fd);
for event in write_events:
	handle_write(event.fd);
handle_others() //处理其他事件

指令队列

• Redis为每个客户端套接字关联一个指令队列。客户端指令通过队列排队进行顺序处理，先到先服务。

响应队列

• 同样Redis也为每个客户端套接字关联一个响应队列。Redis服务器通过响应队列来将指令结果回复给客户端。如果队列空则空闲，此时可以将当前客户端描述符从write_fds里面移除。等队列有数据在将描述符放入，避免select系统调用立刻返回写时间，结果发现没有数据可以写，空耗CPU资源

定时任务

• 上文中socket注册时间流程中，定时任务是关键的一环，服务器除了处理IO操作以外，还有定时任务。
• Redis的定时任务用来记录需要执行的任务，这些数据被记录在一个被称为“最小堆”的数据结构中。这个堆中最快执行的在最上方。每个循环周期中，Redis服务器端都会对最小堆中已经到实际点的任务进行处理，并将下一个要执行的任务还需要的时间记录下来（此处的时间就是我们注册时间到select中的socket的timeout）。因为Redis知道未来timeout时间内是没有任务，所有可以休眠timeout时间。

通信协议

• Redis序列化方法RESP（Redis Serialization Protocol）。一种直观的文本协议，优势在于简单直观，易于实现，解析性能极好，Redis的高效性的原因之一。
• Redis协议将传输结构分为五种单元类型，每种类型结束都加上回车换行（\r\n）。
  • 单行字符串以“+”符合开头
  • 多行字符串以“$”符号开头，后跟字符串长度
  • 整数以“：”开头，后面跟整数字符串的形式
  • 错误信息以“-”开头。
  • 数组以“*”开头，后面跟数组长度
• 一下示例：

//单行字符串 hello world
+hello world\r\n
//多行字符串hello world
$11\r\nhello world\r\n
//整数1024
:1024\r\n
//错误信息
-WRONGTYPE Operation against a key holding the wrong kind of value\r\n
//数组[1,2,3]
*3\r\b:1\r\n:2\r\n:3
//NULL
$-1\r\n
//空串
$0\r\n\r\n

客户端到服务器通信

• 客户端向服务器发送指令只有一种格式，多行字符串数组。比如一个简单的set指令set myList addfirst，会被序列化如下格式

*3\r\n$3\r\nset\r\n$6\r\nmyList\r\n$8\r\naddfirst\r\n

• 控制台输出这个字符串如下，可以看出来是一个很容易理解的格式：

*3
$3
set
$6
myList
$8
addfirst

服务器到客户端

• 服务器向客户端回复响应信息要支持多种数据结构，所以消息响应在结构上要复杂一点，不过还是基于上文中的规则。

//单行字符串响应
docker-redis:0>set myList addfirst
OK
//OK是单行响应，没有使用引号括起来
+OK

//错误响应
新docker-redis:0>incr myList
"ERR value is not an integer or out of range"
//对字符串自增报错，返回如下
-ERR value is not an integer or out of range

//整数响应
新docker-redis:0>incr books
"1"
//此处1是整数
:1

//多行字符串响应
新docker-redis:0>get myList
"addfirst"
//此处有引号，是多行响应
$8
addfirst

//数组响应
新docker-redis:0>hset myMap name liaojiamin
"1"
新docker-redis:0>hset myMap age 28
"1"
新docker-redis:0>hgetall myMap
 1)  "name"
 2)  "liao"
 3)  "age"
 4)  "28"
 //hgetall返回一个数组，第1,3 是key 2,4 是value，客户端负责将数组组装成字典放回，格式如下
 *4
 $4
 name
 $4
 liao
 $3
 age
 $2
 28

//嵌套方式
新docker-redis:0>scan 0
 1)  "2359296"
 2)     1)   "Phone"
  		2)   "nettyim"
  		3)   "1027"
//用sca扫描以游标形式获取，第一个标识游标值，第二个标识当前游标下的数据返回的数组格式，数组的2个元素存储的数组，数组第二个元素还是数组，三个元素
*2
$1
0
*3
$5
phone
$7
nettyim
$4
1027

• 小结
• • Redis协议中大量冗余的回车换行，但是不影响性能，Redis的序列化协议还是互联网技术领域非常受欢迎的文本协议。技术上，性能的确重要，但是同时兼具简单易用，易实现，这些都是需要权衡。

上一篇：Redis高效性探索–管道