• Reactor模型详解:单Reactor多线程与主从Reactor多线程


    单Reactor多线程

    网络模型图:

    图片来源:https://blog.csdn.net/weixin_43326401/article/details/104202424

    消息处理流程:

    1. Reactor对象通过epoll监控连接事件,收到事件后通过回调函数进行转发。
    2. 如果是连接建立的事件,则由acceptor接受连接,并创建handler处理后续事件。
    3. 如果不是建立连接事件,如read事件,则Reactor会分发调用Handler来响应。
    4. handler会完成read->业务处理->send的完整业务流程。

    单Reactor单线程模型只是在代码上进行了组件的区分,但是整体操作还是单线程,不能充分利用硬件资源。handler业务处理部分没有异步。

    对于一些小容量应用场景,可以使用单Reactor单线程模型。但是对于高负载、大并发的应用场景却不合适,主要原因如下:

    1. 即便Reactor线程的CPU负荷达到100%,也无法满足海量消息的编码、解码、读取和发送。
    2. 当Reactor线程负载过重之后,处理速度将变慢,这会导致大量客户端连接超时,超时之后往往会进行重发,这更加重Reactor线程的负载,最终会导致大量消息积压和处理超时,成为系统的性能瓶颈。
    3. 一旦Reactor线程意外中断或者进入死循环,会导致整个系统通信模块不可用,不能接收和处理外部消息,造成节点故障。

    为了解决这些问题,演进出单Reactor多线程模型。

    主 - 从Reactor多线程

    主 - 从 reactor 模式

    下面的这张图描述了主 - 从 reactor 模式是如何工作的。
    主 - 从这个模式的核心思想是,主反应堆线程只负责分发 Acceptor 连接建立,已连接套接字上的 I/O 事件交给 sub-reactor 负责分发。其中 sub-reactor 的数量,可以根据 CPU 的核数来灵活设置。
    比如一个四核 CPU,我们可以设置 sub-reactor 为 4。相当于有 4 个身手不凡的反应堆线程同时在工作,这大大增强了 I/O 分发处理的效率。而且,同一个套接字事件分发只会出现在一个反应堆线程中,这会大大减少并发处理的锁开销。
     

    主反应堆线程一直在感知连接建立的事件,如果有连接成功建立,主反应堆线程通过 accept 方法获取已连接套接字,接下来会按照一定的算法选取一个从反应堆线程,并把已连接套接字加入到选择好的从反应堆线程中。
    主反应堆线程唯一的工作,就是调用 accept 获取已连接套接字,以及将已连接套接字加入到从反应堆线程中。不过,这里还有一个小问题,主反应堆线程和从反应堆线程,是两个不同的线程,如何把已连接套接字加入到另外一个线程中呢?更令人沮丧的是,此时从反应堆线程或许处于事件分发的无限循环之中,在这种情况下应该怎么办呢?

    推出主 - 从Reactor多线程

    如果说主 - 从 reactor 模式解决了 I/O 分发的高效率问题,那么 work threads 就解决了业务逻辑和 I/O 分发之间的耦合问题。把这两个策略组装在一起,就是实战中普遍采用的模式。大名鼎鼎的 Netty,就是把这种模式发挥到极致的一种实现。

  • 相关阅读:
    函数表达式
    BOM
    让超出容器高度的内容滚动显示但不出现滚动条
    插件书写示例
    php中redis的安装
    日常工作bug总结
    pip freeze requirements.txt命令迁移模块
    Django18-中间件和cache实现限制用户访问频率
    Django17-文件上传下载
    Django16-cache缓存
  • 原文地址:https://www.cnblogs.com/-wenli/p/13343397.html
Copyright © 2020-2023  润新知