Redis--为什么这么快?

Redis作为一个基于key-value的NoSQL数据库,最显著的特点存取速度非常快,官方说可以达到10W OPS,但是Redis为何这么快?

1、开发语言

Redis使用C语言进行编写的,而Unix系统也是C语言实现,所以C语言是非常贴近操作系统的语言

2、基于内存读写

基于内存读写是Redis速度快的主要原因,不进行数据同步的情况下,不从磁盘读取数据,没有IO。内存响应时间大约100ns

3、单线程

  1).单线程避免了线程上下文切换以及同步加锁、解锁带来的消耗。

  2).单线程简化算法的实现

  3).单线程也带来一个问题,阻塞,对于一个长命令来说,会阻塞很多命令的执行响应

这里的单线程,不包含fork()产生的子进程。除了Redis之外,Node.js、Nginx都是单线程,都属于高性能的组件框架

4、多路I/O复用模型

  由于Redis是单线程的,所有的操作都是串行执行,但是由于读写操作等待用户输入或输出都是阻塞的,所以 I/O 操作在一般情况下往往不能直接返回,

这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务,而 I/O 多路复用就是为了解决这个问题而出现的。

Redis的I/O模型基于epoll实现,也提供select和kqueue的实现,默认epoll

扫描二维码关注公众号,回复: 6261988 查看本文章

epoll相对于其他多路复用技术,具有的优点:

  1. epoll没有最大并发连接的限制,上限是最大可以打开文件的数目,这个数字一般远大于 2048

  2. 效率提升,epoll最大的优点就在于它只管你“活跃”的连接,而跟连接总数无关,因此在实际的网络环境中, epoll的效率就会远远高于select和poll

  3. 内存拷贝,epoll在这点上使用了“共享内存 ”,这个内存拷贝也省略了。

epoll与select/poll的区别:select,poll,epoll都是IO多路复用的机制。

I/O多路复用:

  通过一种机制,可以监视多个描述符(File Descriptor,简称fd),一旦某个描述符就绪,能够通知程序进行相应的操作。

select:

  本质是采用32个整数的32位,即32*32= 1024来标识,fd值为1-1024。当fd的值超过1024限制时,就必须修改FD_SETSIZE的大小。这个时候就可以标识32*max值范围的fd。

poll:

  poll与select不同,通过一个pollfd数组向内核传递需要关注的事件,故没有描述符个数的限制,pollfd中的events字段和revents分别用于标示关注的事件和发生的事件,

故pollfd数组只需要被初始化一次。

  epoll还是poll的一种优化,返回后不需要对所有的fd进行遍历,在内核中维持了fd的列表。select和poll是将这个内核列表维持在用户态,然后传递到内核中。

与poll/select不同,epoll不再是一个单独的系统调用,而是由epoll_create/epoll_ctl/epoll_wait三个系统调用组成,后面将会看到这样做的好处。epoll在2.6以后的内核才支持。

select/poll的几大缺点:

  1、每次调用select/poll,都需要把fd集合从用户态拷贝到内核态,这个开销在fd很多时会很大

  2、同时每次调用select/poll都需要在内核遍历传递进来的所有fd,这个开销在fd很多时也很大

  3、针对select支持的文件描述符数量太小了,默认是1024

  4.select返回的是含有整个句柄的数组,应用程序需要遍历整个数组才能发现哪些句柄发生了事件;

  5.select的触发方式是水平触发,应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作,那么之后每次select调用还是会将这些文件描述符通知进程。

相比select模型,poll使用链表保存文件描述符,因此没有了监视文件数量的限制,但其他三个缺点依然存在。

epoll IO多路复用模型实现机制:

  由于epoll的实现机制与select/poll机制完全不同,上面所说的 select的缺点在epoll上不复存在。

  epoll没有这个限制,它所支持的FD上限是最大可以打开文件的数目,这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右

  设想一下如下场景:有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻,通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发?

  在select/poll时代,服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态),让操作系统内核去查询这些套接字上是否有事件发生,

  轮询完后,再将句柄数据复制到用户态,让服务器应用程序轮询处理已发生的网络事件,这一过程资源消耗较大,因此,select/poll一般只能处理几千的并发连接。

  如果没有I/O事件产生,我们的程序就会阻塞在select处。但是依然有个问题,我们从select那里仅仅知道了,有I/O事件发生了,但却并不知道是那几个流(可能有一个,多个,甚至全部),

  我们只能无差别轮询所有流,找出能读出数据,或者写入数据的流,对他们进行操作。

  但是使用select,我们有O(n)的无差别轮询复杂度,同时处理的流越多,每一次无差别轮询时间就越长

epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现?B+树)。把原先的select/poll调用分成了3个部分:

  1)调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)

  2)调用epoll_ctl向epoll对象中添加这100万个连接的套接字

  3)调用epoll_wait收集发生的事件的连接

  如此一来,要实现上面说是的场景,只需要在进程启动时建立一个epoll对象,然后在需要的时候向这个epoll对象中添加或者删除连接。同时,epoll_wait的效率也非常高,

因为调用epoll_wait时,并没有一股脑的向操作系统复制这100万个连接的句柄数据,内核也不需要去遍历全部的连接。

epoll内容原文地址:https://blog.csdn.net/wxy941011/article/details/80274233

猜你喜欢

转载自www.cnblogs.com/huigelaile/p/10900652.html