C10K 问题引发的技术变革

原创 2015年01月26日 14:30:34

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 类似),不需要内核参与,可以很方便的实现异步。

参考文献

  • http://www.ulduzsoft.com/2014/01/select-poll-epoll-practical-difference-for-system-architects/
转载请注明:http://blog.csdn.net/yeasy/article/details/43152115

聊聊C10K问题及解决方案

http://my.oschina.net/xianggao/blog/664275
  • wangtaomtk
  • wangtaomtk
  • 2016年07月02日 14:42
  • 6187

C10K问题

C10K问题 (2011-09-29 19:59) 分类: 网络 C10K问题:   网络服务在处理数以万计的客户端连接时,往往出现效率底下甚至完全瘫痪,这被成为C10...
  • JYSG9
  • JYSG9
  • 2012年08月23日 19:53
  • 11503

C10K、C100K, C1000K=C1M,C10M( concurrent 10M connections)....千万级并发实现的秘密:内核不是解决方案,而是问题所在!

参考资料:     The C10K problem:  http://www.kegel.com/c10k.html     C1M http://www.blogjava.net/yongboy/...
  • ajian005
  • ajian005
  • 2016年05月18日 16:28
  • 2345

C10K问题

是时候让 Web 服务器同时处理一万客户端了,你不觉得吗?毕竟,现在的 Web 是一个大地盘了。   并且,计算机也是一样的大。 你可以花 $1200 左右购买一台 1000MHz,2Gb RAM ...
  • zhoudaxia
  • zhoudaxia
  • 2013年11月17日 23:46
  • 2871

C10K问题

The C10K problem翻译 The C10K problem 如今的web服务器需要同时处理一万个以上的客户端了,难道不是吗?毕竟如今的网络是个big place了。 现...
  • typename
  • typename
  • 2010年05月16日 19:59
  • 7374

服务器并发量之突破C10K的问题

原文地址:http://www.cnblogs.com/fll/archive/2008/05/17/1201540.html 如今的web服务器需要同时处理一万个以上的客户端了...
  • longhumen1214
  • longhumen1214
  • 2013年06月03日 20:48
  • 1261

高性能网络编程(二):上一个10年,著名的C10K并发连接问题

1、前言 对于高性能即时通讯技术(或者说互联网编程)比较关注的开发者,对C10K问题(即单机1万个并发连接问题)应该都有所了解。“C10K”概念最早由Dan Kegel发布于其个人站点,即出自...
  • qq_26819733
  • qq_26819733
  • 2016年10月22日 10:01
  • 531

C10K问题

网络服务在处理数以万计的客户端连接时,往往出现效率底下甚至完全瘫痪,这被成为C10K问题。 (C10K = connection 10 kilo 问题)。k 表示 kilo,即 1000 比如:ki...
  • chenyefei
  • chenyefei
  • 2016年07月03日 10:20
  • 180

C10K问题

网络服务在处理数以 万计的客户端 连接时,往往出现效率底下甚至完全瘫痪,这被成为 C10K问题 。 select和poll在连接数增加时,性能急剧下降。这有两方面的原因: (1)操作系统面...
  • cui918
  • cui918
  • 2016年10月18日 17:28
  • 143

Apache的性能解读

MPM全称是多道处理模块,我们都知道apache是以模块化方式设计的.那么MPM用来决定apache如何处理用户请求的.是通过一个进程处理一个请求,还是一个线程处理一个请求.当前MPM有三种可以选择的...
  • u012486730
  • u012486730
  • 2017年08月29日 15:05
  • 121
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:C10K 问题引发的技术变革
举报原因:
原因补充:

(最多只允许输入30个字)