关于事件通知机制的信息

本篇文章给大家谈谈事件通知机制，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享事件通知机制的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、epoll使用详解
• 2、25 NotificationListenerService通知机制
• 3、vue 跨页面通信怎么弄
• 4、【深入解析MAX OSX & iOS操作系统】读书笔记 —— OS X 和 iOS 使用的技术
• 5、面试官：请问Nginx为什么比Apache性能好
• 6、事件性通知怎么保证可靠通信

epoll使用详解

进程级的描述符表的每一条目记录了单个文件描述符的相关信息。
1. 控制文件描述符操作的一组标志。（目前，此类标志仅定义了一个，即close-on-exec标志）
2. 对打开文件句柄的引用

内核对所有打开的文件的文件维护有一个系统级的描述符表格（open file description table）。有时，也称之为打开文件表（open file table），并将表格中各条目称为打开文件句柄（open file handle）。一个打开文件句柄存储了与一个打开文件相关的全部信息，如下所示：
1. 当前文件偏移量（调用read()和write()时更新，或使用lseek()直接修改）
2. 打开文件时所使用的状态标识（即，open()的flags参数）
3. 文件访问模式（如调用open()时所设置的只读模式、只写模式或读写模式）
4. 与信号驱动相关的设置
5. 对该文件i-node对象的引用
6. 文件类型（例如：常规文件、套接字或FIFO）和访问权限
7. 一个指针，指向该文件所持有的锁列表
8. 文件的各种属性，包括文件大小以及与不同类型操作相关的时间戳

下图展示了文件描述符、打开的文件句柄以及i-node之间的关系，图中，两个进程拥有诸多打开的文件描述符。

Epoll - I/O event notification facility
翻译一下，epoll是一种I/O事件通知机制，这句话基本上包含了所有需要理解的要点：

epoll是一种当文件描述符的内核缓冲区非空的时候，发出可读信号进行通知，当写缓冲区不满的时候，发出可写信号通知的机制

epoll的接口非常简单，一共就三个函数：

events可以是以下几个宏的集合：
EPOLLIN ：表示对应的文件描述符可以读（包括对端SOCKET正常关闭）；
EPOLLOUT：表示对应的文件描述符可以写；
EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
EPOLLERR：表示对应的文件描述符发生错误；
EPOLLHUP：表示对应的文件描述符被挂断；
EPOLLET： 将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里

首先通过 create_epoll(int maxfds) 来创建一个epoll的句柄，其中 maxfds 为你epoll所支持的最大句柄数。这个函数会返回一个新的epoll句柄，之后的所有操作将通过这个句柄来进行操作。在用完之后，记得用 close() 来关闭这个创建出来的epoll句柄。

之后在你的网络主循环里面，每一帧的调用 epoll_wait(int epfd, epoll_event events, int max events, int timeout) 来查询所有的网络接口，看哪一个可以读，哪一个可以写了。基本的语法为：
nfds = epoll_wait(kdpfd, events, maxevents, -1);
其中kdpfd为用 epoll_create 创建之后的句柄，events是一个 epoll_event* 的指针，当 epoll_wait 这个函数操作成功之后， epoll_events 里面将储存所有的读写事件。 max_events 是当前需要监听的所有 socket 句柄数。 最后一个 timeout 是 epoll_wait 的超时，为0的时候表示马上返回，为-1的时候表示一直等下去，直到有事件范围，为任意正整数的时候表示等这么长的时间，如果一直没有事件，则范围。 一般如果网络主循环是单独的线程的话，可以用-1来等，这样可以保证一些效率，如果是和主逻辑在同一个线程的话，则可以用0来保证主循环的效率。

epoll_wait范围之后应该是一个循环，遍利所有的事件。

几乎所有的epoll程序都使用下面的框架：

下面给出一个完整的服务器端例子：

25 NotificationListenerService通知机制

Android应用除了组件和窗口管理事件通知机制，还有通知显示也是非常重要事件通知机制的，通知是应用界面之外向用户显示的界面。 NotificationListenerService继承于Service，该服务是为了给app提供获取通知的新增和删除事件，通知的数量和内容等相关信息的途径，该类的主要方法：

常见的Flags:

关于前台服务是用户可感知的，前台服务需要显示一个通知，比如后台播放音乐。

创建通知过程，此处的PendingIntent是当通知被点击后的跳转动作，可以是启动Activity、Service，或者发送Broadcast。 对于更新通知只需要发送notifyID相同的通知即可。

除了调用NotificationManager的cancel()或者cancelAll()，也可

点击查看大图

点击查看大图

可见，通知发送与通知取消流程的步骤一直对齐，这里就只介绍通知发送流程，通知取消流程就不再介绍。

[- NotificationManager.java]

在App端调用NotificationManager类的notify()方法，最终通过binder调用，会进入system_server进程的 NotificationManagerService(简称NMS)，执行enqueueNotificationWithTag()方法。

[- NotificationManagerService.java]

这个过程主要功能：

接下来看看WorkerHandler到底运行在哪个线程，这需要从NMS服务初始化过程来说起：

[- SystemServer.java]

该过程运行在system_server进程的主线程。

[- SystemServiceManager.java]

该过程先创建NotificationManagerService(简称NMS)，然后再调用其onStart方法。

[- NMS.java]

到此，我们可以得知onStart()过程创建的mHandler运行在system_server的主线程。那么上面的执行流便进入了 system_server主线程。

[- NMS.java]

这里的mListeners是指NotificationListeners对象

[- NMS.java]

这里是在system_server进程中第二次采用异步方式来处理。

此处的listener来自于ManagedServiceInfo的service成员变量，listener数据类型是NotificationListenerWrapper的代理对象，详见第三大节。 此处sbnHolder的数据类型为StatusBarNotificationHolder，继承于IStatusBarNotificationHolder.Stub对象，经过binder调用进入到systemui进程的 便是IStatusBarNotificationHolder.Stub.Proxy对象。

[- NotificationListenerService.java]

此时运行在systemui进程，sbnHolder是IStatusBarNotificationHolder的代理端。 此处mHandler = new MyHandler(getMainLooper())，也就是运行在systemui主线程的handler

[- NotificationListenerService.java]

此处调用NotificationListenerService实例对象的onNotificationPosted()

[- BaseStatusBar.java]

此处的mHandler便是systemui的主线程

[- PhoneStatusBar.java]

如果创建的通知视图为空则会直接返回。

[- BaseStatusBar.java]

[- SystemServer.java]

[- SystemServer.java]

启动服务SystemUIService，运行在进程com.android.systemui，接下来进入systemui进程

[- SystemUIService.java]

服务启动后，先执行其onCreate()方法

[- SystemUIApplication.java]

此处以SystemBars为例来展开

[- SystemUIApplication.java]

[- SystemBars.java]

[- SystemBars.java]

config_statusBarComponent的定义位于文件config.xml中，其值为PhoneStatusBar。

[- PhoneStatusBar.java]

[- BaseStatusBar.java]

[- NotificationListenerService.java]

经过binder调用，向system_server中的NMS注册监听器

[- NMS.java]

mListeners的对象类型为ManagedServices。此处的INotificationListener便是NotificationListenerWrapper的代理对象

[- ManagedServices.java]

[- ManagedServices.java]

[- ManagedServices.java]

可见，前面的listener的对端便是运行在systemui中的NotificationListenerWrapper的代理对象。

整个过程涉及到3个Handler都是运行在system_server的主线程：NMS的mHandler，NLS的mHandler以及BaseStatusBar的mHandler。

一次通知发送的过程，在system_server进程里面经过了步骤[2.3]，[2.4]的两次异步调用，进入systemui进程，也经历[2.6]，[2.8]共两次异步调用。 本身是异步调用，再进过一次异步意义并不大。

另外，这里需要注意的是前台服务也会显示通知，该通知是为了提升服务的优先级，并且让用户可感知该服务的存在，以防止进程被杀，比如音乐播放。 对于常规的通知可通过点击通知(允许清除的通知)或者点击通知栏的清除按钮来清除。

vue 跨页面通信怎么弄

在vue的项目里面，组件之间相互通信的方式有很多，比如props/$emit、$on/$emit、vuex以及利用ref通信等方式。跨组件有这么多的通信方式可以选择，但是当需求要求我们跨页面通信怎么办呢？

由于每个页面都是一个独立的vue实例，页面与页面之间不存在数据上的沟通，所以，从vue框架上暂时行不通了。然后想到可以利用页面缓存的方式来进行通信。

在Web Storage中有两种储存数据的方式，分别是sessionStorage和localStorage，他们之间的区别在于生命周期的不同以及作用域（同源条件下）的不同。sessionStorage仅在当前会话中有效，关闭页面或者浏览器后数据会被自动清除，其作用域仅限于当前页面，不能跨tab页面访问。localStorage的生命周期是永久有效，只要是不主动删除，数据会一直被存储下来，其作用域也可以跨同源的页面访问。

有了localStorage跨页面的作用域，就可以做到页面之间的通信了，这下只要能解决如何监听其存储数据的变化就能实现了。于是想到了一个比较粗暴的方式——利用定时器：在一定间隔时间内获取localStorage中的数据并更新到获取数据的页面中去，这样便实现了数据的监听。但这样未免也太耗费性能了，为了少耗费性能而拉长时间间隔，但数据又总是更新不及时。这样这个方式就被待定了。

这时了解到有一个专门用来监听本地存储的数据变化的事件为Storage事件：Web Storage API内建了一套事件通知机制，当存储区域的内容发生改变（包括增加、修改、删除数据）时，就会自动触发 storage 事件，并把它发送给所有感兴趣的监听者。所有支持 localStorage 的浏览器都支持 storage 事件，包括 IE8。但IE 8不支持 W3C 标准的 addEventListener。因此，为了监听 storage 事件，还需要检测浏览器支持哪种事件机制：

有了这个storage事件，跨页面通信就变得很容易了：

【深入解析MAX OSX & iOS操作系统】读书笔记 —— OS X 和 iOS 使用的技术

作为一个BSD衍生的操作系统，OSX继承了很多BSD的特性，包括POSIX系统调用、一些BSD扩展（内核队列）以及BSD的强制访问控制。

苹果新增的内容：“沙盒”机制。替换了原本系统配置的/etc目录。标准的UNIX syslog被AppleSystem Log增强了。还有FSEvents新技术。

尽管XNU的绝对的核心是Mach，但XNU向用户态展现出来的主要接口是BSD层。

sysctl(8)访问内核内部状态的标准方法。直接查询内核变量的值，获得重要的运行时诊断信息。也可以设置可写变量的值。

内核组件也可以在运行会注册额外的sysctl变量值，甚至增加整个名称空间。

sysctl变量的范围很广，包括从一些简单的调试变量到其他可控制整个子系统行为的读写变量。ps和netstat都依赖于sysctl获得PID和socket系列，当然也可以通过其他方式获得。

kqueue是BSD中使用的内核事件通知机制。一个kqueue指的是一个描述符，这个描述符会阻塞等待知道一个特定类型和种类的事件发生。用户态的进程（或内核）可以等待这个描述符，因为kqueue提供了一种用于一个或多个进程同步的简单高效的方法。

kqueue和对应的 kevent（表示事件的数据结构） 构成了内核异步I/O的基础。

审计是OSX中一个自包含的子系统。主要的用户态组件是auditd，由launchd根据需要而启动的后台服务进程。这个后台服务进程不负责实际的审计日志记录，审计日志记录是由内核本身直接完成的。然后这个后台服务进程能控制内核。

如果启用了审计，那么XNU中编号从350到359的系统调用都被分配用于启用和控制审计。

添加了对象级别的安全性，限制特定进程针对具体文件或资源的访问权限。可以控制一个给定的应用程序不允许访问用户的私有数据或某网站。

从内核的角度看，在各种系统调用的实现中插入了对MAC的调用，每一个系统调用都必须先通过MAC的验证，然后才能真正处理来自用户态的请求。

MAC是OSX的隔离机制和iOS的entitlement机制的基础。

UNIX从传统上都依赖密码文件 /etc/passwd 和保存密码的散列文件 /etc/shadow 。在OSX单用户（以及iOS）中，使用 /etc/master.passwd 作为shadow文件，其他情况都放弃了这些密码文件，使用自己的 目录服务 。

目录服务的维护的内容不仅仅是用户和用户组，还保存了系统配置和很多其他方面的信息。

OSX还抛弃了大部分其他配置文件，这些配置文件传统上在UNIX中是当做系统“注册表”使用的。

为了维护系统配置，OSX和IOS使用了一个特殊的守护程序—— configd(8) ，这个守护程序可以加载额外的可加载的bundle（插件），这个bundle位于 /System/Library/SystemConfiguration 下，包含IP和IPv6配置、日志以及其他bundle。

可通过工具 scutil 来流量和查询系统配置。

OSX也继承了传统UNIX的系统日志功能。OSX10.4引入新的日志模型，ASL，提供了更多特性，例如过滤和搜索。

ASL采用模块化设置，同时提供了以下四种日志接口：

ASL日志收集在 /var/log/asl 目录中。 aslmanager(8) 命令负责管理这些日志，launchd自动运行这条命令。

ASL日志采用的是二进制格式，而不是syslog采用的文本文件。日志文件变小了，但不像syslog那么对grep友好。OSX包含了syslog()命令用于显示和查看日志，并提供了搜索和过滤的功能。

OSX有非常强大的支持脚本的能力。通过osascript(1)命令和友好的Automator应用程序可以访问AppleScript

FSEvents是文件系统的通知API，应用程序可以简单快速地响应文件添加、修改和删除事件。

OSX提供了一个系统级的通知机制，这是分布式IPC的一种形式。

通知机制核心部分在于notifyd(8)守护进程，在系统引导时启动，这是Darwin的通知服务器。

Entitlement可以将一些表现行为良好的应用程序单独从监禁中释放出来。

面试官：请问Nginx为什么比Apache性能好

Nginx才短短几年，就拿下了web服务器大笔江山，众所周知，Nginx在处理大并发静态请求方面，效率明显高于httpd，甚至能轻松解决C10K问题。下面我们就来聊聊Web服务器背后的一些原理。

进程是具有一定独立功能的，在计算机中已经运行的程序的实体。在早期系统中（如linux 2.4以前），进程是基本运作单位，在支持线程的系统中（如windows，linux2.6）中，线程才是基本的运作单位，而进程只是线程的容器。程序本身只是指令、数据及其组织形式的描述，进程才是程序（那些指令和数据）的真正运行实例。若干进程有可能与同一个程序相关系，且每个进程皆可以同步（循序）或异步（平行）的方式独立运行。现代计算机系统可在同一段时间内以进程的形式将多个程序加载到存储器中，并借由时间共享（或称时分复用），以在一个处理器上表现出同时（平行性）运行的感觉。同样的，使用多线程技术（多线程即每一个线程都代表一个进程内的一个独立执行上下文）的操作系统或计算机架构，同样程序的平行线程，可在多 CPU 主机或网络上真正同时运行（在不同的CPU上）。

Web服务器要为用户提供服务，必须以某种方式，工作在某个套接字上。一般Web服务器在处理用户请求是，一般有如下三种方式可选择：多进程方式、多线程方式、异步方式。Web服务器要为用户提供服务，必须以某种方式，工作在某个套接字上。一般Web服务器在处理用户请求是，一般有如下三种方式可选择：多进程方式、多线程方式、异步方式。多进程方式：为每个请求启动一个进程来处理。由于在操作系统中，生成进程、销毁进程、进程间切换都很消耗CPU和内存，当负载高是，性能会明显降低。优点： 稳定性！由于采用独立进程处理独立请求，而进程之间是独立的，单个进程问题不会影响其他进程，因此稳定性最好。缺点： 资源占用！当请求过大时，需要大量的进程处理请求，进程生成、切换开销很大，而且进程间资源是独立的，造成内存重复利用。多线程方式：一个进程中用多个线程处理用户请求。由于线程开销明显小于进程，而且部分资源还可以共享，因此效率较高。优点：开销较小！线程间部分数据是共享的，且线程生成与线程间的切换所需资源开销比进程间切换小得多。缺点：稳定性！线程切换过快可能造成线程抖动，且线程过多会造成服务器不稳定。异步方式：使用非阻塞方式处理请求，是三种方式中开销最小的。但异步方式虽然效率高，但要求也高，因为多任务之间的调度如果出现问题，就可能出现整体故障，因此使用异步工作的，一般是一些功能相对简单，但却符合服务器任务调度、且代码中没有影响调度的错误代码存在的程序。优点：性能最好！一个进程或线程处理多个请求，不需要额外开销，性能最好，资源占用最低。缺点：稳定性！某个进程或线程出错，可能导致大量请求无法处理，甚至导致整个服务宕机。

通过这样的一个复杂过程，一次请求就完成了。简单来说就是：用户请求--送达到用户空间--系统调用--内核空间--内核到磁盘上读取网页资源-返回到用户空间-响应给用户。上述简单的说明了一下，客户端向Web服务请求过程，在这个过程中，有两个I/O过程，一个就是客户端请求的网络I/O，另一个就是Web服务器请求页面的磁盘I/O。 下面我们就来说说Linux的I/O模型。

通过上面的对连接的处理分析，我们知道工作在用户空间的web服务器进程是无法直接操作IO的，需要通过系统调用进行，其关系如下：

即进程向内核进行系统调用申请IO，内核将资源从IO调度到内核的buffer中（wait阶段），内核还需将数据从内核buffer中复制（copy阶段）到web服务器进程所在的用户空间，才算完成一次IO调度。这几个阶段都是需要时间的。根据wait和copy阶段的处理等待的机制不同，可将I/O动作分为如下五种模式：

这里有必要先解释一下阻塞、非阻塞，同步、异步、I/O的概念。

阻塞和非阻塞指的是执行一个操作是等操作结束再返回，还是马上返回。比如餐馆的服务员为用户点菜，当有用户点完菜后，服务员将菜单给后台厨师，此时有两种方式：第一种：就在出菜窗口等待，直到厨师炒完菜后将菜送到窗口，然后服务员再将菜送到用户手中；第二种：等一会再到窗口来问厨师，某个菜好了没？如果没有先处理其他事情，等会再去问一次；第一种就是阻塞方式，第二种则是非阻塞的。

同步和异步又是另外一个概念，它是事件本身的一个属性。还拿前面点菜为例，服务员直接跟厨师打交道，菜出来没出来，服务员直接指导，但只有当厨师将菜送到服务员手上，这个过程才算正常完成，这就是同步的事件。同样是点菜，有些餐馆有专门的传菜人员，当厨师炒好菜后，传菜员将菜送到传菜窗口，并通知服务员，这就变成异步的了。其实异步还可以分为两种：带通知的和不带通知的。前面说的那种属于带通知的。有些传菜员干活可能主动性不是很够，不会主动通知你，你就需要时不时的去关注一下状态。这种就是不带通知的异步。对于同步的事件，你只能以阻塞的方式去做。而对于异步的事件，阻塞和非阻塞都是可以的。非阻塞又有两种方式：主动查询和被动接收消息。被动不意味着一定不好，在这里它恰恰是效率更高的，因为在主动查询里绝大部分的查询是在做无用功。对于带通知的异步事件，两者皆可。而对于不带通知的，则只能用主动查询。

回到I/O，不管是I还是O，对外设(磁盘)的访问都可以分成请求和执行两个阶段。请求就是看外设的状态信息（比如是否准备好了），执行才是真正的I/O操作。在Linux 2.6之前，只有“请求”是异步事件，2.6之后才引入AIO（asynchronous I/O ）把“执行”异步化。别看Linux/Unix是用来做服务器的，这点上比Windows落后了好多，IOCP（Windows上的AIO，效率极高）在Win2000上就有了。所以学linux的别老觉得Windows这里不好那里不好（Windows的多线程机制也由于linux）。

根据以上分析，I/O可分为五种模型：

Linux上的前四种I/O模型的“执行”阶段都是同步的，只有最后一种才做到了真正的全异步。第一种阻塞式是最原始的方法，也是最累的办法。当然累与不累要看针对谁。应用程序是和内核打交道的。对应用程序来说，这种方式是最累的，但对内核来说这种方式恰恰是最省事的。还拿点菜这事为例，你就是应用程序，厨师就是内核，如果你去了一直等着，厨师就省事了（不用同时处理其他服务员的菜）。当然现在计算机的设计，包括操作系统，越来越为终端用户考虑了，为了让用户满意，内核慢慢的承担起越来越多的工作，IO模型的演化也是如此。非阻塞I/O ，I/O复用，信号驱动式I/O其实都是非阻塞的，当然是针对“请求”这个阶段。非阻塞式是主动查询外设状态。I/O复用里的select，poll也是主动查询，不同的是select和poll可以同时查询多个fd（文件句柄）的状态，另外select有fd个数的限制。epoll是基于回调函数的。信号驱动式I/O则是基于信号消息的。这两个应该可以归到“被动接收消息”那一类中。最后就是伟大的AIO的出现，内核把什么事都干了，对上层应用实现了全异步，性能最好，当然复杂度也最高。

说明：应用程序调用一个IO函数，导致应用程序阻塞，等待数据准备好。 如果数据没有准备好，一直等待数据准备好了，从内核拷贝到用户空间,IO函数返回成功指示。这个不用多解释吧，阻塞套接字。下图是它调用过程的图示：（注，一般网络I/O都是阻塞I/O，客户端发出请求，Web服务器进程响应，在进程没有返回页面之前，这个请求会处于一直等待状态）

我们把一个套接口设置为非阻塞就是告诉内核，当所请求的I/O操作无法完成时，不要将进程睡眠，而是返回一个错误。这样我们的I/O操作函数将不断的测试数据是否已经准备好，如果没有准备好，继续测试，直到数据准备好为止。在这个不断测试的过程中，会大量的占用CPU的时间，所有一般Web服务器都不使用这种I/O模型。具体过程如下图:

I/O复用模型会用到select或poll函数或epoll函数(Linux2.6以后的内核开始支持)，这两个函数也会使进程阻塞，但是和阻塞I/O所不同的的，这两个函数可以同时阻塞多个I/O操作。而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操作函数。具体过程如下图:

首先，我们允许套接口进行信号驱动I/O，并安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，可以在信号处理函数中调用I/O操作函数处理数据。具体过程如下图:

当一个异步过程调用发出后，调用者不能立刻得到结果。实际处理这个调用的部件在完成后，通过状态、通知和回调来通知调用者的输入输出操作。具体过程如下图:

从上图中我们可以看出，可以看出，越往后，阻塞越少，理论上效率也是最优。其五种I/O模型中，前三种属于同步I/O，后两者属于异步I/O。

同步I/O:

异步I/O:

异步 I/O 和 信号驱动I/O的区别:

注，其中iocp是Windows实现的，select、poll、epoll是Linux实现的，kqueue是FreeBSD实现的，/dev/poll是SUN的Solaris实现的。select、poll对应第3种（I/O复用）模型，iocp对应第5种（异步I/O）模型，那么epoll、kqueue、/dev/poll呢？其实也同select属于同一种模型，只是更高级一些，可以看作有了第4种（信号驱动I/O）模型的某些特性，如callback机制。

答案是，他们无轮询。因为他们用callback取代了。想想看，当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度，不管哪个Socket是活跃的，都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll、kqueue、/dev/poll做的。这样子说可能不好理解，那么我说一个现实中的例子，假设你在大学读书，住的宿舍楼有很多间房间，你的朋友要来找你。select版宿管大妈就会带着你的朋友挨个房间去找，直到找到你为止。而epoll版宿管大妈会先记下每位同学的房间号，你的朋友来时，只需告诉你的朋友你住在哪个房间即可，不用亲自带着你的朋友满大楼找人。如果来了10000个人，都要找自己住这栋楼的同学时，select版和epoll版宿管大妈，谁的效率更高，不言自明。同理，在高并发服务器中，轮询I/O是最耗时间的操作之一，select、epoll、/dev/poll的性能谁的性能更高，同样十分明了。

诚然，Windows的IOCP非常出色，目前很少有支持asynchronous I/O的系统，但是由于其系统本身的局限性，大型服务器还是在UNIX下。而且正如上面所述，kqueue、epoll、/dev/poll 与 IOCP相比，就是多了一层从内核copy数据到应用层的阻塞，从而不能算作asynchronous I/O类。但是，这层小小的阻塞无足轻重，kqueue、epoll、/dev/poll 已经做得很优秀了。

只有IOCP(windows实现)是asynchronous I/O，其他机制或多或少都会有一点阻塞。select（Linux实现）低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善epoll(Linux实现)、kqueue（FreeBSD实现）、/dev/poll（Solaris实现）是Reacor模式，IOCP是Proactor模式。Apache 2.2.9之前只支持select模型，2.2.9之后支持epoll模型Nginx 支持epoll模型Java nio包是select模型

我们都知道Apache有三种工作模块，分别为prefork、worker、event。prefork：多进程，每个请求用一个进程响应，这个过程会用到select机制来通知。worker：多线程，一个进程可以生成多个线程，每个线程响应一个请求，但通知机制还是select不过可以接受更多的请求。event：基于异步I/O模型，一个进程或线程，每个进程或线程响应多个用户请求，它是基于事件驱动（也就是epoll机制）实现的。

如果不用“--with-mpm”显式指定某种MPM,prefork就是Unix平台上缺省的MPM.它所采用的预派生子进程方式也是 Apache1.3中采用的模式。prefork本身并没有使用到线程，2.0版使用它是为了与1.3版保持兼容性；另一方面，prefork用单独的子进程来处理不同的请求，进程之间是彼此独立的,这也使其成为最稳定的MPM之一。

相对于prefork，worker是2.0版中全新的支持多线程和多进程混合模型的MPM。由于使用线程来处理，所以可以处理相对海量的请求，而系统资源的开销要小于基于进程的服务器。但是，worker也使用了多进程,每个进程又生成多个线程，以获得基于进程服务器的稳定性，这种MPM的工作方 式将是Apache2.0的发展趋势。

一个进程响应多个用户请求，利用callback机制，让套接字复用，请求过来后进程并不处理请求，而是直接交由其他机制来处理，通过epoll机制来通知请求是否完成；在这个过程中，进程本身一直处于空闲状态，可以一直接收用户请求。可以实现一个进程程响应多个用户请求。支持持海量并发连接数，消耗更少的资源。

有几个基本条件：

刚好，Nginx 支持以上所有特性。所以Nginx官网上说，Nginx支持50000并发，是有依据的。

传统上基于进程或线程模型架构的web服务通过每进程或每线程处理并发连接请求，这势必会在网络和I/O操作时产生阻塞，其另一个必然结果则是对内存或CPU的利用率低下。生成一个新的进程/线程需要事先备好其运行时环境，这包括为其分配堆内存和栈内存，以及为其创建新的执行上下文等。这些操作都需要占用CPU，而且过多的进程/线程还会带来线程抖动或频繁的上下文切换，系统性能也会由此进一步下降。另一种高性能web服务器/web服务器反向代理：Nginx（Engine X），nginx的主要着眼点就是其高性能以及对物理计算资源的高密度利用，因此其采用了不同的架构模型。受启发于多种操作系统设计中基于“事件”的高级处理机制，nginx采用了模块化、事件驱动、异步、单线程及非阻塞的架构，并大量采用了多路复用及事件通知机制。在nginx中，连接请求由为数不多的几个仅包含一个线程的进程worker以高效的回环(run-loop)机制进行处理，而每个worker可以并行处理数千个的并发连接及请求。

Nginx会按需同时运行多个进程：一个主进程(master)和几个工作进程(worker)，配置了缓存时还会有缓存加载器进程(cache loader)和缓存管理器进程(cache manager)等。所有进程均是仅含有一个线程，并主要通过“共享内存”的机制实现进程间通信。主进程以root用户身份运行，而worker、cache loader和cache manager均应以非特权用户身份运行。

主进程主要完成如下工作：

注：如果负载以CPU密集型应用为主，如SSL或压缩应用，则worker数应与CPU数相同；如果负载以IO密集型为主，如响应大量内容给客户端，则worker数应该为CPU个数的1.5或2倍。

Nginx的代码是由一个核心和一系列的模块组成, 核心主要用于提供Web Server的基本功能，以及Web和Mail反向代理的功能；还用于启用网络协议，创建必要的运行时环境以及确保不同的模块之间平滑地进行交互。不过，大多跟协议相关的功能和某应用特有的功能都是由nginx的模块实现的。这些功能模块大致可以分为事件模块、阶段性处理器、输出过滤器、变量处理器、协议、upstream和负载均衡几个类别，这些共同组成了nginx的http功能。事件模块主要用于提供OS独立的(不同操作系统的事件机制有所不同)事件通知机制如kqueue或epoll等。协议模块则负责实现nginx通过http、tls/ssl、smtp、pop3以及imap与对应的客户端建立会话。在Nginx内部，进程间的通信是通过模块的pipeline或chain实现的；换句话说，每一个功能或操作都由一个模块来实现。例如，压缩、通过FastCGI或uwsgi协议与upstream服务器通信，以及与memcached建立会话等。

处理静态文件，索引文件以及自动索引；反向代理加速(无缓存)，简单的负载均衡和容错；FastCGI，简单的负载均衡和容错；模块化的结构。过滤器包括gzipping, byte ranges, chunked responses, 以及 SSI-filter 。在SSI过滤器中，到同一个 proxy 或者 FastCGI 的多个子请求并发处理；SSL 和 TLS SNI 支持；

使用外部 HTTP 认证服务器重定向用户到 IMAP/POP3 后端；使用外部 HTTP 认证服务器认证用户后连接重定向到内部的 SMTP 后端；认证方法：POP3: POP3 USER/PASS, APOP, AUTH LOGIN PLAIN CRAM-MD5;IMAP: IMAP LOGIN;SMTP: AUTH LOGIN PLAIN CRAM-MD5;SSL 支持；在 IMAP 和 POP3 模式下的 STARTTLS 和 STLS 支持；

FreeBSD 3.x, 4.x, 5.x, 6.x i386; FreeBSD 5.x, 6.x amd64;Linux 2.2, 2.4, 2.6 i386; Linux 2.6 amd64;Solaris 8 i386; Solaris 9 i386 and sun4u; Solaris 10 i386;MacOS X (10.4) PPC;Windows 编译版本支持 windows 系列操作系统

一个主进程和多个工作进程，工作进程运行于非特权用户；kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select, 以及 poll 支持；kqueue支持的不同功能包括 EV_CLEAR, EV_DISABLE （临时禁止事件）， NOTE_LOWAT, EV_EOF, 有效数据的数目，错误代码；sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+), 和 sendfilev (Solaris 8 7/01+) 支持；输入过滤 (FreeBSD 4.1+) 以及 TCP_DEFER_ACCEPT (Linux 2.4+) 支持；10,000 非活动的 HTTP keep-alive 连接仅需要 2.5M 内存。最小化的数据拷贝操作；

基于IP 和名称的虚拟主机服务；Memcached 的 GET 接口；支持 keep-alive 和管道连接；灵活简单的配置；重新配置和在线升级而无须中断客户的工作进程；可定制的访问日志，日志写入缓存，以及快捷的日志回卷；4xx-5xx 错误代码重定向；基于 PCRE 的 rewrite 重写模块；基于客户端 IP 地址和 HTTP 基本认证的访问控制；PUT, DELETE, 和 MKCOL 方法；支持 FLV （Flash 视频）；带宽限制；

在高连接并发的情况下，Nginx是Apache服务器不错的替代品: Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一. 能够支持高达 50,000 个并发连接数的响应, 感谢Nginx为我们选择了 epoll and kqueue 作为开发模型。Nginx作为负载均衡服务器: Nginx 既可以在内部直接支持 Rails 和 PHP 程序对外进行服务, 也可以支持作为 HTTP代理 服务器对外进行服务. Nginx采用C进行编写, 不论是系统资源开销还是CPU使用效率都比 Perlbal 要好很多。作为邮件代理服务器: Nginx 同时也是一个非常优秀的邮件代理服务器（最早开发这个产品的目的之一也是作为邮件代理服务器）, Last.fm 描述了成功并且美妙的使用经验.Nginx 安装非常的简单 , 配置文件非常简洁（还能够支持perl语法）,Bugs 非常少的服务器: Nginx 启动特别容易, 并且几乎可以做到7*24不间断运行，即使运行数个月也不需要重新启动. 你还能够 不间断服务的情况下进行软件版本的升级 。Nginx 的诞生主要解决C10K问题

事件性通知怎么保证可靠通信

生产阶段
在这个阶段，生产者将消息生产出来，并经过网络传输发送到服务器Broker端。
在这里，最常用的就是"发送-确认"机制来保证消息的可靠传递。当你的代码调用发送消息方法时，消息队列的客户端就会发送消息，服务端收到消息后会向给客户端发送一个确认响应，表明消息被收到了。客户端收到确认响应后，完成一次消息传递。如果客户端长时间没有收到确认响应，有些消息队列会重新发送这条消息，如果重发再失败，会以返回值或者异常的方法通知用户。
你在编写发送消息代码的时候，只要正确处理返回值或者捕捉异常就能保证消息不会丢失。同步发送时，只要加上try catch捕捉即可。异步发送在回调函数中检查。
2. 存储阶段
在存储阶段只要broker在正常运行，就能保证消息不会丢失，但是如果进程死掉了，或者服务器宕机了，还是有可能出现消息丢失的。
如果对消息的可靠性要求比较高，可以通过配置Broker参数来避免因为宕机丢消息。
对于单个节点的broker，需要配置broker参数，在收到消息后，将消息写入磁盘再给客户端发送确认响应。如果broker是多个节点组成的集群，那么可以配置成至少将消息发送到2个以上的节点，再给客户端发送确认响应，当单个broker宕机时，其他的broker可以替代宕机的broker，也不会发生消息丢失。
​3. 消费阶段
​ ​消息队列在消费阶段采用了和生产阶段相同的确认机制。你需要注意的是，不要受到消息以后立即发送确认响应，而是应该在业务逻辑处理完成后再发送。
​我们在上诉三个阶段做出正确的配置和编写代码，配合消息队列的可靠性机制，就能保证消息的可靠性传递。我们来总结一下：
在生产阶段：正确的捕获没有接受到确认响应的异常，并做出相应的处理
在存储阶段：正确的配置消息队列相关参数，选择刷盘或者将消息至少发送至两个节点再发送确认响应
在消费阶段：收到消息以后，先进行业务逻辑处理，再发送消费确认响应
​思考：如果确认响应在网络传输过程中丢失，也会导致重发消息。也就是说，无论是broker还是consumer都是有可能收到重复消息的。如何处理这一些重复消息才能不能影响到正常的业务逻辑呢？ 关于事件通知机制和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 事件通知机制的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、事件通知机制的信息别忘了在本站进行查找喔。