单线程模型
Redis客户端对服务端的每次调用都经历了发送命令，执行命令，返回结果三个过程。其中执行命令阶段，由于Redis是单线程来处理命令的，所有每一条到达服务端的命令不会立刻执行，所有的命令都会进入一个队列中，然后逐个被执行。并且多个客户端发送的命令的执行顺序是不确定的。但是可以确定的是不会有两条命令被同时执行，不会产生并发问题，这就是Redis的单线程基本模型。
1. redis单线程问题
单线程指的是网络请求模块使用了一个线程（所以不需考虑并发安全性），即一个线程处理所有网络请求，其他模块仍用了多个线程。
2. 为什么说redis能够快速执行
(1) 绝大部分请求是纯粹的内存操作（非常快速）
(2) 采用单线程,避免了不必要的上下文切换和竞争条件
(3) 非阻塞IO - IO多路复用，Redis采用epoll做为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接，读写，关闭都转换为了时间，不在I/O上浪费过多的时间。
Redis采用单线程模型，每条命令执行如果占用大量时间，会造成其他线程阻塞，对于Redis这种高性能服务是致命的，所以Redis是面向高速执行的数据库。
3. redis的内部实现
内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时间 这3个条件不是相互独立的，特别是第一条，如果请求都是耗时的，采用单线程吞吐量及性能可想而知了。应该说redis为特殊的场景选择了合适的技术方案。
4. Redis关于线程安全问题
redis实际上是采用了线程封闭的观念，把任务封闭在一个线程，自然避免了线程安全问题，不过对于需要依赖多个redis操作的复合操作来说，依然需要锁，而且有可能是分布式锁。
另一篇对redis单线程的理解：Redis单线程理解
个人理解
redis分客户端和服务端，一次完整的redis请求事件有多个阶段（客户端到服务器的网络连接-->redis读写事件发生-->redis服务端的数据处理（单线程）-->数据返回）。平时所说的redis单线程模型，本质上指的是服务端的数据处理阶段，不牵扯网络连接和数据返回，这是理解redis单线程的第一步。接下来，针对不同阶段分别阐述个人的一些理解。
1：客户端到服务器的网络连接
首先，客户端和服务器是socket通信方式，socket服务端监听可同时接受多个客户端请求，这点很重要，如果不理解可先记住。注意这里可以理解为本质上与redis无关，这里仅仅做网络连接，或者可以理解为，为redis服务端提供网络交互api。
假设建立网络连接需要30秒（为了更容易理解，所以时间上扩大了N倍）
2：redis读写事件发生并向服务端发送请求数据
首先确定一点，redis的客户端与服务器端通信是基于TCP连接（不懂去看，基础很重要），第一阶段仅仅是建立了客户端到服务器的网络连接，然后才是发生第二阶段的读写事件。
完成了上一个阶段的网络连接，redis客户端开始真正向服务器发起读写事件，假设是set（写）事件，此时redis客户端开始向建立的网络流中送数据，服务端可以理解为给每一个网络连接创建一个线程同时接收客户端的请求数据。
假设从客户端发数据，到服务端接收完数据需要10秒。
3：redis服务端的数据处理
服务端完成了第二阶段的数据接收，接下来开始依据接收到的数据做逻辑处理，然后得到处理后的数据。数据处理可以理解为一次方法调用，带参调用方法，最终得到方法返回值。不要想复杂，重在理解流程。
假设redis服务端处理数据需要0.1秒
4：数据返回
这一阶段很简单，当reids服务端数据处理完后 就会立即返回处理后的数据，没什么特别需要强调的。
假设服务端把处理后的数据回送给客户端需要5秒。
那么什么是Reids的单线程
第一阶段说过，redis是以socket方式通信，socket服务端可同时接受多个客户端请求连接，也就是说，redis服务同时面对多个redis客户端连接请求，而redis服务本身是单线程运行。
假设，现在有A,B,C,D,E五个客户端同时发起redis请求，A优先稍微一点点第一个到达，然后是B，C，D，E依次到达，此时redis服务端开始处理A请求，建立连接需要30秒，获取请求数据需要10秒，然后处理数据需要0.1秒，回送数据给客户端需要5秒，总共大概需要45秒。也就是说，下一个B请求需要等待45秒，这里注意，也许这五个几乎同时请求，由于socket可以同时处理多个请求，所以建立网络连接阶段时间差可忽略，但是在第二阶段，服务端需要什么事都不干，坐等10秒中，对于CPU和客户端来说是无法忍受的。所以说单线程效率非常，非常低，但是正是因为这些类似问题，Redis单线程本质上并不是如此运行。接下来讨论redis真正的单线程运行方式。
客户端与服务端建立连接交由socket，可以同时建立多个连接（这里应该是多线程/多进程），建立的连接redis是知道的（为什么知道，去看socket编程，再次强调基础很重要），然后redis会基于这些建立的连接去探测哪个连接已经接收完了客户端的请求数据（注意：不是探测哪个连接建立好了，而是探测哪个接收完了请求数据），而且这里的探测动作就是单线程的开始，一旦探测到则基于接收到的数据开始数据处理阶段，然后返回数据，再继续探测下一个已经接收完请求数据的网络连接。注意，从探测到数据处理再到数据返回，全程单线程。这应该就是所谓的redis单线程。至于内部有多复杂我们无需关心，我们追求的是理解流程，苛求原理，但不能把内脏都挖出来。
从探测到接受完请求数据的网络连接到最终的数据返回，服务器只需要5.1秒，这个时间是我放大N倍后的数据，实际时间远远小于这个，可能是5.1的N万分之一时间，为什么这么说，因为数据的处理是在本地内存中，速度有多快任你想象，最终的返回数据虽然牵扯到网络，但是网络连接已经建立，这个速度也是非常非常快的，只是比数据处理阶段慢那么一点点。因此单线程方式在效率上其实并不需要担心。
IO多路复用
参考：https://www.zhihu.com/question/32163005
要弄清问题先要知道问题的出现原因
原因:
由于进程的执行过程是线性的(也就是顺序执行),当我们调用低速系统I/O(read,write,accept等等),进程可能阻塞,此时进程就阻塞在这个调用上,不能执行其他操作.阻塞很正常.
接下来考虑这么一个问题:一个服务器进程和一个客户端进程通信,服务器端read(sockfd1,bud,bufsize),此时客户端进程没有发送数据,那么read(阻塞调用)将阻塞，直到客户端调用write(sockfd,but,size)发来数据.在一个客户和服务器通信时这没什么问题；
当多个客户与服务器通信时当多个客户与服务器通信时,若服务器阻塞于其中一个客户sockfd1,当另一个客户的数据到达套接字sockfd2时,服务器不能处理,仍然阻塞在read(sockfd1,...)上;此时问题就出现了,不能及时处理另一个客户的服务,咋么办?
I/O多路复用来解决!
I/O多路复用:
继续上面的问题,有多个客户连接,sockfd1,sockfd2,sockfd3..sockfdn同时监听这n个客户,当其中有一个发来消息时就从select的阻塞中返回,然后就调用read读取收到消息的sockfd,然后又循环回select阻塞;这样就不会因为阻塞在其中一个上而不能处理另一个客户的消息
“I/O多路复用”的英文是“I/O multiplexing”,可以百度一下multiplexing，就能得到这个图：
Q:
那这样子，在读取socket1的数据时，如果其它socket有数据来，那么也要等到socket1读取完了才能继续读取其它socket的数据吧。那不是也阻塞住了吗？而且读取到的数据也要开启线程处理吧，那这和多线程IO有什么区别呢？
A:
1.CPU本来就是线性的不论什么都需要顺序处理并行只能是多核CPU
2.io多路复用本来就是用来解决对多个I/O监听时,一个I/O阻塞影响其他I/O的问题,跟多线程没关系.
3.跟多线程相比较,线程切换需要切换到内核进行线程切换,需要消耗时间和资源.而I/O多路复用不需要切换线/进程,效率相对较高,特别是对高并发的应用nginx就是用I/O多路复用,故而性能极佳.但多线程编程逻辑和处理上比I/O多路复用简单.而I/O多路复用处理起来较为复杂.
I/O 指的是网络I/O。
多路指的是多个TCP 连接（Socket 或Channel）。
复用指的是复用一个或多个线程。
它的基本原理就是不再由应用程序自己监视连接，而是由内核替应用程序监视文件描述符。
客户端在操作的时候，会产生具有不同事件类型的socket。在服务端，I/O 多路复用程序（I/O Multiplexing Module）会把消息放入队列中，然后通过文件事件分派器（Fileevent Dispatcher），转发到不同的事件处理器中。
多路复用有很多的实现，以select 为例，当用户进程调用了多路复用器，进程会被阻塞。内核会监视多路复用器负责的所有socket，当任何一个socket 的数据准备好了，多路复用器就会返回。这时候用户进程再调用read 操作，把数据从内核缓冲区拷贝到用户空间。
I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符，而这些文件描述符（套接字描述符）其中的任意一个进入读就绪（readable）状态，select()函数就可以返回。
import redis.clients.jedis.Jedis; import redis.clients.jedis.JedisPool; class Demo extends Thread { public void run() { Jedis jedis1 = new Jedis(); for (int i=0;i<100;i++){ int num = Integer.parseInt(jedis1.get("num"));// 1: 代码行1 num = num + 1; // 2: 代码行2 jedis1.set("num",num+""); System.out.println(jedis1.get("num")); } } } public class test{ public static void main(String... args){ Jedis jedis = new Jedis(); jedis.set("num","1"); new Demo().start(); new Demo().start(); } }
如代码所示，例如当线程1在代码行读取数值为99时候，此时线程2页执行读取操作也是99，随后同时执行num=num+1，之后更新，导致一次更新丢失，这就是这个代码测试的错误之处。所以Redis本身是线程安全的，但是你还需要保证你的业务必须也是线程安全的。
注意：千万不要以为原子操作是线程安全的，原子操作只能保证命令全执行或者全不执行，并不会保证线程安全操作。例如数据库中的事务就是原子的，依旧还需要提供并发控制！！！！
原子性操作是否线程安全？
原文：https://stackoverflow.com/questions/14370575/why-are-atomic-operations-considered-thread-safe
1. 原子操作是针对访问共享变量的操作而言的。涉及局部变量访问的操作无所谓是否原子的。
2. 原子操作是从该操作的执行线程以外的线程来描述的，也就是说它只有在多线程环境下才有意义。
原子操作得“不可分割”包括两层含义
1.访问（读、写）某个共享变量的操作从其执行线程以外的任何线程来看，该操作要么已经执行结束要么尚未发生，即其他线程不会“看到”该操作执行了部分的中间效果。
2.访问同一组共享变量的原子操作是不能够被交错的。
此原子性与数据库原子性有区别：最主要区别是数据库的原子性，可以被其他线程看见中间状态，否则就不会有隔离级别的事了。
redis I/O多路复用机制
为什么redis要使用I/O多路复用技术？
Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O多路复用就是为了解决这个问题而出现的。
多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉。当有一个或多个流有 I/O事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。
采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈，主要由以下几点造就了 Redis 具有很高的吞吐量。
(1) 网络IO都是通过Socket实现，Server在某一个端口持续监听，客户端通过Socket（IP+Port）与服务器建立连接（ServerSocket.accept），成功建立连接之后，就可以使用Socket中封装的InputStream和OutputStream进行IO交互了。针对每个客户端，Server都会创建一个新线程专门用于处理。
(2) 默认情况下，网络IO是阻塞模式，即服务器线程在数据到来之前处于【阻塞】状态，等到数据到达，会自动唤醒服务器线程，着手进行处理。阻塞模式下，一个线程只能处理一个流的IO事件。
(3) 为了提升服务器线程处理效率，有以下三种思路
a.非阻塞[忙轮询]:采用死循环方式轮询每一个流，如果有IO事件就处理，这样一个线程可以处理多个流，但效率不高，容易导致CPU空转。
b.Select代理(无差别轮询):可以观察多个流的IO事件，如果所有流都没有IO事件，则将线程进入阻塞状态，如果有一个或多个发生了IO事件，则唤醒线程去处理。但是会遍历所有的流，找出流需要处理的流。如果流个数为N，则时间复杂度为O(N)
c.Epoll代理：Select代理有一个缺点，线程在被唤醒后轮询所有的Stream，会存在无效操作。Epoll哪个流发生了I/O事件会通知处理线程，对流的操作都是有意义的，复杂度降低到了O(1)。
举个栗子:
每个快递员------------------>每个线程
每个快递-------------------->每个socket(I/O流)
快递的物流位置-------------->socket的不同状态
客户(寄/收)快递请求-------------->来自客户端的请求
快递公司的经营方式-------------->服务端运行的代码
一辆车---------------------->CPU的核数
1.经营方式一就是传统的并发模型，每个I/O流(快递)都有一个新的线程(快递员)管理。
2.经营方式二就是I/O多路复用。只有单个线程(一个快递员)，通过跟踪每个I/O流(快递)的状态(每个快递的送达地点)，来管理多个I/O流。
redis线程模型:
epoll IO多路复用模型实现机制
epoll没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,一般来说这个数目和系统内存关系很大,具体数目可以 cat /proc/sys/fs/file-max查看，在1GB内存的机器上大约是10万左右
场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的。
在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。
如果没有I/O事件产生，我们的程序就会阻塞在select处。有个问题，我们从select仅知道了有I/O事件发生了，但却不知是哪几个流，只能无差别轮询所有流，找出能读或写数据的流进行操作。
使用select，O(n)的无差别轮询复杂度，同时处理的流越多，每一次无差别轮询时间就越长。
epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用B+树数据结构实现)。把原先的select/poll调用分成了3个部分：
1）调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
2）调用epoll_ctl向epoll对象中添加这100万个连接的套接字
3）调用epoll_wait收集发生的事件的连接实现上面场景只需要在进程启动时建立一个epoll对象，在需要的时候向epoll对象中添加或者删除连接。同时epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。
底层实现:
当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体如下所示：
每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，通过红黑树可以高效的识别重复事件(红黑树的插入时间效率是lg(n)，其中n为树的高度)。
所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，当相应的事件发生时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。
在epoll中，对于每一个事件，都会建立一个epitem结构体，如下所示：
当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。
优势：
1. 不用重复传递。我们调用epoll_wait时就相当于以往调用select/poll，但是这时却不用传递socket句柄给内核，因为内核已经在epoll_ctl中拿到了要监控的句柄列表。
2. 在内核里，一切皆文件。epoll向内核注册了一个文件系统，用于存储上述的被监控socket。当你调用epoll_create时，就会在这个虚拟的epoll文件系统里创建一个file结点。这个file不是普通文件，它只服务于epoll。epoll在被内核初始化时（操作系统启动），同时会开辟出epoll自己的内核高速cache区，用于安置每一个我们想监控的socket，这些socket会以红黑树的形式保存在内核cache里，以支持快速的查找、插入、删除。这个内核高速cache区，就是建立连续的物理内存页，然后在之上建立slab层，简单的说，就是物理上分配好你想要的size的内存对象，每次使用时都是使用空闲的已分配好的对象。
3. 极其高效的原因：我们在调用epoll_create时，内核除了帮我们在epoll文件系统里建了个file结点，在内核cache里建了个红黑树用于存储以后epoll_ctl传来的socket外，还会再建立一个list链表，用于存储准备就绪的事件，当epoll_wait调用时，仅仅观察这个list链表里有没有数据即可。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。
这个准备就绪list链表是怎么维护的呢？当我们执行epoll_ctl时，除了把socket放到epoll文件系统里file对象对应的红黑树上之外，还会给内核中断处理程序注册一个回调函数，告诉内核，如果这个句柄的中断到了，就把它放到准备就绪list链表里。所以，当一个socket上有数据到了，内核在把网卡上的数据copy到内核中后就来把socket插入到准备就绪链表里了。epoll的基础就是回调呀！
一颗红黑树，一张准备就绪句柄链表，少量的内核cache，就帮我们解决了大并发下的socket处理问题。执行epoll_create时，创建了红黑树和就绪链表，执行epoll_ctl时，如果增加socket句柄，则检查在红黑树中是否存在，存在立即返回，不存在则添加到树干上，然后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数据。执行epoll_wait时立刻返回准备就绪链表里的数据即可。
epoll独有的两种模式LT和ET。无论是LT和ET模式，都适用于以上所说的流程。区别是，LT模式下，只要一个句柄上的事件一次没有处理完，会在以后调用epoll_wait时次次返回这个句柄，而ET模式仅在第一次返回。
LT和ET都是电子里面的术语，ET是边缘触发，LT是水平触发，一个表示只有在变化的边际触发，一个表示在某个阶段都会触发。
LT, ET这件事怎么做到的呢？当一个socket句柄上有事件时，内核会把该句柄插入上面所说的准备就绪list链表，这时我们调用epoll_wait，会把准备就绪的socket拷贝到用户态内存，然后清空准备就绪list链表，最后，epoll_wait干了件事，就是检查这些socket，如果不是ET模式（就是LT模式的句柄了），并且这些socket上确实有未处理的事件时，又把该句柄放回到刚刚清空的准备就绪链表了。所以，非ET的句柄，只要它上面还有事件，epoll_wait每次都会返回这个句柄。