针对什么代码做事件驱动
什么代码值得基于事件做拆分?目标是为了高性能,服务里对资源操作速度由快到慢:CPU > 内存 > 磁盘 > 网络。由于CPU和内存都是纳秒级,故只有磁盘和网络可以考虑采用事件驱动的异步方式处理。机械硬盘最慢也就几十毫秒,属于可控,而网络速度慢波动大,既受制于连接对端性能,也受制于网络传输路径。故,一般事件驱动,都指网络事件。
多路复用
基本概念
一个进程任一时刻虽然只能处理一个请求,但如果处理单个请求产生的事件控制在1毫秒内,那么1秒就可以处理上千个请求。从更长的时间维度看,多个请求复用了一个进程,就叫多路复用(时分多路复用)。
Linux内核多路复用接口
select接口/poll接口/epoll接口
select接口
获取事件时,将所有并发连接传给内核,再由内核返回产生了事件的连接,最后处理这些连接对应的请求。
epoll接口
像select这样,会有频繁的用户态到内核态数据拷贝到消耗。C10M 意味着有一千万个连接,若每个 socket 是 4 字节(unsigned int),那么 1 千万连接就是 40M 字节。这样,每收集一次事件,就需要从用户态复制 40M 字节到内核态。而且,高性能 Server 必须及时地处理网络事件,所以每隔几十毫秒就要收集一次事件,性能消耗巨大。
epoll为了降低性能消耗,把获取事件拆分成了两步。
- 把需要监控的socket传给内核(epoll_ctl函数),仅在连接建立等有限的时机调用传递;
- 由于内核已管理了socket,故收集事件不再需要传递socket。
这样便只有一次socket复制。
获取到了产生事件的socket后,如何处理?
处理事件的代码分为三类来看。
-
计算任务,虽然内存、CPU 的速度很快,然而循环执行也可能耗时达到秒级。所以,如果一定要引入需要密集计算才能完成的请求,为了不阻碍其他事件的处理,要么把这样的请求放在独立的线程中完成,要么把请求的处理过程拆分成多段,确保每段能够快速执行完,同时每段执行完都要均等地处理其他事件,这样通过放慢该请求的处理时间,就保障了其他请求的及时处理。
-
读写磁盘,由于磁盘的写入操作使用了 PageCache 的延迟写特性,当 write 函数返回时只是复制到了内存中,所以写入操作很快。磁盘的读取操作就比较慢了,这时,通常要把大文件的读取,拆分成许多份,每份仅有几十 KB,降低单次操作的耗时。
-
通过网络访问上游服务。与处理客户端请求相似,我们必须使用非阻塞 socket,用事件驱动方式处理请求。需要注意的是,许多网络服务提供的 SDK,都是基于阻塞 socket 实现的,使用前必须先做完非阻塞改造。比如 Memcached 的官方 SDK 是用阻塞 socket 实现的,Nginx 如果直接使用该 SDK 访问它,性能就会一落千丈。正确的访问方式,是使用第三方提供的ngx_http_memcached_module 模块,它用非阻塞 socket 重新封装了 SDK。
总之,网络报文到达后,内核就产生了读、写事件,而 epoll 函数使得进程可以高效地收集到这些事件。接下来,要确保在进程中处理每个事件的时间足够短,才能及时地处理所有请求,这个过程中既要避免阻塞 socket 的使用,也要把耗时过长的操作拆成多份执行。最终,通过快速、及时、均等地执行所有事件,异步 Server 实现了高并发。
标签:请求,认识,事件驱动,处理,内核,事件,socket From: https://www.cnblogs.com/kiper/p/17169664.html