1.Nginx源码分析 - Event事件篇 - Event模块和配置的初始化
2.gem5 源码阅读 之 event
3.Nginx源码分析 - Event事件篇 - Epoll事件模块
4.说下你可能没用过的EventBus

Nginx源码分析 - Event事件篇 - Event模块和配置的初始化

       深入探讨Nginx源码分析中的Event事件篇，专注于Event模块和配置的初始化，旨在清晰理解配置解析与模块初始化的协同工作。

       Event模块的配置解析分为两层：最外层的events模块以及内层的ngx_events_module事件模块和ngx_event_core_module事件核心模块。

       在初始化流程中，最开始配置文件的ios 屏幕录制 源码初始化调用的是核心模块的指令集，即events模块的配置解析指令函数：ngx_events_block。这里涉及的事件模块结构主要包括：事件模块本身和事件核心模块，每层模块拥有特定的角色与功能。

       具体而言，事件核心模块初始化函数为ngx_event_module_init，而配置解析流程则始于解析顶层“event”的配置，并通过ngx_conf_parse方法实现。在顶层配置解析完成后，将进入对事件块block中的内容解析，即ngx_events_block方法执行，此方法为事件命令集的回调函数，负责核心模块配置信息的创建。

       配置初始化中，首先在ngx_init_cycle方法中完成核心模块初始化，但由于ngx_events_module中的create_conf方法为NULL，故不会调用创建配置的步骤。接着，顶层配置解析完成后，进入事件块block内容解析，通过遍历模块命令集cmd->set方法，100周年微信头像源码完成具体配置的创建与初始化。

       在配置获取过程中，首先从ngx_events_module获取配置信息，再通过查找找到ngx_event_core_module的配置信息。配置的获取涉及从事件模块到事件核心模块的层级访问，确保配置信息的准确获取。

       综上所述，Event事件篇中的模块和配置初始化通过多层解析与调用，确保了Nginx配置的完整执行与模块功能的有效实现。这一过程不仅涉及配置的层次结构，还涉及到初始化函数的精确调用与配置解析的细致处理，体现了Nginx源码设计的严谨与高效。

gem5 源码阅读 之 event

       Event在gem5中扮演核心角色，本文将聚焦几个关键问题的解答：

       gem5作为事件驱动型仿真器，能高效处理每个动作或响应，无需频繁检查全局时间，显著降低执行时间。每个继承自EventManager的SimObject实例均可承担事件管理职责。

       SimObject的schedule方法将事件排序并插入全局EventQueue，构建全局事件树。Event执行基于排序后的when+priority值，确保事件有序执行。

       以cache为例，事件注册流程始于DCachePort的recvTimingResp函数中的tickEvent自身调用schedule方法，进一步由cpu调用schedule，通达信拉升换手副图源码实际上就是EventManager的schedule函数，将事件插入到event queue中。

       事件的执行时机取决于其特性，如cache中的tickEvent执行数据传输动作，通常在recvTimingResp函数中触发，此时代表完整数据请求完成的事件点。

       事件树的执行依赖于event queue管理，主event queue在doSimLoop中处理，其他event queue通过thread_loop并行处理，并通过threadBarrier同步所有线程，确保事件同时执行。

       全局eventqueue通过getEventQueue函数生成，参数index指定queue索引，第一次使用时创建新对象，每个queue与一个线程关联，执行相关事件。

       EventQueue创建在不同使用场景中，例如cxx_config方式下，在main.cc文件中直接调用getEventQueue，生成全局eventqueue；gem5 within systemc方式下，在main.cc中实例化SimControl对象，进而调用simulate函数，管理全局eventqueue。

       在Python配置文件中，如fs.py，微信公众号怎么找网站源码通过build_test_system函数构建系统组件，cpu的eventq_index参数用于创建全局eventqueue，确保所有相关组件事件同步。

       综上所述，gem5通过事件驱动机制高效仿真系统行为，事件注册、执行、管理流程贯穿整个系统仿真过程，确保复杂系统行为的准确模拟。

Nginx源码分析 - Event事件篇 - Epoll事件模块

       本文重点解析Nginx源码中的epoll事件模块，作为事件模块家族的一员，epoll以其高效性广受开发者喜爱。

       Nginx的epoll事件模块位于源码文件 /event/module/ngx_epoll_module.c 中。

       一、epoll模块的数据结构

       epoll模块包含以下三个关键数据结构：

       ngx_epoll_commands: epoll模块命令集

       ngx_epoll_module_ctx: epoll模块上下文

       ngx_epoll_module: epoll模块配置

       二、epoll模块的初始化

       在配置文件初始化阶段，epoll模块的初始化工作主要在核心函数 ngx_events_block 中完成。

       随后，ngx_event_process_init 函数负责执行模块的初始化操作，ngx_epoll_init 用于具体实现epoll模块的初始化。

       三、核心函数

       epoll模块的关键功能体现在 ngx_epoll_process_events 函数，此函数实现了事件的收集和分发功能，是Nginx处理事件的核心。

       以上是吸拉派落手机指标公式源码对Nginx源码中epoll事件模块的简要分析。

说下你可能没用过的EventBus

       最近在Code Review过程中，我发现了一个业务场景：业务处理完成后，需要通知审核人员，通知方式包括短信和邮件。代码如下：

       这个方法对吗？

       针对这种常见的业务场景，我们首先会考虑同步或异步发送的问题。

       如果选择同步，会对接口的响应时间产生影响，并且与业务逻辑紧密耦合，这显然不是好的做法。

       一般情况下，我们会选择异步方式，使用消息队列（MQ）进行消息的发送和消费，或者使用线程池来处理，这样不会影响主业务逻辑，可以提高性能，并且实现了解耦。

       此外，我们还需要考虑数据一致性的问题，邮件是否一定要发送成功？

       大多数情况下，我们并不要求邮件必须%发送成功，失败了就失败了，只要监控告警的失败率不超过阈值即可。同时，消息服务一旦收到请求，应该自行保证消息的投递。

       因此，总的来说，使用MQ发送消息并自行处理，或者使用线程池进行异步处理，最后自行处理补偿逻辑，就能解决这类问题。

       那么，今天要介绍的是这两种解决方案之外的处理方式。对于这种场景，我们可以使用EventBus来解决。

       EventBus是事件总线的意思，它是Google Guava库的一个工具，基于观察者模式，可以在进程内实现代码的解耦。

       以上面的例子来说，引入MQ可能会有些过于复杂，其实使用EventBus也能达到相同的效果。与MQ相比，EventBus只能提供进程内的消息事件传递，但对于我们的业务场景来说，这已经足够了。

       接下来，我们来看一下EventBus的使用方法。首先，创建一个EventBus实例。

       第二步，创建一个事件消息订阅者，处理方式非常简单，只需在希望处理事件的方法上添加@Subscribe注解即可。

       形参只能有一个，如果定义0个或多个，运行时将会报错。

       第三步，注册事件。

       第四步，发送事件。

       这就是EventBus使用的最简单例子。下面我们看看如何结合开头的例子进行处理。

       比如上面提到的案例，比如注册和用户下单的场景，都需要发送消息和邮件给用户。

       EventBus并不强制要求我们使用单例模式，因为其创建和销毁成本较低，所以更多是根据我们的业务场景和上下文来选择。

       在业务逻辑处理完成后，分别注册了邮件和短信两个事件订阅者。

       最后，我们发送事件，用户注册时发送一个用户ID，下单成功时发送一个订单ID。

       然后写一个测试类进行测试，分别创建两个service，然后分别调用方法。

       执行测试类，我们可以看到输出，分别执行了事件订阅的方法。

       使用起来你会发现非常简单，对于希望轻量级简单地实现解耦，使用EventBus非常合适。

       注意，例子中的参数都是Long类型。如果事件的参数是其他类型，那么消息是无法接收到的。比如，如果我们将下单中发送的订单ID改为String类型，会发现没有消费。因为我们没有定义一个参数类型为String的方法。

       去EmailMsgHandler和SmsMsgHandler都新增一个接收String类型的订阅方法，这样就可以接收到了。

       除此之外，我们还可以定义一个DeadEvent来处理这种情况，它相当于是一个默认的处理方式。当没有匹配的事件类型参数时，就会默认发送一个DeadEvent事件。

       定义一个默认处理器。

       给BookingService新增一个pay()支付方法，下单完成后去支付，注册我们的默认事件。

       执行测试bookingService.pay()，看到输出结果：

       OK，简单的介绍就到这里。到目前为止，我们所说的都是同步调用，这并不符合我们的要求。我们当然希望使用异步处理更好。

       那就看看源码它是如何实现的。

       identifier是一个名字，标记，默认是default。

       executor是执行器，默认创建一个MoreExecutors.directExecutor()，事件订阅者根据你提供的executor来决定如何执行事件订阅的处理方式。

       exceptionHandler是异常处理器，默认创建的就是打点日志。

       subscribers是我们的消费者，订阅者。

       dispatcher用来做事件分发。

       默认创建的executor是一个MoreExecutors.directExecutor()，看到command.run()你就会发现这其实是同步执行。

       同步执行并不太好。我们希望不仅解耦，还要异步执行。EventBus提供了AsyncEventBus，我们可以自己传入executor。

       上面的代码我们改成异步的，这样不就好起来了嘛。实际上，我们可以结合自己的线程池来处理。

       OK，这个说清楚了。我们可以顺便再看看事件分发的处理。看到DeadEvent了吗？没有当前事件的订阅者，就会发送一个DeadEvent事件，bingo！

       OK，这个使用和源码都比较简单，有兴趣的同学可以自己去看看，花不了多少功夫。

       总的来说，EventBus提供了一个更优雅的代码解耦方式，你在实际工作中的业务中肯定能用得上它！