Via 由 [ ] 提供

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 级别的产品。小伙伴们,你们怎么看?心动了,行动不?

上一篇: 灰度发布 下一篇: TIME_WAIT 问题