C++ Workflow 异步调度框架 - 性能优化网络篇

最近在努力同步维护 InfoQ 的文章积累～方便后续持续更新～原文 2022 年 3 月追更的一篇。

希望自己和项目都可以持续进步 (๑╹ヮ╹๑)ﾉ 欢迎多多交流！！

时隔(鸽)一年半，Workflow 架构系列又回来惹～虽然搁笔许久，但我们项目几乎每天都在更新代码！

GitHub 是主战场，欢迎大家在 github 关注一手信息，这段时间的海量功能更新，都在散落在文档、issue、以及我后来的其他文章和回答中了。

过去一年的提交动态！真的！没有！偷懒！👇

今天整的活，是被催更最多的，Workflow 中最重要的优化——网络。

通信器可以说是 Workflow 的前身，是我老大从自研分布式存储模块中演化出来的，并且由于老大很少看其他项目的做法，因此个人感觉其中有许多创新点值得分享，如果大家看腻了千篇一律的做法，也许这里可以和你产生一些思维的碰撞。因此本篇欢迎大家讨论、交流，以及指出执笔的我写得不对的地方～

P.S. 这个系列是我在 2020 年 7 月刚开源时积累的一些鶸鶸的思路，免得一些后来认识的开发者不太了解，这里附上一些鶸鶸的链接：

C++ Workflow异步调度框架 - 基本介绍篇

C++ Workflow异步调度框架 - 架构设计篇

C++ Workflow异步调度框架 - 性能优化上篇

然后我们从底向上，开始今天的话题——网络优化。

项目地址 GitHub👉 https://github.com/sogou/workflow

项目地址 Gitee👉 https://gitee.com/sogou/workflow

一、和事件循环不一样的全新玩法

有趣的新东西放第一部分说：Workflow 使用 epoll 的方式有什么不同？

答案是线程模型。

我们常用 epoll 提供的三个接口：create、ctl、wait。连接多了的时候，异步要做的就是用尽可能少的线程去管理 fd，以节省创建销毁线程的 overhead 以及线程所占用的内存和对资源的争抢。

所以高性能网络框架，都要管理着自己的多个线程（或者 nginx 的多进程）对 epoll 进行操作，并对上层提供原子性的语义。

好，我们现在给 n 个网络线程去操作 epoll，全局这么多 fd 怎么分配和管理呢？

我们以前都见过的通用的做法是事件循环，用 one loop per thread 的方式进行分配和管理的。

以下我描述一下我弱弱的几点理解：

1. 如果是 server，是被动方，那么要做好 accept 工作

2. 如果是 client，是主动方，那么要做好 connect 工作

3. 这些都是要从全局的角度来分发 fd

4. 然后按照这 n 个线程当前的负载量分发给一个人，这个人来全面负责这个 fd 的：吃（增）喝（删）拉（改）撒（等）

orkflow 的方式不一样：

1. 分发部分我们先简单地对 fd 进行 n 取模，毕竟建立连接大家也是异步做的呀，连接的响应已经可以交给网络线程去做了

2. 然后这个网络线程就继续做等待这个被分配的 fd 以及响应它的所有事件

3. 并且，敲黑板～，如果一个线程在 epoll_wait，另一个线程向 epoll 里添加，删除或修改 fd 这在 Workflow 里都是常规操作，因为 epoll、kqueue 都是支持这个特征的

所以看到这里边最大的区别是什么了吗？

事件循环是通过 eventfd 或者其他方式打断 epoll_wait 来添加 fd。显然，这个做法在很多场景下其实对性能是有影响的。

如果对一个的操作有变动，Workflow 怎么做呢？我们会通过一个 pipe 事件通知这个 poller thread。

举个例子。如果要删除一个 fd，那么如果别人把 fd 从 epoll 删除，删除之后就没有契机告诉该 poller thread 去做它要做的事情（最典型的，比如，删掉对应的上下文或者调用钩子等）。所以要借助 pipe 事件来通知“删除”这件小事儿，而这个等这个 poller thread 下次有正事儿要做的时候，再一并处理就完了，无需现在叫醒它就为了干点小事儿。

好奇宝宝你可能会问：fd 直接取模难道不会不均匀吗？

这里有个很重要的设计上的优化理念。

Workflow 从来不做空跑 QPS 之王，Workflow 做的是一个跑得又快又稳的通用企业级框架，所以贯穿整个项目一个设计理念就是面向全局优化：

即，比起尽可能优化一个请求得到最优性能，我们更倾向于优化整体的请求得到最优性能。

如果系统本身很忙，那么其实连进来的大部分 fd 都会比较繁忙，因此暂时还不需要去做分发，取模就够用了。毕竟每个优化步骤都是有点小开销，到底优化谁，这是个非常 compromise 的事情。

这个优化思路后面还会持续看到～

虽然这种线程模型的新做法，不一定会成为 Workflow 高性能的最决定性因素，但却是我个人觉得最值得分享的新思路，可以让我们这些暂时还没有把底层吃透、没办法上来就创新的入门开发者，也看看业内现在有了不一样的眼前一亮的有趣方案，也让我们可以不要那么浮躁，不要为了快速出成绩浪费了自己的思考机会，而应该大胆设计，小心实现。

二、比 proactor 走得更远：消息的语义设计

上一部分讲的，除了封装多线程以外，网络库还要提供我们所设计的接口。

而 Workflow 的另一个不同点在于，它不是网络库，而是从网络模块到上层具体协议、任务流都有的成型框架。所以提供的接口语义并不是 proactor、reactor，Workflow 的语义是以消息为单位的。

为了简单起见，这里以收消息为例：

• Reactor 是有事件来了，我告诉你，你负责去读出来；（epoll 所提供的功能）

• Proactor 是你给我一片内存，我把数据读出来了之后告诉你，一次通信的消息可能你是要读好几次才能读完的；（iocp，以及很多网络库的做法）

• Workflow 是别管事件来了和读多少几次，我会帮你把你要的完整消息都收好了，再叫你；（也就是上层的每一个任务）

这显然更加符合人类的自然思维，接口的简洁和易用也是我们对 Workflow 一直以来的坚持。

我们依然从底向上，看看一个消息长什么样：

1.pollet_message_t

struct __poller_message poller_message_t;
struct __poller_message{       int (*append)(const void *, size_t *, poller_message_t *);    char data[0];};

最底层很简单，一个钩子，以及一片内存。

2.CommMessageIn

class CommMessageIn : private poller_message_t{private:    virtual int append(const void *buf, size_t *size) = 0;    …

这个派生类是收到的消息，增加了一个 append 接口：数据来了上层可以拿走，并通过 ret 告诉底层核心之后的状态。这里的 size 是个双向参数，你甚至可以告诉我你现在要拿走到哪里，剩下的我帮你接管、下次再给你。

其中：

• ret 返回 1 表示消息收完；

• ret 返回 0 表示还没收完；

• ret<0 表示消息错误。

正是这个返回值让底层核心知道如何切出一份完整的消息。

3.CommMessageOut

class CommMessageOut{private:    virtual int encode(struct iovec vectors[], int max) = 0;    …

发送接口也很简单。

到此就是核心通信器所做能看到的消息接口。但作为一个成熟的框架，我们认为还远远不够方便，因此消息的语义我们继续往下看：

ProtocolMessage 会从 CommMessageIn 和 CommMessageOut 派生，因为对于 server 来说，in 就是 request，out 就是 response，而对于 client 来说，out 就是 request，in 就是 response，我们会需要收发两种功能。

class ProtocolMessage : public CommMessageOut, public CommMessageIn;

而消息收完了没有，是由协议开发者来做的：具体协议需要派生 ProtocolMessage 来实现刚才说的append和encode接口。因此 Workflow 的 Http、Redis、MySQL、Kafka、DNS 等协议都是自己手写解析的，这样才能真正做纯异步、收发不受原生模块的线程模型影响，这也是性能足够快的关键点之一。

Workflow 的很多用户是在用作异步 MySQL 客户端，虽然我们认为 MySQL 性能瓶颈应该在 server 才对，但是只要想提升并发，原生 client 就会捉襟见肘，而且随着目前 MySQL 协议各集群的崛起，Workflow 伪装成 MySQL client 的时候，对方也常常并不是原生 MySQL server，而是 tidb 之类的其他集群版伪装者（开源世界就是如此有意思～

三、特殊的异步写实现

如果你是后端开发，你就会有同感，我们处理的绝大部分 tcp 请求场景其实都是一来一回的，这是 Workflow 最擅长的领域，以至于在这在场景下，Workflow 又出现了一个新思路：高效的异步写实现。

我们知道 fd 天生是可以同时监听 EPOLLOUT 和 EPOLLIN 的，如果这样做，我们的网络库可以在有事件处理的时候，既看看是不是要读、又看看是不是要写，这些都在这次 loop 被叫醒的一次中做。

因此 Workflow 无论是 client 或者 server，fd 长期都保持 EPOLLIN 状态。需要写数据时，先同步的写，如果数据可以全部写入 tcp buffer，则无需改变 fd 的状态；如果数据无法全部写入，通过 epoll 的 MOD，原子性的把 fd 从 EPOLLIN 状态改为 EPOLLOUT 状态开始异步发送。异步发送完成（fd 会从 epoll 里删除），再把 fd 以 EPOLLOUT 状态重新加入 epoll。

而且为了性能考虑，我们的 poller_node 是一个以 fd 为下标的数组，而每个 node 只能关注一种事件，READ 或 WRITE。然后我们会通过 operation 来判断调用哪个处理函数（而非用 event 来判断）。

这种做法实现出来的通信器，其实比任何全双工都要快。

因为大多数情况下，没有必要进行异步写。操作系统会动态调整 TCP send buffer 的大小，从 100 多 K 逐渐增加至少 10M。需要异步写的场景很少，所以 epoll 里的 fd 基本不用动不会有额外开销。如果真的需要异步写，基于一来一回的模式下这个 fd 只写的模式那也是炒鸡快的。

四、超时处理是一门学问

超时难不难？超～难。

难在哪里呢？我个人理解是难在于精确地响应、高效的管理、和严格的原子性。

我们先看看精确地响应。

首先要基于一个足够精确的机制，所以我们用了 linux 的 timerfd（kqueue 的话用了 timer 事件，没错依然辣么统一～）。每一个负责操作 poller 的线程，都有一个 timerfd 去负责当前该线程所有在监听的 fd 的超时事件。

这就够精确了吗？那可太天真了，毕竟网络那么多步骤，而且我们不希望用户每个请求都去关心 connect、request、response 这么多阶段。

那怎么办呢？我们先对超时提出了几个阶段，最底层是全局给几个配置：

• connect_timeout: 与目标建立连接的超时。

• receive_timeout: 接收一条完整请求的超时。

• response_timeout: 等待目标响应的超时。代表成功发送到目标、或从目标读取到一块数据的超时。

这个每读一块数据的超时值得注意，在实际网络链路不好的情况下需要阶段划分出来，否则会很惨烈（相信我我是过来人

再往上一层，我们开发者还需要对连接层有超时管理的权利：

• keep_alive_timeout: 连接保持时间。默认 1 分钟。redis server 为 5 分钟。

再往上，每一个任务。

如果连接已经达到上限，默认的情况下，client 任务就会失败返回。但是我们允许通过任务上的一个超时值，来配置同步等待的时间。如果在这段时间内，有连接被释放，则任务可以占用这个连接：

• wait_timeout: 全局唯一一个同步等待超时。

再往上？那就不是框架需要管的事情了，熟悉 Workflow 框架的开发者应该知道，我们提供了 timer_task 与任务流，所以我们可以用 timer_task 和我们的业务逻辑的 task 一起随意搭配组装使用～让你写代码都能感受到拼乐高的乐趣～～

以上的架构设计，足以满足我们对网络请求中精确的超时控制。

我们再看看高效的管理。

目前的超时算法利用了链表+红黑树的数据结构，时间复杂度在 O(1)和 O(logn)之间，其中 n 为 poller 线程的 fd 数量。

超时处理目前看不是瓶颈所在，因为 Linux 内核 epoll 相关调用也是 O(logn)时间复杂度，我们把超时都做到 O(1)也区别不大。

最后，严格的原子性，设计我们配合第五部分的代码一起感受一下。另外涉及到 Communicator 的状态转换，所以就需要放到单独的代码解析中了（并不是这篇文章写到这里写累了._.

五、循环部分的代码讲解

我们把 src/kernel/poller.c 中，一个网络线程所执行的核心函数拿出来一行一行解读：

static void *__poller_thread_routine(void *arg) // 线程函数入口{    poller_t *poller = (poller_t *)arg;    __poller_event_t events[POLLER_EVENTS_MAX]; // 刚才提到的以fd为下标的超级快的poller_node数组    struct __poller_node time_node;    struct __poller_node *node;    ...
    while (1)    {        __poller_set_timer(poller);   // 继续开始等待之前，需要更新本轮要等的下一个超时时间，就是这里设置的timerfd        nevents = __poller_wait(events, POLLER_EVENTS_MAX, poller); // 2000 years later ...        clock_gettime(CLOCK_MONOTONIC, &time_node.timeout);        has_pipe_event = 0;        for (i = 0; i < nevents; i++) // 对于每个本线程要处理的已经ready的事件        {            node = (struct __poller_node *)__poller_event_data(&events[i]);            if (node > (struct __poller_node *)1)            {                switch (node->data.operation) // 一个正在监听的node（一个会话、或文件读写操作等）只会有一种状态                {                case PD_OP_READ:                    __poller_handle_read(node, poller);                    break;                case PD_OP_WRITE:                    __poller_handle_write(node, poller);                    break;                ... // 还有很多其他异步操作，比如连接也是异步的，以及ssl的复杂操作。建议大家先看nossl分支学习            }            else if (node == (struct __poller_node *)1)                has_pipe_event = 1; // 我们使用了node==1标记pipe事件，毕竟fd为1不可能是合法地址，用之～        }
        if (has_pipe_event) // 这里说明本轮有pipe事件，pipe用来通知各种fd的删除和poller的停止        {            if (__poller_handle_pipe(poller))                break;        }
        __poller_handle_timeout(&time_node, poller); // 处理超时事件，如上所述从红黑树和链表里把所有超时的节点都处理掉    }    ...}

六、还有什么 Workflow 目前不做

本质上，workflow 优化的主要方向都是：通用地用尽量少的系统资源，去做尽可能多的事情。

所以，Workflow 的通信器是全世界最快的通信器吗？

很显然不是。

Workflow 只是一个够快够稳够简单好用的、并且携带很多新思路的企业级框架，而且其异步特点在于可以做到调度无损耗。

这个得益于很多方面，上述这些折中的选择其实非常重要，另外还得益于架构层面的：

• 对资源的一视同仁、

• 接口设计的对称性、

• 任务流的编程范式

等等。并且，刚才有提到，Workflow 做的优化决策，都是面向全局的，这样的例子还有很多。

许多高性能优化方向，Workflow 目前没有用到，并不是东西不好，而是很多时候目前还没有必要，或者通过实际测试得出对比数据，发现必要性没有想象中的高，又或者优化思路不太通用。

包括以下这些：

1. 消息收回来，可以不切一次线程。

2. 但 Workflow 目前都会切，并过一次消息队列（某些空跑场景下显然不切会更好，但 Workflow 还是走实用路线～

3. workstealing 队列

4. 很多调度系统包括 go 内核都在使用，但 Workflow 的队列依然只是一个简单的队列，我原先有写过多种简单队列的对比，目前用的双队列模式，是简单队列里实测最快的！

5. 其他无锁技术，

6. 以及有人会使用 eventfd 去替代 cond，或者对 cond 进行 cacheline 优化（这也是一个很有趣的方向，但前两者我还没尝试。后者实践过，cacheline 优化听上去很美丽，但简单场景下没有测出实际的性能提升🤔

7. cpu 亲和性相关的优化

8. 在服务器已经够繁忙的时候。这个优化并不是那么有必要，但后续有空我会去学习一下～

9. 各种用户态的优化

10. 用户态协程、用户态协议栈~~~

11. 各种内核态的优化

12. 比如早就出来十几年、最近突然又火了的技能树 eBPF

七、最后

希望这篇优化，除了新的 epoll 使用方式、新的异步写方式等新思路以外，更多地是分享一些做事情的方法。

一方面，我们在做优化的时候，既要保持对新技术的好奇心，又不能对新技术趋之若鹜。有些花里胡哨的做法听上去超级棒，实际上真的有用吗？很多时候，操作系统已经帮你做得很好的事情，就不要自我感动拍脑袋去做好吗。

但另一方面，反过来说，又需要保持足够的自我思考，多琢磨多看看新思路新做法，从而提升自己的思路，去创造出更多有价值的精品，从做题家进化为代码艺术家。

其实本来这次还想写写连接管理，毕竟也做了很多事情，但是真的写不完了╥﹏╥好不容易提笔，我必须！现在！立刻！马上！把这篇文章发出！！！因此连接管理和其他的控制逻辑，我会放到下一篇～(# /ω＼#)

主页上有吞吐和长尾的优秀的 Benchmark，欢迎大家到点击[阅读原文]到主页围观，另外附上 GitHub 上项目主作者对某个 issue 中一个问题的用心回答截图：

图长警告⚠️这只是对一个问题的回答，截四段是因为回答太长👇

我们小团队真的是做用心血去开发与推进这个项目，Workflow 的发展虽然与 kpi 无关，但至少和我的个人技术信仰有关～希望大家可以喜欢我积累的新思路，以及不嫌弃我一丢丢啰嗦的心得体会。

并且！在等不到我的文章的时候，乃们可以去 issue 找主作者答疑解惑嘤嘤嘤～

GitHub - sogou/workflow: C++ Parallel Computing and Asynchronous Networking Engine