Redis多路复用在不同操作系统的性能

Redis多路复用

在redis中在不同系统中会使用不同的模型,但是多路复用的原理还是一个进程或者线程可以同时处理多个连接,不需要为每个连接都创建一个单独的线程或者进程。不同的多路复用机制在具体实现有一些差异,但是核心思想还是单个进程或进程处理多个事件。

在单线城的并发性是指: 一个线程轮询获取新的事件进行处理。

多路复用的工作原理

Epool模型 Linux下默认的模型

Epool的工作原理就是使用三个系统调用epoll_create、pool_ctl和epool_wait。它通过注册时间和就绪事件轮询方式,通知程序发生的事件。

状态变化表(读和写事件)示某个文件描述符(文件、websocks)关联的 I/O 资源发生了可读、可写或其他事件

​ **epoll_create:**创建一个epool实列,然后一个文件描述符,该描述符用于标识epoll实列。

​ **epoll_ctl:**用于向epoll实列中添加、修改或删除需要监视的文件描述符。

​ **epoll_wait:**用于等待文件描述符上的事件发生。

数据结构设计

数据结构设计: epoll使用红黑树存储文件描述符,这使得在变动添加和删除文件描述的时候时间复杂度为O(0),这和kqueue的数据结构使用链表或者数据相比,更为高效。

触发模式: Epool的触发模式有2种。水平触发和边缘触发

​ **水平触发:**只要文件描述符的状态有变化,就会通知应用程序 (默认)

水平触发的优点: 使用场景处理持续性IO事件。

边缘触发: 仅在状态变化的时候发送通知 ,需要应用程序处理所有未处理的事件(只会发一次)。

​ **边缘通知的优点:**避免重复发送通知造成的性能浪费,适用于更加精细的控制和处理场景。

​ 这种设计可以使得我们epool支持不同的场景。

​ **支持的文件描述数量:**epool在设计上更适用于大规模并发连接,因为他能处理万计的文件描述符,随着连接的数量增加,性能也不会线性下降,相比之下,kqueue会出现这个情况。

​ **效率和性能:**epool的实现内核采用了一些优化策略,入采用基于事件的回调机制,能够加高效率处理并发连接,这在高并发环境下,epoll的性能更好。

在Redis中默认是使用水平触发的,如果我们想要修改为bian’yuan可以在redis配置文件进行修改,

Redis6.0版本 使用 I\O Completion Ports 在Windows

I\OCP提供了一种高效的异步I\O机制,特别适合处理并发连接的场景。I\OCP是widows提供的一种异步I\O完成通知机制,它允许IO在完成的时候发送通知,而不需要程序不断地询问文件描述符的状态。

在使用IOCP的时候首先会创建一个完成端口对象,然后再将我们的套接字(比如我们的连接操符)或者文件句柄(就是我们要操作的文件)绑定在这个完成端口对象上,然后提交我们的异步IO上,然后就是等待我们的完成包,当我们的完成包处理完会通知我们我们IOCP,这个完成包包含了操作类型、操作结果和我们的套接字或文件句柄,然后我们IOCP拿到这个完成包会根据不同的操作类型进行响应,比如读就会得到读的结果。

因为在我们收到完成包的时候会通知我们IOCP,然后对我们的IO结果进行处理,也就是说当我们收到事件就异步。然后等通知从而实现。

也就是说如果需要网络通信那么我们先创建一个接口完成对象,然后我们套接字和我们的接口完成对象绑定,然后异步io。如果不需要进行网络通信操作那么就在创建一个接口完成对象,然后在和一个文件句柄关联进行操作,然后进行异步操作。

  • 6
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

哇塞大嘴好帅(DaZuiZui)

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值