【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 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。