导航菜单
路很长,又很短
博主信息
昵   称:Cocodroid ->关于我
Q     Q:2531075716
博文数:308
阅读量:794843
访问量:73349
至今:
×
云标签 标签球>>
云标签 - Su的技术博客
博文->>首页 博主的更多博文>>
C10K问题

转载 C10K问题

Tags : 网络编程,C10K发表时间: 2019-01-12 13:50:09

C10K问题由来

随着互联网的普及,应用的用户群体几何倍增长,此时服务器性能问题就出现。最初的服务器是基于进程/线程模型。新到来一个TCP连接,就需要分配一个进程。假如有C10K,就需要创建1W个进程,可想而知单机是无法承受的。那么如何突破单机性能是高性能网络编程必须要面对的问题,进而这些局限和问题就统称为C10K问题,最早是由Dan Kegel进行归纳和总结的,并且他也系统的分析和提出解决方案。

C10K问题的本质

C10K问题的本质上是操作系统的问题。对于Web 1.0/2.0时代的操作系统,传统的同步阻塞I/O模型处理方式都是requests per second。当创建的进程或线程多了,数据拷贝频繁(缓存I/O、内核将数据拷贝到用户进程空间、阻塞,进程/线程上下文切换消耗大, 导致操作系统崩溃,这就是C10K问题的本质。

可见, 解决C10K问题的关键就是尽可能减少这些CPU资源消耗。

C10K问题的解决方案

从网络编程技术的角度来说,主要思路:

  1. 每个连接分配一个独立的线程/进程
  2. 同一个线程/进程同时处理多个连接

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

该思路最为直接,但是申请进程/线程是需要系统资源的,且系统需要管理这些进程/线程,所以会使资源占用过多,可扩展性差

每个进程/线程同时处理 多个连接(I/O多路复用)

  1. select方式:使用fd_set结构体告诉内核同时监控那些文件句柄,使用逐个排查方式去检查是否有文件句柄就绪或者超时。该方式有以下缺点:文件句柄数量是有上线的,逐个检查吞吐量低,每次调用都要重复初始化fd_set。
  2. poll方式:该方式主要解决了select方式的2个缺点,文件句柄上限问题(链表方式存储)以及重复初始化问题(不同字段标注关注事件和发生事件),但是逐个去检查文件句柄是否就绪的问题仍然没有解决。
  3. epoll方式:该方式可以说是C10K问题的killer,他不去轮询监听所有文件句柄是否已经就绪。epoll只对发生变化的文件句柄感兴趣。其工作机制是,使用"事件"的就绪通知方式,通过epoll_ctl注册文件描述符fd,一旦该fd就绪,内核就会采用类似callback的回调机制来激活该fd, epoll_wait便可以收到通知, 并通知应用程序。而且epoll使用一个文件描述符管理多个描述符,将用户进程的文件描述符的事件存放到内核的一个事件表中, 这样数据只需要从内核缓存空间拷贝一次到用户进程地址空间。而且epoll是通过内核与用户空间共享内存方式来实现事件就绪消息传递的,其效率非常高。但是epoll是依赖系统的(Linux)。
  4. 异步I/O以及Windows,该方式在windows上支持很好,这里就不具体介绍啦。

参考:

  1. 构建C1000K的服务器(1) – 基础
  2. 高性能网络编程(二):上一个10年,著名的C10K并发连接问题

作者:周小WA
链接:https://www.jianshu.com/p/ba7fa25d3590

打赏
打赏
关注公众号
公众号
类别:Java| 阅读(323)| 赞 (0)
评论
暂无评论!
发表评论
昵  称:

验证码:

内  容:

    同时赞一个 赞