1. 单线程模型
现在开启了三个redis-cli客户端同时执行命令。
-
客户端1设置一个字符串键值对：
127.0.0.1:6379> set hello world
-
客户端2对counter做自增操作：
127.0.0.1:6379> incr counter
-
客户端3对counter做自增操作：
127.0.0.1:6379> incr counter
我们已经知道从客户端发送的命令经历了：发送命令、执行命令、返回结果三个阶段，其中我们重点关注第2步。我们所谓的Redis是采用单线程模型执行命令的是指：虽然三个客户端看起来是同时要求Redis去执行命令的，但微观角度，这些命令还是采用线性方式去执行的，只是原则上命令的执行顺序是不确定的，但一定不会有两条命令被同步执行，如图2 - 3、2 - 4、2 - 5所示，可以想象Redis内部只有一个服务窗口，多个客户端按照它们达到的先后顺序被排队在窗口前，依次接受Redis的服务，所以两条incr命令无论执行顺序，结果一定是2，不会发生并发问题，这个就是Redis的单线程执行模型。
Redis的单线程模型
2. 为什么单线程还能这么快
通常来讲，单线程处理能力要比多线程差，例如有10000公斤货物，每辆车的运载能力是每次200公斤，那么要50次才能完成；但是如果有50辆车，只要安排合理，只需要依次就可以完成任务。那么为什么Redis使用单线程模型会达到每秒万级别的处理能力呢？可以将其归结为三点：
- 纯内存访问：Redis将所有数据放在内存中，内存的响应时长大为约100纳秒，这是Redis达到每秒万级别访问的重要基础。
- 非阻塞IO：Redis使用epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间，如图2 - 6所示。
- 单线程避免了线程切换和竞态产生的消耗：单线程可以简化数据结构和算法的实现，让程序模型更简单；其次多线程避免了在线程竞争同一份共享数据时带来的切换和等待消耗。
虽然单线程给Redis带来很多好处，但还是有一个致命的问题：对于单个命令的执行时间都是有要求的。如果某个命令执行过长，会导致其他命令全部处于等待队列中，迟迟等不到响应，造成客户端的阻塞，对于Redis这种高性能的服务来说是非常严重的，所以Redis是面向快速执行场景的数据库。
键的过期机制
一个Redis中可能会同时存在很多很多的key，这些key中有很大一部分都有过期时间，此时Redis如何 GET key是否过期？
Redis的整体策略：
- 定期删除
- 每取一部分验证过期时间
- 惰性删除
- 发送DEL指令后，服务器端并不会立即删除，如果再访问已标记删除的key，才会删除，同时返回nil.
Redis中并没有采取定时器的方式来实现过期key删除
- 若有多个key过期，也可以通过一个定时器来高效/节省CPU的前提下处理多个key，（优先级队列，时间轮）
- 若是基于定时器实现，就要引入多线程