Redis为什么是单线程?高并发响应快?

为什么 redis 单线程却能支撑高并发?

  • 纯内存操作
  • 核心是基于非阻塞的 IO 多路复用机制
  • 单线程反而避免了多线程的频繁上下文切换问题

一、Redis的高并发和快速原因

1.redis是基于内存的,内存的读写速度非常快(纯内存); 数据存在内存中,数据结构用HashMap,HashMap的优势就是查找和操作的时间复杂度都是O(1)。

2.redis是单线程的,省去了很多上下文切换线程的时间(避免线程切换和竞态消耗)。

3.redis使用IO多路复用技术(IO multiplexing, 解决对多个I/O监听时,一个I/O阻塞影响其他I/O的问题),可以处理并发的连接(非阻塞IO)。

下面重点介绍单线程设计和IO多路复用核心设计快的原因。

二、为什么Redis是单线程的

2.1.官方答案

因为Redis是基于内存的操作,CPU不是Redis的瓶颈,Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现,而且CPU不会成为瓶颈,那就顺理成章地采用单线程的方案了。

2.2.性能指标

关于redis的性能,官方网站也有,普通笔记本轻松处理每秒几十万的请求。

2.3.详细原因

1)不需要各种锁的性能消耗

Redis的数据结构并不全是简单的Key-Value,还有list,hash等复杂的结构,这些结构有可能会进行很细粒度的操作,比如在很长的列表后面添加一个元素,在hash当中添加或者删除一个对象。这些操作可能就需要加非常多的锁,导致的结果是同步开销大大增加。

总之,在单线程的情况下,就不用去考虑各种锁的问题,不存在加锁、释放锁操作,没有因为可能出现死锁而导致的性能消耗。

2)单线程多进程集群方案

单线程的威力实际上非常强大,单核cpu效率也非常高,多线程自然是可以比单线程有更高的性能上限,但是在今天的计算环境中,即使是单机多线程的上限也往往不能满足需要了,需要进一步摸索的是多服务器集群化的方案,这些方案中多线程的技术照样是用不上的。

所以“单线程、多进程的集群”不失为一个时髦的解决方案。

3)CPU消耗

采用单线程,避免了不必要的上下文切换和竞争条件,也不存在多进程或者多线程导致的切换而消耗 CPU。

但是如果CPU成为Redis瓶颈,或者不想让服务器其他CUP核闲置,那怎么办?

可以考虑多起几个Redis进程,Redis是key-value数据库,不是关系数据库,数据之间没有约束。只要客户端分清哪些key放在哪个Redis进程上就可以了。

三、Redis单线程的优劣势

3.1.单进程单线程优势

代码更清晰,处理逻辑更简单。
不用去考虑各种锁的问题,不存在加锁、释放锁操作,没有因为可能出现死锁而导致的性能消耗。
不存在“多进程或者多线程导致的切换”而消耗CPU。

3.2.单进程单线程弊端

无法发挥多核CPU性能,不过可以通过在单机开多个Redis实例来完善。

四、IO多路复用技术(多路网络连接复用一个IO线程, 时分复用)

实际上所有的I/O设备都被抽象为了文件这个概念,一切皆文件,Everything isFile,磁盘、网络数据、终端,甚至进程间通信工具管道pipe等都被当做文件对待。

所有的I/O操作也都是通过文件读写来实现的,这一非常优雅的抽象可以让程序员使用一套接口就能实现所有I/O操作。

常用的I/O操作接口一般有以下几类:

打开文件,open
改变读写位置,seek
文件读写,read、write
关闭文件,close

那么,什么是IO多路复用呢?

有了文件描述符,进程对文件一无所知,比如文件在磁盘的什么位置上、内存是如何管理文件的等等,这些信息属于操作系统,进程无需关心,操作系统只需要给进程一个文件描述符就足够了。因此我们来完善上述程序:

int fd = open(file_name);
read(fd, buff);

文件描述符太多了怎么办经过了这么多的铺垫,终于到高性能、高并发这一主题了。从前几节我们知道,所有I/O操作都可以通过文件样的概念来进行,这当然包括网络通信。如果你是一个web服务器,当三次握手成功以后,我们通过调用accept同样会得到一个文件描述符,只不过这个文件描述符是用来进行网络通信的,通过读写该文件描述符你就可以同客户端通信。在这里为了概念上好理解,我们称之为链接描述符,通过这个描述符我们就可以读写客户端的数据了。

int conn_fd = accept(...);

server的处理逻辑通常是读取客户端请求数据,然后执行某些特定逻辑:

if(read(conn_fd, request_buff) > 0) {
    do_something(request_buff);
}

是不是非常简单,然而世界终归是复杂的,也不是这么简单的。接下来就是比较复杂的了。

既然我们的主题是高并发,那么server端就不可能只和一个客户端通信,而是成千上万个客户端。这时你需要处理不再是一个描述符这么简单,而是有可能要处理成千上万个描述符。为了不让问题一上来就过于复杂,我们先简单化,假设只同时处理两个客户端的请求。有的同学可能会说,这还不简单,这样写不就行了:

if(read(socket_fd1, buff) > 0) { // 处理第一个
    do_something();
}
if(read(socket_fd2, buff) > 0) {
    do_something();

这是非常典型的阻塞式I/O,如果读取第一个请求进程被阻塞而暂停运行,那么这时我们就无法处理第二个请求了,即使第二个请求的数据已经就位,这也就意味着所有其它客户端必须等待,而且通常情况下也不会只有两个客户端而是成千上万个,上万个连接也要这样串行处理吗。

聪明的你一定会想到使用多线程,为每个请求开启一个线程,这样一个线程被阻塞不会影响到其它线程了,注意,既然是高并发,那么我们要为成千上万个请求开启成千上万个线程吗,大量创建销毁线程会严重影响系统性能。那么这个问题该怎么解决呢?

不要打电话给我,有需要我会打给你

方式一:

我们主动通过I/O接口, 问内核: 这些文件描述符对应的外设是不是已经就绪了?

方式二:

一种更好的方法是,我们把这些文件描述符,一股脑扔给内核,并霸气的告诉内核:“我这里有1万个文件描述符,你替我监视着它们,有可以读写的文件描述符时你就告诉我,我好处理”。

而不是弱弱的问内核:“第一个文件描述可以读写了吗?第二个文件描述符可以读写吗?第三个文件描述符可以读写了吗?”这样应用程序就从“繁忙”的主动变为清闲的被动了,反正哪些设备ok了内核会通知我, 能偷懒我才不要那么勤奋。


你有N个不知道什么时候来水的水龙头需要接水,你根据某种信号一会儿拧这个龙头,一会儿拧那个龙头把水都接了就是多路复用(一个线程)。

所谓I/O多路复用

回到我们的主题。所谓I/O多路复用指的是这样一个过程:我们拿到了一堆文件描述符(不管是网络相关的、还是磁盘文件相关等等,任何文件描述符都可以), 通过调用某个函数告诉内核:“这个函数你先不要返回,你替我监视着这些描述符,当这堆文件描述符中有可以进行I/O读写操作的时候你再返回”。

当调用的这个函数返回后,我们就能知道哪些文件描述符可以进行I/O操作了。

那么有哪些函数可以用来进行I/O多路复用呢?在Linux世界中有这样三种机制可以用来进行I/O多路复用:

select
poll
epoll

Redis 采用网络IO多路复用技术,来保证在多连接的时候系统的高吞吐量。

多路: 指的是多个socket网络连接;
复用: 指的是复用一个线程。多路复用主要有三种技术:select,poll,epoll。epoll是最新的, 也是目前最好的多路复用技术。

采用多路I/O复用技术的好处:

其一,可以让单个线程高效处理多个连接请求(尽量减少网络IO的时间消耗)。

其二,Redis在内存中操作数据的速度非常快(内存里的操作不会成为这里的性能瓶颈)。主要以上两点造就了Redis具有很高的吞吐量。

I/O multiplexing 这里面的 multiplexing 指的其实是在单个线程通过记录跟踪每一个Sock(I/O流)的状态(对应空管塔里面的Fight progress strip槽)来同时管理多个I/O流. 发明它的原因,是尽量多的提高服务器的吞吐能力。

是不是听起来好拗口? 看个图就懂了.

在同一个线程里面, 通过拨开关的方式,来同时传输多个I/O流, (学过EE的人现在可以站出来义正严辞说这个叫“时分复用”了)。

非阻塞 IO 与 epoll ( nginx、redis 和 NIO 等核心思想 )

非阻塞 IO 内部实现采用 epoll,采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件,然后利用epoll的多路复用特性,绝不在 IO 上浪费一点时间。
详细参考:

五、Redis高并发快总结

  1. Redis是纯内存数据库,一般都是简单的存取操作,线程占用的时间很多,时间的花费主要集中在IO上,所以读取速度快。

  2. 再说一下IO,Redis使用的是非阻塞IO、IO多路复用,使用了单线程来轮询描述符,将数据库的开、关、读、写都转换成了事件,减少了线程切换时上下文的切换和竞争。

  3. Redis采用了单线程的模型,保证了每个操作的原子性,也减少了线程的上下文切换和竞争。

  4. 另外,数据结构也帮了不少忙。

Redis全程使用hash结构,读取速度快,还有一些特殊的数据结构,对数据存储进行了优化,如压缩表,对短数据进行压缩存储,再如,跳表,使用有序的数据结构加快读取的速度。

Redis 压缩表:https://baijiahao.baidu.com/s?id=1636747984492350713&wfr=spider&for=pc

  1. 还有一点,Redis采用自己实现的事件分离器,效率比较高,内部采用非阻塞的执行方式,吞吐能力比较大。

六、Redis常见性能问题和解决方案:

(1) Master最好不要做任何持久化工作,如RDB内存快照和AOF日志文件;(Master写内存快照,save命令调度rdbSave函数,会阻塞主线程的工作,当快照比较大时对性能影响是非常大的,会间断性暂停服务,所以Master最好不要写内存快照;AOF文件过大会影响Master重启的恢复速度)

(2) 如果数据比较重要,某个Slave开启AOF备份数据,策略设置为每秒同步一次

(3) 为了主从复制的速度和连接的稳定性,Master和Slave最好在同一个局域网内

(4) 尽量避免在压力很大的主库上增加从库

(5) 主从复制不要用图状结构,用单向链表结构更为稳定,即:Master <- Slave1 <- Slave2 <- Slave3...;这样的结构方便解决单点故障问题,实现Slave对Master的替换。如果Master挂了,可以立刻启用Slave1做Master,其他不变。

七、Redis的回收策略

  • volatile-lru:从已设置过期时间的数据集(server.db[i].expires)中挑选最近最少使用的数据淘汰

  • volatile-ttl:从已设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数据淘汰

  • volatile-random:从已设置过期时间的数据集(server.db[i].expires)中任意选择数据淘汰

  • allkeys-lru:从数据集(server.db[i].dict)中挑选最近最少使用的数据淘汰

  • allkeys-random:从数据集(server.db[i].dict)中任意选择数据淘汰

  • no-enviction(驱逐):禁止驱逐数据

注意这里的6种机制,

(1)volatile和allkeys规定了,是对已设置过期时间的数据集淘汰数据,还是从全部数据集淘汰数据。

(2)后面的lru、ttl以及random是三种不同的淘汰策略,再加上一种no-enviction永不回收的策略。

使用策略规则:

1、如果数据呈现幂律分布,也就是一部分数据访问频率高,一部分数据访问频率低,则使用allkeys-lru

2、如果数据呈现平等分布,也就是所有的数据访问频率都相同,则使用allkeys-random

八. 五种I/O模型介绍

IO 多路复用是5种I/O模型中的第3种,对各种模型讲个故事,描述下区别:

故事情节为:老李去买火车票,三天后买到一张退票。参演人员(老李,黄牛,售票员,快递员),往返车站耗费1小时。

1.阻塞I/O模型

老李去火车站买票,排队三天买到一张退票。

耗费:在车站吃喝拉撒睡 3天,其他事一件没干。

2.非阻塞I/O模型

老李去火车站买票,隔12小时去火车站问有没有退票,三天后买到一张票。

耗费:往返车站6次,路上6小时,其他时间做了好多事。

3.I/O复用模型

select/poll

老李去火车站买票,委托黄牛,然后每隔6小时电话黄牛询问,黄牛三天内买到票,然后老李去火车站交钱领票。

耗费:往返车站2次,路上2小时,黄牛手续费100元,打电话17次

epoll

老李去火车站买票,委托黄牛,黄牛买到后即通知老李去领,然后老李去火车站交钱领票。

耗费:往返车站2次,路上2小时,黄牛手续费100元,无需打电话。

epoll : 进程只要等待在epoll上,epoll 代替进程去各个文件描述符上等待,当哪个文件描述符可读或者可写的时候就告诉epoll,epoll用小本本认真记录下来然后唤醒大哥:“进程大哥,快醒醒,你要处理的文件描述符我都记下来了”。
这样进程被唤醒后就无需自己从头到尾检查一遍,因为epoll都已经记下来了。因此我们可以看到,在这种机制下,实际上利用的就是“不要打电话给我,有需要我会打给你”,这就不需要一遍一遍像孙子一样问各个文件描述符了,而是翻身做主人当大爷了,“你们那个文件描述符可读或者可写了主动报上来”,这中机制实际上就是大名鼎鼎的 —— 事件驱动,event-driven。(https://ssup2.github.io/theory_analysis/Event_Driven_Architecture_on_Linux/)

简单说epoll和select/poll最大区别是:
1.epoll内部使用了mmap共享了用户和内核的部分空间,避免了数据的来回拷贝
2.epoll基于事件驱动,epoll_ctl注册事件,并注册callback回调函数,epoll_wait只返回发生的事件,避免了像select和poll对事件的整个轮询操作。

nginx中使用了epoll,是基于事件驱动模型的。由一个或多个事件收集器来收集或者分发事件,epoll就属于事件驱动模型的事件收集器,将注册过的事件中发生的事件收集起来,master进程负责管理worker进程。

4.信号驱动I/O模型

老李去火车站买票,给售票员留下电话,有票后,售票员电话通知老李,然后老李去火车站交钱领票。

耗费:往返车站2次,路上2小时,免黄牛费100元,无需打电话

5.异步I/O模型

老李去火车站买票,给售票员留下电话,有票后,售票员电话通知老李并快递送票上门。

耗费:往返车站1次,路上1小时,免黄牛费100元,无需打电话。

1同2的区别是:自己轮询
2同3的区别是:委托黄牛
3同4的区别是:电话代替黄牛
4同5的区别是:电话通知是自取还是送票上门

九、事件驱动( event-driven )

Event Driven Architecture Code Demo:

int event_handler1(event *ev){
  // Non-blocking
}

int event_handler2(event *ev){
  // Non-blocking
}

int main()
{
  // Init I/O multiplexer
  IOMultiplexer multiplexer;

  // Registe event to multiplexer
  multiplexer.Add(ev1)
  multiplexer.Add(ev2)

  // Run main loop
  while(ture){
    ev_list = multiplexer.wait() // Only blocked here

    for(ev:ev_list){
      switch(ev){
        case: ev1
          event_handler1();
          break;
        case: ev2
          event_handler2();
          break;    
      }
    }
  }
}

Linux Event Driven Architecture

参考链接

https://blog.csdn.net/chinawangfei/article/details/90082576
https://blog.csdn.net/bird73/article/details/79792548
https://www.zhihu.com/question/32163005/answer/55772739
https://www.zhihu.com/question/32163005/answer/1644076216
https://www.zhihu.com/question/32163005
https://ssup2.github.io/theory_analysis/Event_Driven_Architecture_on_Linux/
https://cloud.tencent.com/developer/article/1582276

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 201,552评论 5 474
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,666评论 2 377
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 148,519评论 0 334
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,180评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,205评论 5 363
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,344评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,781评论 3 393
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,449评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,635评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,467评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,515评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,217评论 3 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,775评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,851评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,084评论 1 258
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,637评论 2 348
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,204评论 2 341

推荐阅读更多精彩内容