CPU 密集型:这种系统就说明 CPU 的利用率很高,那么使用多线程反而会增加上下文切换而带来额外的开销,所以使用多线程效率可能会不升反降。举个例子:假如你现在在干活,你一直不停的在做一件事,需要 1 分钟可以做完,但是你中途总是被人打断,需要花 1 秒钟时间步行到旁边去做另一件事,假如这件事也需要 1 分钟,那么你因为反复切换做两件事,每切换一次就要花 1 秒钟,最后做完这 2 件事的时间肯定大于 2 分钟(取决于中途切换的次数),但是如果中途不被打断,你做完一件事再去做另一件事,那么你最多只需要切换 1 次,也就是 2 分 1 秒就能做完。
IO 密集型:IO 操作也可以分为磁盘 IO 和网络 IO 等操作。大部分 IO 操作的特点是比较耗时且 CPU 利用率不高,所以 Redis 6.0 版本网络 IO 会改进为多线程。至于磁盘 IO,因为 Redis 中的数据都存储在内存(也可以持久化),所以并不会过多的涉及到磁盘操作。举个例子:假如你现在给树苗浇水,你每浇完一次水之后就需要等别人给你加水之后你才能继续浇,那么假如这个等待过程需要 5 秒钟,也就是说你浇完一次水就可以休息 5 秒钟,而你切换去做另一件事来回只需要 2 秒,那么你完全可以先去做另一件事,做完之后再回来,这样就可以充分利用你空闲的 5 秒钟时间,从而提升了效率。
使用多线程还会带来一个问题就是数据的安全性,所以多线程编程都会涉及到锁竞争,由此也会带来额外的开销。
什么是 I/O 多路复用I/O 指的是网络 I/O, 多路指的是多个 TCP 连接(如 Socket),复用指的是复用一个或多个线程。I/O 多路复用的核心原理就是不再由应用程序自己来监听连接,而是由服务器内核替应用程序监听。
在 Redis 中,其多路复用有多种实现,如:select,epoll,evport,kqueue 等。
我们用去餐厅吃饭为的例子来解释一下 I/O 多路复用机制(点餐人相当于客户端,餐厅的厨房相当于服务器,厨师就是线程)。
阻塞 IO:张三去餐厅吃饭,点了一道菜,这时候他啥事也不干了,就是一直等,等到厨师炒好菜,他就把菜端走开始吃饭了。也就是在菜被炒好之前,张三被阻塞了,这就是 BIO(阻塞 IO),效率会非常低下。
非阻塞 IO:张三去餐厅吃饭,点了一道菜,这时候张三他不会一直等,找了个位置坐下,刷刷抖音,打打电话,做点其他事,然后每隔一段时间就去厨房问一下自己的菜好了没有。这种就属于非阻塞 IO,这种方式虽然可以提高性能,但是如果有大量 IO 都来定期轮询,也会给服务器造成非常大的负担。
事件驱动机制:张三去餐厅吃饭,点了一道菜,这时候他找了个位置坐下来等:
厨房那边菜做好了就会把菜端出来了,但是并不知道这道菜是谁的,于是就挨个询问顾客,这就是多路复用中的 select 模型,不过 select 模型最多只能监听 1024 个 socket(poll 模型解决了这个限制问题)。
厨房做好了菜直接把菜放在窗口上,大喊一声,某某菜做好了,是谁的快过来拿,这时候听到通知的人就会自己去拿,这就是多路复用中的 epoll 模型。
需要注意的是在 IO 多路复用机制下,客户端可以阻塞也可以选择不阻塞(大部分场景下是阻塞 IO),这个要具体情况具体分析,但是在多路复用机制下,服务端就可以通过多线程(上面示例中可以多几个厨师同时炒菜)来提升并发效率。
Redis 中 I/O 多路复用的应用Redis 服务器是一个事件驱动程序,服务器需要处理两类事件:文件事件和时间事件。
文件事件:Redis 服务器和客户端(或其他服务器)进行通信会产生相应的文件事件,然后服务器通过监听并处理这些事件来完成一系列的通信操作。
时间事件:Redis 内部的一些在给定时间之内需要进行的操作。
Redis 的文件事件处理器以单线程的方式运行,其内部使用了 I/O 多路复用程序来同时监听多个套接字(Socket)连接,提升了性能的同时又保持了内部单线程设计的简单性。下图就是文件事件处理器的示意图: