事件驱动

在nginx调用 ngx_http_process_request_headers() 方法读取完所有的header数据之后，就调用 ngx_http_process_request() 方法开始了请求的处理过程，这也就是nginx http模块开始处理请求的11个阶段的入口，本文则主要讲解nginx是如驱动http模块的11个阶段。 1. 处理入口 ngx_http_process_request() 关于 ngx_http_process_request() 方法，这里首先有两点需要读者理解的： nginx是在接收完header数据之后就开始进入http模块的11个阶段进行处理的，这主要是因为，相对于多变的body数据，nginx更关注如何控制header数据的处理； ngx_http_process_request() 方法只是一个入口方法，最终这个方法将会进入执行http模块11个阶段的调用中，而这个部分是会读取请求的body数据的。由于TCP是流式数据，也就是说一次接收并不一定能够完整的接收所有数据，而且http模块的11个阶段中有部分阶段也可能会要求再次进行当前阶段的调用，这就还是回归到事件框架中了，这个时候会把事件的回调函数设置为 ngx_http_request_handler() 方法，根据请求需要，其是可以不断的将控制权交给该方法，以进行再次调用。也就是说这里的

1.1 概述 　　　　　　　　JS 是以事件驱动为核心的一门语言。 1.2 事件三要素 　　　　　　　　 　 事件源、事件、事件驱动程序。 三句话：获取事件源、绑定事件、书写事件驱动程序。 获取事件源： document.getElementById(“box”); 绑定事件： box.onclick = function(){ 程序 }; 书写事件驱动程序：以后要学习的关于 DOM 的操作。 1.2.1 事件有哪些 来源： https://www.cnblogs.com/BingBing-Deng/p/10354203.html

原文链接 前言 事件驱动为广大的程序员所熟悉，其最为人津津乐道的是在图形化界面编程中的应用；事实上，在网络编程中事件驱动也被广泛使用，并大规模部署在高连接数高吞吐量的服务器程序中，如 http 服务器程序、ftp 服务器程序等。相比于传统的网络编程方式，事件驱动能够极大的降低资源占用，增大服务接待能力，并提高网络传输效率。 关于本文提及的服务器模型，搜索网络可以查阅到很多的实现代码，所以，本文将不拘泥于源代码的陈列与分析，而侧重模型的介绍和比较。使用 libev 事件驱动库的服务器模型将给出实现代码。 本文涉及到线程 / 时间图例，只为表明线程在各个 IO 上确实存在阻塞时延，但并不保证时延比例的正确性和 IO 执行先后的正确性；另外，本文所提及到的接口也只是笔者熟悉的 Unix/Linux 接口，并未推荐 Windows 接口，读者可以自行查阅对应的 Windows 接口。 阻塞型的网络编程接口 几乎所有的程序员第一次接触到的网络编程都是从 listen()、send()、recv() 等接口开始的。使用这些接口可以很方便的构建服务器 / 客户机的模型。 我们假设希望建立一个简单的服务器程序，实现向单个客户机提供类似于“一问一答”的内容服务。 图 1. 简单的一问一答的服务器 / 客户机模型 我们注意到，大部分的 socket 接口都是阻塞型的。所谓阻塞型接口是指系统调用（一般是

在微服务架构中，需要调用很多服务才能完成一项功能。服务之间如何互相调用就变成微服务架构中的一个关键问题。 服务调用有两种方式，一种是RPC方式，另一种是事件驱动（Event-driven）方式，也就是发消息方式。 消息方式是松耦合方式，比紧耦合的RPC方式要优越，但RPC方式如果用在适合的场景也有它的一席之地。 我们总在谈耦合，那么耦合到底意味着什么呢？ 耦合的种类： 时间耦合： 客户端和服务端必须同时上线才能工作。发消息时，接受消息队列必须运行，但后台处理程序暂时不工作也不影响。 容量耦合： 客户端和服务端的处理容量必须匹配。发消息时，如果后台处理能力不足也不要紧，消息队列会起到缓冲的作用。 接口耦合： RPC调用有函数标签，而消息队列只是一个消息。例如买了商品之后要调用发货服务，如果是发消息，那么就只需发送一个商品被买消息。 发送方式耦合： RPC是点对点方式，需要知道对方是谁，它的好处是能够传回返回值。消息既可以点对点，也可以用广播的方式，这样减少了耦合，但也使返回值比较困难。 下面我们来逐一分析这些耦合的影响。第一，时间耦合，对于多数应用来讲，你希望能马上得到回答，因此即使使用消息队列，后台也需要一直工作。 第二，容量耦合，如果你对回复有时间要求，那么消息队列的缓冲功能作用不大，因为你希望及时响应。 真正需要的是自动伸缩（Auto-scaling）

2020-02-12 关键字： 在 Linux 内核当中，处理一个中断事件需要知道两件事： 1、中断号码 2、中断处理函数 而在 ARM 中处理中断则需要知道以下四件事： 1、中断源号码 2、初始化中断控制器 3、初始化 CPU 中断功能 4、中断处理函数 获取中断号有以下两种方式： 1、宏定义 通过查询芯片手册上记载的相应中断编号，再经过系统预置的 IRQ_EINT(编号) 来得到中断号。 2、设备树文件 首先查询相应设备树头文件 dtsi，找到我们要用的那个中断组的描述，形如下所示： gpx1: gpx1{ 　　gpio-controller; 　　#gpio-cells = <2>; 　　interrupt-controller; 　　interrupt-parent = <&gic>; 　　interrupts = <0 24 0>, <0 25 0>, <0 26 0>, <0 27 0>, <0 28 0>; 　　#interrupt-cells = <2> }; 上面的 interrupt-controller; 表示以下描述的是和中断控制器相关的信息。 interrupts 描述的是 gpx1 这个节点所要控制或者说使用的中断号列表。 #interrupt-cells 描述的是长度，记住是长度就好了。 其次再在我们自己的 dts 里添加上我们想要的中断信息节点：

代码已经上传至 https://github.com/masteryourself/study-spring.git ，分支是 master ，工程是 study-spring-framework 1. Event 1.1 ApplicationListener 监听容器中发布的事件，事件驱动模型开发 监听 ApplicationEvent 及其子类的事件 1.2 @EventListener 可以使用注解简化开发，原理是通过 EventListenerMethodProcessor 处理器解析方法上的 @EventListener 注解 2. 代码 1. MyAnnotationListener @Component public class MyAnnotationListener { @EventListener ( classes = { ApplicationEvent . class } ) public void applicationEventListen ( ApplicationEvent event ) { System . out . println ( "MyAnnotationListener 接收到事件：" + event . getClass ( ) ) ; } } 2. MyApplicationListener @Component public

引用 ：https://www.cnblogs.com/woodyblog/p/6061671.html 前言 说到js的单线程（single threaded）和异步（asynchronous），很多同学不禁会想，这不是自相矛盾么？其实，单线程和异步确实不能同时成为一个语言的特性。js选择了成为单线程的语言，所以它本身不可能是异步的，但js的宿主环境（比如浏览器，Node）是多线程的，宿主环境通过某种方式（事件驱动，下文会讲）使得js具备了异步的属性。往下看，你会发现js的机制是多么的简单高效！ 说说浏览器 js是单线程语言，浏览器只分配给js一个主线程，用来执行任务（函数），但一次只能执行一个任务，这些任务形成一个任务队列排队等候执行，但前端的某些任务是非常耗时的，比如网络请求，定时器和事件监听，如果让他们和别的任务一样，都老老实实的排队等待执行的话，执行效率会非常的低，甚至导致页面的假死。所以，浏览器为这些耗时任务开辟了另外的线程，主要包括http请求线程，浏览器定时触发器，浏览器事件触发线程，这些任务是异步的。下图说明了浏览器的主要线程。 图片来自popAnt 画得太好，忍不住引过来 （ http://blog.csdn.net/kfanning/article/details/5768776 ） 再说说任务队列 刚才说到浏览器为网络请求这样的异步任务单独开了一个线程

前言 说到js的单线程（single threaded）和异步（asynchronous），很多同学不禁会想，这不是自相矛盾么？其实，单线程和异步确实不能同时成为一个语言的特性。js选择了成为单线程的语言，所以它本身不可能是异步的，但js的宿主环境（比如浏览器，Node）是多线程的，宿主环境通过某种方式（事件驱动，下文会讲）使得js具备了异步的属性。往下看，你会发现js的机制是多么的简单高效！ 说说浏览器 js是单线程语言，浏览器只分配给js一个主线程，用来执行任务（函数），但一次只能执行一个任务，这些任务形成一个任务队列排队等候执行，但前端的某些任务是非常耗时的，比如网络请求，定时器和事件监听，如果让他们和别的任务一样，都老老实实的排队等待执行的话，执行效率会非常的低，甚至导致页面的假死。所以，浏览器为这些耗时任务开辟了另外的线程，主要包括http请求线程，浏览器定时触发器，浏览器事件触发线程，这些任务是异步的。下图说明了浏览器的主要线程。 图片来自popAnt 画得太好，忍不住引过来 （ http://blog.csdn.net/kfanning/article/details/5768776 ） 再说说任务队列 刚才说到浏览器为网络请求这样的异步任务单独开了一个线程，那么问题来了，这些异步任务完成后，主线程怎么知道呢？答案就是回调函数，整个程序是事件驱动的

Spring事件驱动模型，简单来说类似于Message-Queue消息队列中的Pub/Sub发布/订阅模式，也类似于Java设计模式中的观察者模式。 自定义事件 Spring的事件接口位于 org.springframework.context.ApplicationEvent ，源码如下： public abstract class ApplicationEvent extends EventObject { private static final long serialVersionUID = 7099057708183571937L; private final long timestamp; public ApplicationEvent(Object source) { super(source); this.timestamp = System.currentTimeMillis(); } public final long getTimestamp() { return this.timestamp; } } 继承了Java的事件对象 EventObject ，所以可以使用 getSource() 方法来获取到事件传播对象。 自定义Spring事件 public class CustomSpringEvent extends ApplicationEvent {

一.传统编程模式 开始--->代码块A---->代码块B===>代码块C---->---->结束 每一个代码块完成不同的功能，但编程块之间有顺序，唯一能够改变这个流程的是数据，由于输入数据的不同，会有不同的结果。 二.事件驱动模型 开始---->初始化----->等待 与上面的传统模式不同，事件驱动程序在启动之后，就在那里等待。等待事件被触发，传统编程下也有等待的时候，例如，input则需要用户输入。编程者知道用户输入的内容与数据类型，这是传统编程模式。事件驱动模式等待的事件是未知，也不强制用户输入什么，只要某一件事件发生，程序会执行相应部分的内容， 三.事件驱动的本质 事件驱动模型的大体思想： 1.有一个事件（消息）队列 2.鼠标按下时，就将事件添加在该队列中 3.有个循环不断从该队列中取出事件，调用不同的函数 4.每个消息都各自保存各自独立的函数指针，这样，每个事件都有自己独立的处理函数/ 事件驱动编程是一种编程范式/这里程序的执行顺序有外部事件绝定，特点包含一个事件循环，当外部事件发生时会使用回调机制来触发相应的的处理。 来源： https://www.cnblogs.com/gjx1212/p/12276030.html