C10K问题

Posted 2020-10-24

C10K问题

(@tigerfive)[学习笔记][c10k]

前言

今天在看nginx性能优化的时候，突然看到的C10K，就随手度娘一波，看到了这个标题<<程序员怎么会不知道 C10K 问题呢？>>,吓的我赶紧了解了一波什么是C10K。对于高性能即时通讯技术（或者说互联网编程）比较关注的开发者，对C10K问题（即单机1万个并发连接问题）应该都有所了解。“C10K”概念最早由Dan Kegel发布于其个人站点，即出自其经典的高性能网络编程经典：《The C10K problem(英文)；

C10K问题的由来

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

  Web2.0时代到来后就不同了，一方面是普及率大大提高了，用户群体几何倍增长。另一方面是互联网不再是单纯的浏览万维网网页，逐渐开始进行交互，而且应用程序的逻辑也变的更复杂，从简单的表单提交，到即时通信和在线实时互动，C10K的问题才体现出来了。因为每一个用户都必须与服务器保持TCP连接才能进行实时的数据交互，诸如Facebook这样的网站同一时间的并发TCP连接很可能已经过亿。

  这时候问题就来了，最初的服务器都是基于进程/线程模型的，新到来一个TCP连接，就需要分配1个进程（或者线程）。而进程又是操作系统最昂贵的资源，一台机器无法创建很多进程。如果是C10K就要创建1万个进程，那么单机而言操作系统是无法承受的（往往出现效率低下甚至完全瘫痪）。如果是采用分布式系统，维持1亿用户在线需要10万台服务器，成本巨大，也只有Facebook、Google、雅虎等巨头才有财力购买如此多的服务器。

  基于上述考虑，如何突破单机性能局限，是高性能网络编程所必须要直面的问题。这些局限和问题最早被Dan Kegel 进行了归纳和总结，并首次成系统地分析和提出解决方案，后来这种普遍的网络现象和技术局限都被大家称为 C10K 问题。

  简单来说，C10K 就是 Client 10000 问题，即「在同时连接到服务器的客户端数量超过 10000 个的环境中，即便硬件性能足够， 依然无法正常提供服务」，简而言之，就是单机1万个并发连接问题。这个概念最早由 Dan Kegel 提出并发布于其个人站点（http://www.kegel.com/c10k.html）。

技术解读C10K问题

  为什么会这样呢？因为计算机的上古时代，比如没有网络的 PC 时代，不会有程序员高瞻远瞩的预测到互联网时代的来临，也不会想到一台服务器会创建那么多的进程，即使在互联网初期，一台服务器能有100个在线用户已经是不得了的事情了。甚至，他们在设计 Unix 的 PID 的时候，采用了有符号的16位整数，这就导致一台计算机上能够创建出来的进程无法超过32767个。而计算机自己也得运行一些后台进程，这样应用软件能够创建的进程数就更少了。

  当然，这个问题随着技术的发展很快就解决了，现在大部分的个人电脑操作系统可以创建64位的进程，由于数据类型所带来的进程数上限消失了，但是我们依然不能无限制的创建进程，因为随着并发连接数的上升会占用系统大量的内存，同样会造成系统的不可用。

  操作系统里内存管理的主要作用是，进程请求内存的时候为其分配可用内存，进程释放后回收内存，并监控内存的使用状况。为了提高内存的使用率，现代操作系统需要程序能够共享内存，并且内存的限制对开发者透明，有些程序占用了内存空间，但不一定是一直使用的，这样可以把这部分内存数据序列化到磁盘上，需要的时候再加载到内存里，这样内存资源永远会给最需要的程序使用。于是程序员们发明了虚拟内存（Virtual Memory）。

  虚拟内存技术支持程序访问比物理内存大得多的内存空间，也使得多个程序共享内存更加高效。物理内存由 RAM 芯片提供，虚拟内存则依靠透明的使用磁盘空间，使程序运行起来好像有了更大的内存空间。

  但是问题依然存在，进程和线程的创建都需要消耗一定的内存，每创建一个栈空间，都会产生内存开销，当内存使用超过物理内存的时候，一部分数据就会持久化到磁盘上，随之而来的就是性能的大幅度下降。

C10K问题的本质

  C10K问题本质上是操作系统的问题。对于Web1.0/2.0时代的操作系统而言， 传统的同步阻塞I/O模型都是一样的，处理的方式都是requests per second，并发10K和100的区别关键在于CPU。

  创建的进程线程多了，数据拷贝频繁（缓存I/O、内核将数据拷贝到用户进程空间、阻塞）， 进程/线程上下文切换消耗大， 导致操作系统崩溃，这就是C10K问题的本质！

  可见，解决C10K问题的关键就是尽可能减少这些CPU等核心计算资源消耗，从而榨干单台服务器的性能，突破C10K问题所描述的瓶颈。

C10K解决方案探讨

  现在我们早已经突破了 C10K 这个瓶颈，具体的思路就是通过单个进程或线程服务于多个客户端请求，通过异步编程和事件触发机制替换轮训，IO 采用非阻塞的方式，减少不必要的性能损耗，等等。

  底层的相关技术包括 epoll、kqueue、libevent 等，应用层面的解决方案包括 OpenResty、Golang、Node.js 等，比如 OpenResty 的介绍中是这么说的：

   OpenResty 通过汇聚各种设计精良的 Nginx 模块，从而将 Nginx 有效地变成一个强大的通用 Web 应用平台。这样，Web 开发人员和系统工程师可以使用 Lua 脚本语言调动 Nginx 支持的各种 C 以及 Lua 模块，快速构造出足以胜任 C10K 乃至 C1000K 以上单机并发连接的高性能 Web 应用系统。