c10 k 编程

比较传统的服务端程序（ PHP 、 FAST CGI 等），大多都是通过每产生一个请求，都会有一个进程与之相对应，请求处理完毕后相关进程自动释放。由于进程创建、销毁对资源占用比较高，所以很多语言都通过常驻进程、线程等方式降低资源开销。即使是资源占用最小的线程，当并发数量超过 1 k 的时候，操作系统的处理能力就开始出现明显下降，因为有太多的 CPU 时间都消耗在系统上下文切换。

由此产生了 c10 k 编程，指的是服务器同时支持成千上万个客户端的问题，也就是 concurrent 10 000 connection （这也是 c10 k 这个名字的由来）。由于硬件成本的大幅度降低和硬件技术的进步，如果一台服务器同时能够服务更多的客户端，那么也就意味着服务每一个客户端的成本大幅度降低，从这个角度来看， c10 k 问题显得非常有意义。

c10 k 解决了这几个主要问题：

• 单个进程或线程可以服务于多个客户端请求
• 事件触发替代业务轮训
• IO 采用非阻塞方式，减少额外不必要轮训

c10 k 编程的世界，一定是异步编程的世界，他俩绝对是一对儿好基友。服务端一直都不缺乏新秀，各种语言、框架层出不穷。笔者比较熟悉的就有 OpenResty ， Golang ， Node.js ， Rust ， Python(gevent)等。每个语言或解决方案，都有自己完全不同的表现。但是他们从系统底层 API 应用上，都是相差不大。每个语言自身的实现机理、运行方式可能差别很大，但只要没有严重的代码错误，他们的性能指标都应该是在同一个级别的。

c1 k --> c10 k --> c100 k --> ???

人类前进的步伐，永远是没有尽头的，总是在不停的往前追跑。 c10 k 的问题，早就被解决，而且方法还不止一个。目前如果方案优化手段给力，做到 c100 k 也是可以达到的。后面还有世界么？我们还能走么？

告诉你肯定是有的，那就是 c10 m 。推荐大家了解一下dpdk这个项目，并搜索一些相关领域的知识。要做到 c10 m ，可以说系统网络内核、内存管理，都成为瓶颈了。要揭竿起义，统统推到重来。直接操作网卡绕过内核对网络的封装，内存从系统中拿过来，自己玩。由于这个动作太大，而且还绑定硬件型号（主要是网卡），所以目前这个项目进展还比较缓慢。不过对于有追求的人，可能就要两眼放光了。

前些日子 dpdk 组织国内 CDN 厂商开了一个小会，阿里的朋友说已经用这个开发出了 c10 m 级别的产品。小伙伴们，你们怎么看？心动了，行动不？