专栏首页物流IT圈C10K 问题引发的技术变革

C10K 问题引发的技术变革

C10K 问题

服务器应用领域很古老很出名的一个问题,大意是说单台服务器要同时支持并发 10K 量级的连接,这些连接可能是保持存活状态的。

解决这一问题,主要思路有两个:一个是对于每个连接处理分配一个独立的进程/线程;另一个思路是用同一进程/线程来同时处理若干连接。

每个进程/线程处理一个连接

这一思路最为直接。但是由于申请进程/线程会占用相当可观的系统资源,同时对于多进程/线程的管理会对系统造成压力,因此这种方案不具备良好的可扩展性。

因此,这一思路在服务器资源还没有富裕到足够程度的时候,是不可行的;即便资源足够富裕,效率也不够高。

问题:资源占用过多,可扩展性差。

每个进程/线程同时处理多个连接

传统思路

最简单的方法是循环挨个处理各个连接,每个连接对应一个 socket,当所有 socket 都有数据的时候,这种方法是可行的。

但是当应用读取某个 socket 的文件数据不 ready 的时候,整个应用会阻塞在这里等待该文件句柄,即使别的文件句柄 ready,也无法往下处理。

思路:直接循环处理多个连接。

问题:任一文件句柄的不成功会阻塞住整个应用。

select

要解决上面阻塞的问题,思路很简单,如果我在读取文件句柄之前,先查下它的状态,ready 了就进行处理,不 ready 就不进行处理,这不就解决了这个问题了嘛?

于是有了 select 方案。用一个 fd_set 结构体来告诉内核同时监控多个文件句柄,当其中有文件句柄的状态发生指定变化(例如某句柄由不可用变为可用)或超时,则调用返回。之后应用可以使用 FD_ISSET 来逐个查看是哪个文件句柄的状态发生了变化。

这样做,小规模的连接问题不大,但当连接数很多(文件句柄个数很多)的时候,逐个检查状态就很慢了。因此,select 往往存在管理的句柄上限(FD_SETSIZE)。同时,在使用上,因为只有一个字段记录关注和发生事件,每次调用之前要重新初始化 fd_set 结构体。

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

思路:有连接请求抵达了再检查处理。

问题:句柄上限+重复初始化+逐个排查所有文件句柄状态效率不高。

poll

poll 主要解决 select 的前两个问题:通过一个 pollfd 数组向内核传递需要关注的事件消除文件句柄上限,同时使用不同字段分别标注关注事件和发生事件,来避免重复初始化。

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

思路:设计新的数据结构提供使用效率。

问题:逐个排查所有文件句柄状态效率不高。

epoll

既然逐个排查所有文件句柄状态效率不高,很自然的,如果调用返回的时候只给应用提供发生了状态变化(很可能是数据 ready)的文件句柄,进行排查的效率不就高多了么。

epoll 采用了这种设计,适用于大规模的应用场景。

实验表明,当文件句柄数目超过 10 之后,epoll 性能将优于 select 和 poll;当文件句柄数目达到 10K 的时候,epoll 已经超过 select 和 poll 两个数量级。

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

思路:只返回状态变化的文件句柄。

问题:依赖特定平台(Linux)。

libevent

跨平台,封装底层平台的调用,提供统一的 API,但底层在不同平台上自动选择合适的调用。

C10K 到 C10M

随着技术的演进,epoll 已经可以较好的处理 C10K 问题,但是如果要进一步的扩展,例如支持 10M 规模的并发连接,原有的技术就无能为力了。

那么,新的瓶颈在哪里呢?

从前面的演化过程中,我们可以看到,根本的思路是要高效的去阻塞,让 CPU 可以干核心的任务。

当连接很多时,首先需要大量的进程/线程来做事。同时系统中的应用进程/线程们可能大量的都处于 ready 状态,需要系统去不断的进行快速切换,而我们知道系统上下文的切换是有代价的。虽然现在 Linux 系统的调度算法已经设计的很高效了,但对于 10M 这样大规模的场景仍然力有不足。

所以我们面临的瓶颈有两个,一个是进程/线程作为处理单元还是太厚重了;另一个是系统调度的代价太高了。

很自然地,我们会想到,如果有一种更轻量级的进程/线程作为处理单元,而且它们的调度可以做到很快(最好不需要锁),那就完美了。

这样的技术现在在某些语言中已经有了一些实现,它们就是 coroutine(协程),或协作式例程。具体的,Python、Lua 语言中的 coroutine(协程)模型,Go 语言中的 goroutine(Go 程)模型,都是类似的一个概念。实际上,多种语言(甚至 C 语言)都可以实现类似的模型。

它们在实现上都是试图用一组少量的线程来实现多个任务,一旦某个任务阻塞,则可能用同一线程继续运行其他任务,避免大量上下文的切换。每个协程所独占的系统资源往往只有栈部分。而且,各个协程之间的切换,往往是用户通过代码来显式指定的(跟各种 callback 类似),不需要内核参与,可以很方便的实现异步。

本文分享自微信公众号 - 物流IT圈(exiter18)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-10-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 原来好产品经理每天工作的时间是这样分配的

    要想成为一名优秀的产品经理,需要了解一些具像的问题。不如,先从了解产品经理的一天开始。通过了解产品经理的日常工作,或许可以解决以下问题。

    物流IT圈
  • 运费模板的设计元素与逻辑

    运费模板的设计在页面内设计元素较少且较为简单,但是在实际规则的使用需求中较为复杂。

    物流IT圈
  • 传统SpringMVC到Springboot迁移之路

    最近在把公司的老项目迁移到springboot,遇到了很多坑,包括jar包的升级,代码重构,以及全方位的测试。具体过程参照了简书上的一篇文章。

    物流IT圈
  • 逆向对抗技术之ring3解除文件句柄,删除文件

    这些问题主要是工作中会遇到.包括后面的逆向对抗技术.有的可能只会提供思路.并且做相应的解决与对抗.

    IBinary
  • HANDLE

        HANDLE:句柄,是Windows用来表示对象的(不是C++的对象),HWND是其中一种,HWND是HANDLE,但HANDLE不只是HWND,更具体...

    猿人谷
  • 操作系统实验一资料归纳

    指导书上出现了一个陌生的名词“句柄(handle)”,感觉比较奇妙,因为在之前编写微信公众号小程序看教程也编写了一个handle程序。所以留档一下吧。

    Ewdager
  • 句柄的真正理解

    **真理一句话:句柄是引用,而不是指针。只能改变对应对象的内容,但不知道对象在哪。 **

    逐梦的青春
  • Linux下查看进程打开的文件句柄数

    在 Linux 平台上运行的进程都会从系统资源申请一定数量的句柄,而且系统控制了进程能够申请的最大句柄数量。用户程序如果不及时释放无用的句柄,将会引起句柄泄露,...

    九州暮云
  • win32进程概念之句柄表,以及内核对象.

    我们知道.我们使用CreateProcess 的时候会返回一个进程句柄.以及线程句柄. 其实在调用CreateProcess的时候.内核中会新建一个EPROCE...

    用户3128588
  • win32进程概念之句柄表,以及内核对象.

    我们知道.我们使用CreateProcess 的时候会返回一个进程句柄.以及线程句柄. 其实在调用CreateProcess的时候.内核中会新建一个EPROCE...

    IBinary

扫码关注云+社区

领取腾讯云代金券