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

时隔(鸽)一年半，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的：吃（增）喝（删）拉（改）撒（等）

而Workflow的形式不一样：

  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. 音讯发出来，能够不切一次线程。
    但Workflow目前都会切，并过一次音讯队列（某些空跑场景下显然不切会更好，但Workflow还是走实用路线～
  2. workstealing队列
    很多调度零碎包含go内核都在应用，但Workflow的队列仍然只是一个简略的队列，我原先有写过多种简略队列的比照，目前用的双队列模式，是简略队列里实测最快的！
  3. 其余无锁技术，
    以及有人会应用eventfd去代替cond，或者对cond进行cacheline优化（这也是一个很乏味的方向，但前两者我还没尝试。后者实际过，cacheline优化听下来很漂亮，但简略场景下没有测出理论的性能晋升
  4. cpu亲和性相干的优化
    在服务器曾经够忙碌的时候。这个优化并不是那么有必要，但后续有空我会去学习一下～
  5. 各种用户态的优化
    用户态协程、用户态协定栈~~~
  6. 各种内核态的优化
    比方早就进去十几年、最近忽然又火了的技能树eBPF

七、最初

心愿这篇优化，除了新的epoll应用形式、新的异步写形式等新思路以外，更多地是分享一些做事件的办法。

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

但另一方面，反过来说，又须要保持足够的自我思考，多推敲多看看新思路新做法，从而晋升本人的思路，去发明出更多有价值的精品，从做题家进化为代码艺术家。

其实原本这次还想写写连贯治理，毕竟也做了很多事件，然而真的写不完了╥﹏╥好不容易提笔，我必须！当初！立即！马上！把这篇文章收回！！！因而连贯治理和其余的管制逻辑，我会放到下一篇～(# /＼#)

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

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

咱们小团队真的是做用心血去开发与推动这个我的项目，Workflow的倒退尽管与kpi无关，但至多和我的集体技术信奉无关～心愿大家能够喜爱我积攒的新思路，以及不厌弃我一丢丢啰嗦的心得体会。
并且！在等不到我的文章的时候，乃们能够去issue找主作者答疑解惑嘤嘤嘤～

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

七、最初

心愿这篇优化，除了新的epoll应用形式、新的异步写形式等新思路以外，更多地是分享一些做事件的办法。

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

但另一方面，反过来说，又须要保持足够的自我思考，多推敲多看看新思路新做法，从而晋升本人的思路，去发明出更多有价值的精品，从做题家进化为代码艺术家。

其实原本这次还想写写连贯治理，毕竟也做了很多事件，然而真的写不完了╥﹏╥好不容易提笔，我必须！当初！立即！马上！把这篇文章收回！！！因而连贯治理和其余的管制逻辑，我会放到下一篇～(# /＼#)

主页上有吞吐和长尾的benchmark，欢送大家到主页围观，另外附上GitHub上我的项目主作者对某个issue中一个问题的用心答复截图：

咱们小团队真的是做用心血去开发与推动这个我的项目，Workflow的倒退尽管与kpi无关，但至多和我的集体技术信奉无关～心愿大家能够喜爱我积攒的新思路，以及不厌弃我一丢丢啰嗦的心得体会。

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

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