资讯专栏INFORMATION COLUMN

物联网高并发编程之C10K问题原理和解决方案

dayday_up / 2923人阅读

摘要:问题任一文件句柄的不成功会阻塞住整个应用。主要解决的前两个问题通过一个数组向内核传递需要关注的事件消除文件句柄上限,同时使用不同字段分别标注关注事件和发生事件,来避免重复初始化。问题逐个排查所有文件句柄状态效率不高。

C10K问题思维导图

C10K问题出现前期

大家都知道互联网的基础就是网络通信,早期的互联网可以说是一个小群体的集合。

互联网还不够普及,用户也不多。一台服务器同时在线100个用户估计在当时已经算是大型应用了。所以并不存在什么C10K的难题。互联网的爆发期应该是在www网站,浏览器,雅虎出现后。最早的互联网称之为Web1.0,互联网大部分的使用场景是下载一个Html页面,用户在浏览器中查看网页上的信息。这个时期也不存在C10K问题。

Web2.0时代到来后就不同了,一方面是普及率大大提高了,用户群体几何倍增长。另一方面是互联网不再是单纯的浏览万维网网页,逐渐开始进行交互,而且应用程序的逻辑也变的更复杂,从简单的表单提交,到即时通信和在线实时互动。

C10K的问题才体现出来了。每一个用户都必须与服务器保持TCP连接才能进行实时的数据交互。

Facebook这样的网站同一时间的并发TCP连接可能会过亿。

腾讯QQ也是有C10K问题的,只不过他们是用了UDP这种原始的包交换协议来实现的,绕开了这个难题。当然过程肯定是痛苦的。如果当时有epoll技术,他们肯定会用TCP。后来的手机QQ,微信都采用TCP协议。
C10K问题出现和本质

这时候问题就来了,最初的服务器都是基于进程/线程模型的,新到来一个TCP连接,就需要分配1个进程(或者线程)。

而进程又是操作系统最昂贵的资源,一台机器无法创建很多进程。

如果是C10K就要创建1万个进程,那么操作系统是无法承受的。

如果是采用分布式系统,维持1亿用户在线需要10万台服务器,成本巨大,也只有Facebook,Google,雅虎才有财力购买如此多的服务器。这就是C10K问题的本质。

实际上当时也有异步模式,如:select/poll模型,这些技术都有一定的缺点,如selelct最大不能超过1024,poll没有限制,但每次收到数据需要遍历每一个连接查看哪个连接有数据请求。
C10K解决方案C10K解决方案

解决这一问题,主要思路有两个:

一个是对于每个连接处理分配一个独立的进程/线程;

另一个思路是用同一进程/线程来同时处理若干连接。

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

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

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

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

每个进程/线程同时处理多个连接(IO多路复用) 传统思路

最简单的方法是循环挨个处理各个连接,每个连接对应一个 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)。

因为Linux是互联网企业中使用率最高的操作系统,Epoll就成为C10K killer、高并发、高性能、异步非阻塞这些技术的代名词了。

这些操作系统提供的功能就是为了解决C10K问题:

FreeBSD推出了kqueue,

Linux推出了epoll

Windows推出了IOCP,

Solaris推出了/dev/poll。

这些操作系统提供的功能就是为了解决C10K问题。

epoll技术的编程模型就是异步非阻塞回调,也可以叫做Reactor,事件驱动,事件轮循(EventLoop)。Nginx,libevent,node.js这些就是Epoll时代的产物。

select、poll、epoll具体原理详解,

libevent

由于epoll, kqueue, IOCP每个接口都有自己的特点,程序移植非常困难,于是需要对这些接口进行封装,以让它们易于使用和移植,其中libevent库就是其中之一。

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

按照libevent的官方网站,libevent库提供了以下功能:

当一个文件描述符的特定事件(如可读,可写或出错)发生了,或一个定时事件发生了,libevent就会自动执行用户指定的回调函数,来处理事件。

目前,libevent已支持以下接口/dev/poll, kqueue, event ports, select, poll 和 epoll。

Libevent的内部事件机制完全是基于所使用的接口的。因此libevent非常容易移植,也使它的扩展性非常容易。

目前,libevent已在以下操作系统中编译通过:Linux,BSD,Mac OS X,Solaris和Windows。

使用libevent库进行开发非常简单,也很容易在各种unix平台上移植。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/72525.html

相关文章

  • 联网并发编程单台服务器最大并发TCP连接数

    摘要:对端,通过增加内存修改最大文件描述符个数等参数,单机最大并发连接数超过万甚至上百万是没问题的,国外公司在产品环境中已做到万并发 [TOC] 前言 曾几何时我们还在寻求网络编程中C10K问题的解决方案,但是现在从硬件和操作系统支持来看单台服务器支持上万并发连接已经没有多少挑战性了。 我们先假设单台服务器最多只能支持万级并发连接,其实对绝大多数应用来说已经远远足够了,但是对于一些拥有很大用...

    leap_frog 评论0 收藏0
  • 联网并发编程网络编程中的线程模型

    摘要:如需了解更多物联网网络编程知识请点击物联网云端开发武器库物联网高并发编程之网络编程中的线程模型值得说明的是,具体选择线程还是进程,更多是与平台及编程语言相关。 如需了解更多物联网网络编程知识请点击:物联网云端开发武器库 物联网高并发编程之网络编程中的线程模型 值得说明的是,具体选择线程还是进程,更多是与平台及编程语言相关。例如 C 语言使用线程和进程都可以(例如 Nginx 使用进程...

    ziwenxie 评论0 收藏0
  • 联网并发编程网络编程中的I/O模型

    摘要:缺点每个连接需要独立的进程线程单独处理,当并发请求量大时为了维护程序,内存线程切换开销较大,这种模型在实际生产中很少使用。而在系统下,才引入,目前并不完善,因此在下实现高并发网络编程时都是以复用模型模式为主。 思维导图 showImg(https://segmentfault.com/img/bVbkrNz?w=1766&h=994); 互联网服务端处理网络请求的原理 首先看看一个典型...

    hsluoyz 评论0 收藏0
  • nginx、swoole并发原理初探

    摘要:一阅前热身为了更加形象的说明同步异步阻塞非阻塞,我们以小明去买奶茶为例。等奶茶做好了,店员喊一声小明,奶茶好了,然后小明去取奶茶。将响应结果发给相应的连接请求处理完成因为基于,所以每个可以处理无数个连接请求。如此,就轻松的处理了高并发。 一、阅前热身 为了更加形象的说明同步异步、阻塞非阻塞,我们以小明去买奶茶为例。 1、同步与异步 ①同步与异步的理解 同步与异步的重点在消息通知的方式上...

    617035918 评论0 收藏0
  • nginx、swoole并发原理初探

    摘要:一阅前热身为了更加形象的说明同步异步阻塞非阻塞,我们以小明去买奶茶为例。等奶茶做好了,店员喊一声小明,奶茶好了,然后小明去取奶茶。将响应结果发给相应的连接请求处理完成因为基于,所以每个可以处理无数个连接请求。如此,就轻松的处理了高并发。 一、阅前热身 为了更加形象的说明同步异步、阻塞非阻塞,我们以小明去买奶茶为例。 1、同步与异步 ①同步与异步的理解 同步与异步的重点在消息通知的方式上...

    denson 评论0 收藏0

发表评论

0条评论

dayday_up

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<