【Redis】redis 高性能--线程模型以及epoll网络框架
目录
一.前言
二.多线程的弊端
2.1 锁的开销问题
2.2 多线程上下文切换带来的额外开销
2.3 多线程占用内存成本增高
三.基本IO模型与epoll 模式
3.1 基本IO模型
3.2 单线程处理机制
四.总结
一.前言
我们经常讨论到，redis 是单线程，那为什么单线程的性能还这么高，能够达到 10w+ QPS。
二.多线程的弊端
2.1 锁的开销问题
多线程的使用，需要我们注意共享资源的并发控制问题，控制并发问题需要我们用锁机制，加锁就会带来代码的可维护性和易调试的增大。
2.2 多线程上下文切换带来的额外开销
在单个处理器的时期，操作系统就能处理多线程并发任务。处理器给每个线程分配 CPU 时间片（Time Slice），线程在分配获得的时间片内执行任务。
CPU 时间片是 CPU 分配给每个线程执行的时间段，一般为几十毫秒。在这么短的时间内线程互相切换，我们根本感觉不到，所以看上去就好像是同时进行的一样。
时间片决定了一个线程可以连续占用处理器运行的时长。当一个线程的时间片用完了，或者因自身原因被迫暂停运行了，这个时候，另外一个线程（可以是同一个线程或者其它进程的线程）就会被操作系统选中，来占用处理器。这种一个线程被暂停剥夺使用权，另外一个线程被选中开始或者继续运行的过程就叫做上下文切换（Context Switch）。
而多线程的上下文切换频繁的话，会造成性能问题，时间开销会变大。
为了避免以上问题，redis采用了单线程模式
2.3 多线程占用内存成本增高
JVM里对象是堆里面的，但是线程是独立空间，当多线程的时候，内存空间的成本就会有所增高。
三.基本IO模型与epoll 模式
通常来说，单线程的处理能力要比多线程差很多，但是 Redis 却能使用单线程模型达到每秒数十万级别的处理能力，这是为什么呢？其实，这是 Redis 多方面设计选择的一个综合结果。主要体现在两点上
一方面，Redis 的大部分操作在内存上完成，再加上它采用了高效的数据结构，例如哈希表和跳表，这是它实现高性能的一个重要原因。
另一方面，就是 Redis 采用了多路复用机制，使其在网络 IO 操作中能并发处理大量的客户端请求，实现高吞吐率。接下来，我们就重点学习下多路复用机制。
3.1 基本IO模型
3.2 单线程处理机制
四.总结
1、大部分操作在内存完成
2、采用高效的数据结果，比如哈希表和跳表
3、采用了IO多路复用机制：使其在网络IO操作中能并发处理大量的客户端请求
注意：在redis 6.0 单线程主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外提供键值存储服务的主要流程。但 Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。