C10K问题
说实话我真不知到C10K问题,如果不是最近要了解swoole牵涉到异步、同步接着牵扯到各种知识点也不会接触到这个,现在单机已经不单单是C10K了,在朝着C1M、C10M的目标前进。但是本质其实是想通的或者是可以借鉴的,这里整理下
原文:
http://www.kegel.com/c10k.html
网上有很多小结 这边就转载下
http://rango.swoole.com/archives/381
最近到处在争论这些话题,发现很多人对一些基础的常识并不了解,在此发表一文做一下解释。此文未必能解答所有问题,各位能有一个大致的了解就好。
C10K的由来
大家都知道互联网的基础就是网络通信,早期的互联网可以说是一个小群体的集合。互联网还不够普及,用户也不多。一台服务器同时在线100个用户估计在当时已经算是大型应用了。所以并不存在什么C10K的难题。互联网的爆发期应该是在www网站,浏览器,雅虎出现后。最早的互联网称之为Web1.0,互联网大部分的使用场景是下载一个Html页面,用户在浏览器中查看网页上的信息。这个时期也不存在C10K问题。
Web2.0时代到来后就不同了,1方面是普及率大大提高了,用户群体几何倍增长。2是互联网不再是单纯的浏览万维网网页,逐渐开始进行交互,而且应用程序的逻辑也变的更复杂,从简单的表单提交,到即时通信和在线实时互动。C10K的问题才体现出来了。每一个用户都必须与服务器保持TCP连接才能进行实时的数据交互。Facebook这样的网站同一时间的并发TCP连接可能会过亿。
腾讯QQ也是有C10K问题的,只不过他们是用了UDP这种原始的包交换协议来实现的,绕开了这个难题。当然过程肯定是痛苦的。如果当时有epoll技术,他们肯定会用TCP。后来的手机QQ,微信都采用TCP协议。
这时候问题就来了,最初的服务器都是基于进程/线程模型的,新到来一个TCP连接,就需要分配1个进程(或者线程)。而进程又是操作系统最昂贵的资源,一台机器无法创建很多进程。如果是C10K就要创建1万个进程,那么操作系统是无法承受的。如果是采用分布式系统,维持1亿用户在线需要10万台服务器,成本巨大,也只有Facebook,Google,雅虎才有财力购买如此多的服务器。这就是C10K问题的本质。
实际上当时也有异步模式,如:select/poll模型,这些技术都有一定的缺点,如selelct最大不能超过1024,poll没有限制,但每次收到数据需要遍历每一个连接查看哪个连接有数据请求。
Epoll异步非阻塞
既然有了C10K问题,程序员们就开始行动去解决它。于是FreeBSD推出了kqueue,Linux推出了epoll,Windows推出了IOCP。这些操作系统提供的功能就是为了解决C10K问题。因为Linux是互联网企业中使用率最高的操作系统,Epoll就成为C10K killer、高并发、高性能、异步非阻塞这些技术的代名词了。
epoll技术的编程模型就是异步非阻塞回调,也可以叫做Reactor,事件驱动,事件轮循(EventLoop)。Epoll就是为了解决C10K问题而生。使用Epoll技术,使得小公司也可以玩高并发。不需要购买很多服务器,有几台服务器就可以服务大量用户。Nginx,libevent,node.js这些就是Epoll时代的产物。
C100K,C1M,C10M,C100M …
C10K问题解决后,程序员又提出了更高的挑战,也就是最近在火热争论的C100K,C1M等。Epoll既然能解决C10K,解决什么C100K,C1M也是可以的。只不过这个已经没有意义了。一个公司有1亿用户难道他买不起1万台服务器嘛。WhatsApp有2亿用户,卖了150亿美元。1万台服务器最多花费5000万美元。
看到阿里技术保障部的人也在谈C10K话题,我要补充一下,搞路由器、交换机、网关、防火墙之类基础网络设备的人,就不要参与C10K话题了。我们说的是应用层程序。
协程,coroutine
当程序员还沉浸在解决C10K问题带来的成就感时,一个新的问题被抛出了。异步嵌套回调太TM难写了。尤其是Node.js层层回调,缩进了几十层,要把程序员逼疯了。于是一个新的技术被提出来了,那就是协程(coroutine)。这个技术本质上也是异步非阻塞技术,它是将事件回调进行了包装,让程序员看不到里面的事件循环。程序员就像写阻塞代码一样简单。比如调用 client->recv() 等待接收数据时,就像阻塞代码一样写。实际上是底层库在执行recv时悄悄保存了一个状态,比如代码行数,局部变量的值。然后就跳回到EventLoop中了。什么时候真的数据到来时,它再把刚才保存的代码行数,局部变量值取出来,又开始继续执行。
这个就像时间禁止的游戏一样,国王对巫师说“我必须马上得到宝物,不然就砍了你的脑袋”,巫师念了一句时间停止的咒语,直到过了1年后勇士们才把宝物送来。这时候巫师解开咒语,把宝物交给国王。这里国王就可以理解成协程,他根本没感觉到时间停止,在他停止到醒来期间发生了什么他不知道,也不关心。
这就是协程的本质。协程是异步非阻塞的另外一种展现形式。Golang,Erlang,Lua协程都是这个模型。
同步阻塞
再回到同步阻塞这个话题,不知道大家看完协程是否感觉得到,实际上协程和同步阻塞是一样的。答案是的。所以协程也叫做用户态进/用户态线程。区别就在于进程/线程是操作系统充当了EventLoop调度,而协程是自己用Epoll进行调度。
协程的优点是它比系统线程开销小,缺点是如果其中一个协程中有密集计算,其他的协程就不运行了。操作系统进程的缺点是开销大,优点是无论代码怎么写,所有进程都可以并发运行。
Erlang解决了协程密集计算的问题,它基于自行开发VM,并不执行机器码。即使存在密集计算的场景,VM发现某个协程执行时间过长,也可以进行中止切换。Golang由于是直接执行机器码的,所以无法解决此问题。所以Golang要求用户必须在密集计算的代码中,自行Yield。
实际上同步阻塞程序的性能并不差,它的效率很高,不会浪费资源。当进程发生阻塞后,操作系统会将它挂起,不会分配CPU。直到数据到达才会分配CPU。多进程只是开多了之后副作用太大,因为进程多了互相切换有开销。所以如果一个服务器程序只有1000左右的并发连接,同步阻塞模式是最好的。
异步回调和协程哪个性能好
协程虽然是用户态调度,实际上还是需要调度的,既然调度就会存在上下文切换。所以协程虽然比操作系统进程性能要好,但总还是有额外消耗的。而异步回调是没有切换开销的,它等同于顺序执行代码。所以异步回调程序的性能是要优于协程模型的。
这里是指Nginx这种多进程异步非阻塞程序。Node.js/Redis此类程序如果不开多个进程,由于无法利用多核计算优势,所以性能并不好。
http://www.luoyandi.com/article/1992.html
关于这个问题,Ruby 的作者松本行弘在《代码的未来》- 云计算时代的编程一章中有详细的阐述,有兴趣的同事可以直接去读那本书,内容丰富,比我写的好。我这里写个简化版。
在做技术规划和架构设计的时候,我常常告诫技术人员,不要做过度设计,如果咱们只有1万用户,先别去操百万用户在线的心。淘宝那么大,也是从 Apache、PHP、MySql 发展起来的,没人能预见到淘宝会发展到这样一个规模,一旦发展起来,业务的爆发性增长会驱动技术的迅速发展,在业务规模还不及格的时候,不用为技术的未来担心。
这个思路在业务领域不会有太大的问题,因为需求的变化实在是太快了,需要时时去应对。但在底层技术的发展上,我们就有可能遭到「短视」的报复,比如:这个数据长度不会超过16位吧,这个程序不可能使用到2000年吧。于是就有了千年虫的问题,也有了 C10K 的问题。
C10K 就是 Client 10000 问题,即「在同时连接到服务器的客户端数量超过 10000 个的环境中,即便硬件性能足够, 依然无法正常提供服务」,简而言之,就是单机1万个并发连接问题。这个概念最早由 Dan Kegel 提出并发布于其个人站点(http://www.kegel.com/c10k.html)。
为什么会这样呢?因为计算机的上古时代,比如没有网络的 PC 时代,不会有程序员高瞻远瞩的预测到互联网时代的来临,也不会想到一台服务器会创建那么多的进程,即使在互联网初期,一台服务器能有100个在线用户已经是不得了的事情了。甚至,他们在设计 Unix 的 PID 的时候,采用了有符号的16位整数,这就导致一台计算机上能够创建出来的进程无法超过32767个。而计算机自己也得运行一些后台进程,这样应用软件能够创建的进程数就更少了。
当然,这个问题随着技术的发展很快就解决了,现在大部分的个人电脑操作系统可以创建64位的进程,由于数据类型所带来的进程数上限消失了,但是我们依然不能无限制的创建进程,因为随着并发连接数的上升会占用系统大量的内存,同样会造成系统的不可用。
操作系统里内存管理的主要作用是,进程请求内存的时候为其分配可用内存,进程释放后回收内存,并监控内存的使用状况。为了提高内存的使用率,现代操作系统需要程序能够共享内存,并且内存的限制对开发者透明,有些程序占用了内存空间,但不一定是一直使用的,这样可以把这部分内存数据序列化到磁盘上,需要的时候再加载到内存里,这样内存资源永远会给最需要的程序使用。于是程序员们发明了虚拟内存(Virtual Memory)。
虚拟内存技术支持程序访问比物理内存大得多的内存空间,也使得多个程序共享内存更加高效。物理内存由 RAM 芯片提供,虚拟内存则依靠透明的使用磁盘空间,使程序运行起来好像有了更大的内存空间。
但是问题依然存在,进程和线程的创建都需要消耗一定的内存,每创建一个栈空间,都会产生内存开销,当内存使用超过物理内存的时候,一部分数据就会持久化到磁盘上,随之而来的就是性能的大幅度下降。
这就像银行挤兑,人们把现金存入银行,收取一定的利息,平时只有少数人去银行取现,银行会拿人们存的钱去做更有价值的投资。但是,如果大部分人都去银行取现,银行是没有那么多现金的。取不到钱的用户,被门挡在外面的用户,一定会去拉横幅喊口号「最喜欢双截棍柔中带刚,不喜欢银行就上少林武当」云云,于是银行就处于不可用状态了。现在的 P2P 理财也是一个道理,投资者都去变现,无论是多么良性的资产,一样玩完。
为什么现在会有这么大的连接需求呢?因为业务驱动和技术发展嘛。除了普通的网页浏览和表单提交,即时通信和实时互动交流越来越成为主流需求,keep-alive 技术也能让浏览器产生长连接,实时在线的客户端越来越多,如果不能解决 C10K 问题,将导致服务商需要购买大量的服务器,而每一台服务器都不能做到物尽其用,即使你配置了更好的 CPU 和更大的内存。
当然,现在我们早已经突破了 C10K 这个瓶颈,具体的思路就是通过单个进程或线程服务于多个客户端请求,通过异步编程和事件触发机制替换轮训,IO 采用非阻塞的方式,减少不必要的性能损耗,等等。
底层的相关技术包括 epoll、kqueue、libevent 等,应用层面的解决方案包括 OpenResty、Golang、Node.js 等,比如 OpenResty 的介绍中是这么说的:
OpenResty 通过汇聚各种设计精良的 Nginx 模块,从而将 Nginx 有效地变成一个强大的通用 Web 应用平台。这样,Web 开发人员和系统工程师可以使用 Lua 脚本语言调动 Nginx 支持的各种 C 以及 Lua 模块,快速构造出足以胜任 C10K 乃至 C1000K 以上单机并发连接的高性能 Web 应用系统。
据说现在都去搞 C10M 了,你们怕不怕?
实际操作中,每个解决方案都不是那么容易实现的,很多技术领域油光水滑的东西,放到线上,往往会出现各种各样的问题和毛病。松本行弘先生介绍了一个「最弱连接」的概念:
如果往两端用力拉一条由很多环 (连接)组成的锁链,其中最脆弱的一个连接会先断掉。因此,锁链整体的强度取决于其中最脆弱的一环。
C10K 问题的情况也很相似。一台服务器同时应付超过一万个(或者更多)并发连接的情况,哪怕只有一个要素没有考虑到超过一万个客户端的情况,这个要素就会成为「最弱连接」,从而导致问题的发生。
每个做架构设计和技术实现的程序员,都应当考虑这个最弱连接问题。
你是最弱的一环吗?