1.Redis是单线程的还是多线程的？
2.Redis性能很快的原因
3.Redis的瓶颈在哪里
4.I/O多路复用模型理论
5.I/O多路复用模型JAVA验证
6.Redis如何处理并发客户端链接
7.Linux内核函数select, poll, epoll解析
8.总结
1.Redis是单线程的还是多线程的？
当我们在学习和使用redis的时候，大家口耳相传的，说的都是redis是单线程的。其实这种说法并不严谨，Redis的版本有非常多，3.x、4.x、6.x，版本不同架构也是不同的，不限定版本问是否单线程不太严谨。
1）版本3.x，最早版本，也就是大家口口相传的redis是单线程。
2）版本4.x，严格意义上来说也不是单线程，而是负责客户端处理请求的线程是单线程，但是开始加了点多线程的东西（异步删除）
3）最新版本的6.0.x后，告别了刻板印象中的单线程，而采用了一种全新的多线程来解决问题。
所以我们可以得出，Redis 6.0版本以后，对于整个redis来说，是多线程的。
Redis是单线程到多线程的演变：
在以前，Redis的网络IO和键值对的读写都是由一个线程来完成的，Redis的请求时包括获取（Socket读），解析，执行，内容返回（socket写）等都是由一个顺序串行的主线程处理，这就是所谓的单线程。
但此时，Redis的瓶颈就出现了：
I/O的读写本身是阻塞的，比如当socket中有数据的时候，Redis会通过调用先将数据从内核态空间拷贝到用户态空间，再交给Redis调用，而这个拷贝的过程就是阻塞的，当数据量越大时拷贝所需要的时间就越多，而这些操作都是基于单线程完成的。
在Redis6.0中新增加了多线程的功能来提高I/O读写性能，他的主要实现思路是将主线程的IO读写任务拆分给一组独立的线程去执行，这样就可以使多个socket的读写并行化了，采用I/O多路复用技术可以让单个线程高效处理多个连接请求（尽量减少网络IO的时间消耗），将最耗时的socket读取，请求解析，写入单独外包出去，剩下的命令执行任然是由主线程串行执行和内存的数据交互。
结合上图可知，网络IO操作就变成多线程化了，其他核心部分仍然是线程安全的，是个不错的折中办法。
流程图：
流程简述：
1）主线程负责接收建立链接请求，获取socket放入全局等待读取队列
2）主线程处理完读事件后，将这些连接分配给这些IO线程
3）主线程阻塞等待IO线程读取socket完毕
4）IO线程组收集各个socket输入进来的命令，收集完毕
5）主线解除阻塞，程执行命令，执行完毕后输出结果数据
6）主线程阻塞等待 IO 线程将数据回写 socket 完毕
7）解除绑定，清空等待队列
2.Redis性能很快的原因
1）基于内存操作，Redis的所有数据都存在内存中，因此所有的运算都是内存级别的，所以他的性能比较高。
2）数据结构简单：Redis的数据结构都是专门设计的，而这些简单的数据结构的查找和操作的时间大部分复杂度都是O（1），因此性能比较强，可以参考我之前写过的这篇文章。深入理解redis——redis经典五种数据类型及底层实现
3）多路复用和非阻塞I/O，Redis使用I/O多路复用来监听多个socket链接客户端，这样就可以使用一个线程链接来处理多个请求，减少线程切换带来的开销，同时也避免了I/O阻塞操作。
4）主线程为单线程，避免上下文切换，因为是单线程模型，因此避免了不必要的上下文切换和多线程竞争（比如锁），这就省去了多线程切换带来的时间和性能上的消耗，而且单线程不会导致死锁问题的发生。
3.Redis的瓶颈在哪里？
说了这么多redis的优点，redis的性能瓶颈到底在哪里？
从cpu上看：
1）redis是基于内存的，因此减少了cpu将数据从磁盘复制到内存的时间
2）redis是单线程的，因此减少了多线程切换和恢复上下文的时间
3）redis是单线程的，因此多核cpu和单核cpu对于redis来说没有太大影响，单个线程的执行使用一个cpu即可
综上所述，redis并没有太多受到cpu的限制，所以cpu大概率不会成为redis的瓶颈。
而内存大小和网络IO才有可能是redis的瓶颈。
内存大小我们很好理解，那么为什么说网络IO是Redis的瓶颈呢？
瓶颈一：网络带宽瓶颈
在Redis中，命令的请求和数据的响应都是通过网络带宽传输的，而每个请求和响应都是一个二进制数据包，所以要传输的数量还是比较大的。如果请求和响应大到一定程度，就会一定程度造成请求和响应的阻塞。
瓶颈二：连接瓶颈
在Redis中，所有客户端都是通过socket连接到服务器的，而每个连接都需要一个线程处理。在早起的Redis版本中，当有大量连接的时候，服务器可能就会因为繁忙而出现请求暂停，因为处理连接的线程可能会被全部耗尽。
所以Redis使用了I/O多路复用模型，来优化redis。
4.I/O多路复用模型理论
在学习IO多路复用之前，我们先明白下面的几个词语的概念：
1）同步：调用者要一直等待调用结果的通知后，才能继续执行，类似于串行执行程序，执行完毕后返回。
2）异步：指被调用者先返回应答让调用者先回去，然后计算调用结果，计算完成后，再以回调的方式通知给调用方。
同步，异步的侧重点，在于被调用者，重点在于获得调用结果的通知方式上。
3）阻塞：调用方一直在等，且其它别的事情都不做，当前线程会被挂起，啥都不干
4）非阻塞：调用在发出去之后，调用方先去干别的事情，不会阻塞当前线程，而会立刻返回。
阻塞，非阻塞的侧重点，在于调用者在等待消息的时候的行为，调用者能否干其它的事。
以上的IO可以组合成4种组合方式：同步阻塞，同步非阻塞，异步阻塞，异步非阻塞
同时也就衍生出了unix网络编程中的五种模型：
接下来我们用代码进行验证
5.I/O多路复用模型JAVA验证
BIO(阻塞IO)：
我们来看这样一段代码：
假设我们现在有一个服务器，监听6379端口，让别人来链接，我们用这样的方式来写代码：
public class RedisServer
{
public static void main(String[] args) throws IOException
{
byte[] bytes = new byte[1024];
//监听6379端口
ServerSocket serverSocket = new ServerSocket(6379);
while(true)
{
System.out.println("模拟RedisServer启动-----111 等待连接");
Socket socket = serverSocket.accept();
System.out.println("-----222 成功连接");
System.out.println();
}
}
}客户端：
public class RedisClient01
{
public static void main(String[] args) throws IOException
{
System.out.println("------RedisClient01 start");
Socket socket = new Socket("127.0.0.1", 6379);
}
}上面这个模型存在很大的问题，如果客户端与服务端建立了链接，如果上面这个链接的客户端迟迟不发数据，线程就会一直阻塞在read()方法上，这样其它客户端也不能进行链接，也就是一个服务器只能处理一个客户端，对客户很不友好，我们需要升级：
利用多线程：
只要连接了一个socket，操作系统就会分配一个线程来处理，这样read()方法堵在每个具体线程上而不阻塞主线程。
public class RedisServerBIOMultiThread
{
public static void main(String[] args) throws IOException
{
ServerSocket serverSocket = new ServerSocket(6379);
while(true)
{
Socket socket = serverSocket.accept();//阻塞1 ,等待客户端连接
//每次都开一个线程
new Thread(() -> {
try {
InputStream inputStream = socket.getInputStream();
int length = -1;
byte[] bytes = new byte[1024];
System.out.println("-----333 等待读取");
while((length = inputStream.read(bytes)) != -1)//阻塞2 ,等待客户端发送数据
{
System.out.println("-----444 成功读取"+new String(bytes,0,length));
System.out.println("====================");
System.out.println();
}
inputStream.close();
socket.close();
} catch (IOException e) {
e.printStackTrace();
}
},Thread.currentThread().getName()).start();
System.out.println(Thread.currentThread().getName());
}
}
}存在的问题：
每来一个客户端，就要开辟一个线程，在操作系统中用户态不能直接开辟线程，需要调用内核来创建一个线程，其中还涉及到用户态的切换（上下文的切换），十分消耗资源。
解决办法：
1）使用线程池，在链接少的情况下可以使用，但是在用户量大的情况下，你不知道线程池要多大，太大了内存可能不够，也不可行。
2）NIO方式，这就引出了我们的NIO
NIO(非阻塞IO):
在NIO模式中，一切都是非阻塞的：
accept()方法是非阻塞的，如果没有客户端连接，就返回error
read()方法是非阻塞的，如果read()方法读取不到数据就返回error，如果读取到数据时只阻塞read()方法读数据的时间
在NIO模式中，只有一个进程：
当一个客户端与服务器进行链接，这个socket就会加入到一个数组中，隔一段时间遍历一次，这样一个线程就能处理多个客户端的链接和数据了。
public class RedisServerNIO
{
//将所有socket加入到这个数组中
static ArrayList socketList = new ArrayList<>();
static ByteBuffer byteBuffer = ByteBuffer.allocate(1024);
public static void main(String[] args) throws IOException
{
System.out.println("---------RedisServerNIO 启动等待中......");
ServerSocketChannel serverSocket = ServerSocketChannel.open();
serverSocket.bind(new InetSocketAddress("127.0.0.1",6379));
serverSocket.configureBlocking(false);//设置为非阻塞模式
while (true)
{
//遍历所有数组
for (SocketChannel element : socketList)
{
int read = element.read(byteBuffer);
if(read > 0)
{
System.out.println("-----读取数据: "+read);
byteBuffer.flip();
byte[] bytes = new byte[read];
byteBuffer.get(bytes);
System.out.println(new String(bytes));
byteBuffer.clear();
}
}
SocketChannel socketChannel = serverSocket.accept();
if(socketChannel != null)
{
System.out.println("-----成功连接: ");
socketChannel.configureBlocking(false);//设置为非阻塞模式
socketList.add(socketChannel);
System.out.println("-----socketList size: "+socketList.size());
}
}
}
}
NIO成功解决了BIO需要开启多线程的问题，NIO中一个线程就能解决多个socket，但还是存在两个问题：
问题一：对cpu不友好
如果客户端非常多的话，每次遍历都要非常多的socket，很多都是无效遍历。
问题二：线程上下文切换
这个遍历是在用户态进行的，用户态判断socket是否有数据还是调用内核的read()方法实现的，这就会涉及到用户态和内核态的切换，每遍历一个就要切换一次，开销非常大。
优点：不会阻塞在内核的等待数据过程，每次发起的IO请求可以立刻返回，不用阻塞等待，实时性好。
缺点：会不断询问内核，占用大量cpu时间，资源利用率低。
改进：让linux内核搞定上述需求，我们将一批文件描述符通过一次系统调用传给内核，由内核层去遍历，才能真正解决这个问题，IO多路复用应运而生，就是将上述工作直接放进Linux内核，不再两态转换。
6.Redis如何处理并发客户端链接
我们先来看看redis是如何处理这么多客户端连接的：
Redis利用linux内核函数（下文会讲解）来实现IO多路复用，将连接信息和事件放到队列中，队列再放到事件派发器，事件派发器把事件分给事件处理器。
因为Redis主线程是跑在单线程里面的，所有操作都得按顺序执行，但是由于读写操作等待用户的数据输出都是阻塞的，IO在一般的情况下不能直接返回，这回导致某一文件的IO阻塞导致整个进程无法对其它客户端提供服务，而IO多路复用就是解决这个问题的。
所谓的I/O多路复用，就是通过一种机制，让一个线程可以监视多个链接描述符，一旦某个描述符就绪（一般都是读就绪或者写就绪），就能够通知程序进行相应的读写操作。这种机制的使用需要select 、 poll 、 epoll 来配合。多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。
它的概念是：多个Socket链接复用一根网线，这个功能是在内核+驱动层实现的。
IO多路复用，也叫I/O multiplexing， 这里面的 multiplexing指的其实是在单个线程通过记录跟踪每一个sock（I/O流）的状态来同时管理多个IO流，目的是尽量多的提高服务器的吞吐能力。
7.Linux内核函数select, poll, epoll解析
select, poll, epoll 都是I/O多路复用的具体的实现。
select方法：
Linux官网源码：
select函数监视的文件描述符分3类，分别是readfds、writefds和exceptfds，将用户传入的数组拷贝到内核空间，调用select函数后会进行阻塞，直到有描述符就绪（有数据 可读，可写或者有except）或者超时（timeout指定等待时间，如果立即返回设为null即可），函数返回。
当select函数返回后，可以通过遍历fdset，来找到就绪的描述符。
从代码中可以看出，select系统调用后，返回了一个位置后的&ret，这样用户态只需要很简单地进行二进制比较，就能很快知道哪些socket需要read数据，有效提高了效率。
优点：
select其实就是把NIO中用户态要遍历的fd数组（我们的每一个socket链接，安装进ArrayList里面的那个）拷贝到了内核态，让内核态来遍历，因为用户态判断socket是否有数据还是要调用内核态的，所有拷贝到内核态后，这样遍历判断的时候就不用一直用用户态和内核态频繁切换了。
缺点：
1）bitmap最大1024位，一个进程最多只能处理1024个客户端
2）&rset不可重用，每次socket有数据就相应的位会被置位
3）文件描述符数组拷贝到了内核态，任然有开销。select调用需要传入fd数组，需要拷贝一份到内核，高并发场景下这样的拷贝消耗资源是惊人的。（可优化为不复制）
4）select并没有通知用户态哪一个socket用户有数据，仍需要O（n）的遍历。select仅仅返回可读文件描述符的个数，具体哪个可读还是要用户自己遍历。（可优化为只返回给用户就绪的文件描述符，无需用户做无效的遍历）
我们自己模拟写的是，RedisServerNIO.java,只不过将它内核化了。
poll方法：
看一下linux内核源码
优点：
1）poll使用pollfd数组来代替select中的bitmap，数组中没有1024的限制，去掉了select只能监听1024个文件描述符的限制。
2）当pollfds数组中有事件发生，相应revents置置为1，遍历的时候又置位回零，实现了pollfd数组的重用
缺点：
1、pollfds数组拷贝到了内核态，仍然有开销
2、poll并没有通知用户态哪一个socket有数据，仍然需要O(n)的遍历
epoll方法：
epoll操作过程需要三个接口：
epoll_create：创建一个 epoll 句柄
epoll_ctl：向内核添加、修改或删除要监控的文件描述符
epoll_wait：类似发起了select() 调用
epoll 是只轮询那些真正发出了事件的流，并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。 采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈
为什么redis一定要部署在Linux机器上才能发挥出该性能？
因为只有linux有epoll函数，其它系统会自动降级成select函数。
三个方法对比：
| select | poll | epoll | |
|---|---|---|---|
| 操作方式 | 遍历 | 遍历 | 回调 |
| 数据结构 | bitmap | 数组 | 红黑树 |
| 最大连接数 | 1024（x86）或者2048（x64） | 无上限 | 无上限 |
| 最大支持文件描述符数 | 有最大值限制 | 65535 | 65535 |
| fd拷贝 | 每次调用，都需要把fd结合从用户态拷贝到内核态 | 每次调用，都需要把fd结合从用户态拷贝到内核态 | 只有首次调用的时候拷贝 |
| 工作效率 | 每次都要遍历所有文件描述符，时间复杂度O（n） | 每次都要遍历所有文件描述符，时间复杂度O（n） | 每次只用遍历需要遍历的文件描述符，时间复杂度O（1） |
8.总结
Redis快的一部分原因在于多路复用，多路复用快的原因是系统提供了这样的调用，使得原来的while循环里的多次系统调用变成了，一次系统调用+内核层遍历这些文件描述符。
