您好,欢迎访问本站博客!登录后台查看权限
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧
  • 网站所有资源均来自网络,如有侵权请联系站长删除!

关于C10K、异步回调、协程、同步阻塞(转)

C/C++ admin 2018-08-01 951 次浏览 0个评论
网站分享代码

最近到处在争论这些话题,发现很多人对一些基础的常识并不了解,在此发表一文做一下解释。此文未必能解答所有问题,各位能有一个大致的了解就好。

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此类程序如果不开多个进程,由于无法利用多核计算优势,所以性能并不好。在Node.js中可以使用childprocess/cluster等扩展开启多进程以解决此问题。
分类:Linux互联网标签:

关于HHVM/Hack/Jit和PHP的性能问题

2014年4月18日没有评论

最近HHVM/Hack很火,群里有不少人已经开始预言HHVM将会取代Zend。

HHVM为什么比Zend PHP快?

读过PHP内核实现文章的人都懂得PHP的zend vm是一个很高级的虚拟机,zend先将PHP代码进行编译生成一种二进制指令,称之为opcode。然后再用zend vm逐条执行。而PHP的用户函数、运行时局部变量,全局变量,常量都是放在一个Hashtable中。每一条opcode指令都对应一个C函数。

执行一次C函数的开销主要是1:参数的入栈出栈,2:CPU寄存器状态保存。比如在PHP里执行1千万次加法。

$j = 0;for ($i = 0; $i < 10000000; $i++) {    $j += $i;
}

这里会发生1000万次函数调用。但如果是编译为机器码就快得多了。一个2.0GHz的CPU,理论上每秒可以执行20亿次指令。如果换成函数调用,1秒差不多只能运行一千万次。所以编译为机器码执行的语言,如C/C++,Golang或者拥有JIT的语言,如Java,Node.js(V8),LuaJIT,HHVM单从指令执行的角度上来看至少比PHP快几十倍。

对于字符串处理,JSON解码编码,iconv编码转换,数组操作等,PHP比C++,Java慢,这是不正确的。在PHP里这类操作都是由C扩展函数完成的,性能与编译型语言一致。所以真正慢的只是PHP的写的代码,如用户函数,类和对象操作等。

运算密集型/IO密集型

运算密集型程序,程序内需要大量执行内存复制操作、循环、运算指令等。此类程序的瓶颈就是CPU,增加性能的方法就是提升CPU硬件配置,改进算法,提升语言/工具的执行性能。对于此类程序,PHP的性能问题就会凸显出来。执行相同的逻辑,PHP要比C/C++慢几十倍甚至上百倍,这是不可接受的。

IO密集型程序,程序内主要的瓶颈是IO等待,比如我们有一个Http请求要执行100ms才返回结果,其中有90ms在查询数据库,8ms的时间在读写文件。那无论使用C/C++还是PHP,请求响应时间总是100ms左右。语言性能优化只有这2ms的空间。

我们常见的程序里大部分都是IO密集型程序,很少有运算密集的,语言本身的性能差异可以忽略。遇到需要密集计算的模块,也可以使用C/C++来实现,并提供PHP扩展。

像HHVM这样提升PHP性能的工具,在超大型PHP集群确实是有价值的,提升性能后可以节约一部分机器成本。

 

分类:LinuxPHPPHP系统编程标签:

PHP开发异步高性能的MySQL代理服务器

2014年3月6日2 条评论

MySQL数据库对每个客户端连接都会分配一个线程,所以连接非常宝贵。开发一个异步的MySQL代理服务器,PHP应用服务器可以长连接到这台Server,既减轻MYSQL的连接压力,又使PHP保持长连接减少connect/close的网络开销。

此Server考虑到了设置了数据库连接池尺寸,区分忙闲,mysqli断线重连,并设置了负载保护。基于swoole扩展开发,io循环使用epoll,是全异步非阻塞的,可以应对大量TCP连接。

程序的逻辑是:启动时创建N个MySQL连接,收到客户端发来的SQL后,分配1个MySQL连接,将SQL发往数据库服务器。然后等待数据库返回查询结果。当数据库返回结果后,再发给对应的客户端连接。

核心的数据结构是3个PHP数组。idle_pool是空闲的数据库连接,当有SQL请求时从idle_pool中移到busy_pool中。当数据库返回结果后从busy_pool中再移到idle_pool中,以供新的请求使用。当SQL请求到达时如果没有空闲的数据库连接,那会自动加入到wait_queue中。一旦有SQL完成操作,将自动从wait_queue中取出等待的请求进行处理。

如此循环使用。由于整个服务器是异步的单进程单线程所以完全不需要锁。而且是完全异步的,效率非常高。

当然本文的代码,如果要用于生产环境,还需做更多的保护机制和压力测试。在此仅抛砖引玉,提供一个解决问题的思路。

class DBServer{    protected $pool_size = 20;    protected $idle_pool = array(); //空闲连接
    protected $busy_pool = array(); //工作连接
    protected $wait_queue = array(); //等待的请求
    protected $wait_queue_max = 100; //等待队列的最大长度,超过后将拒绝新的请求

    /**
     * @var swoole_server
     */
    protected $serv;    function run()
    {        $serv = new swoole_server("127.0.0.1", 9509);        $serv->set(array(            'worker_num' => 1,
        ));        $serv->on('WorkerStart', array($this, 'onStart'));        //$serv->on('Connect', array($this, 'onConnect'));
        $serv->on('Receive', array($this, 'onReceive'));        //$serv->on('Close', array($this, 'onClose'));
        $serv->start();
    }    function onStart($serv)
    {        $this->serv = $serv;        for ($i = 0; $i < $this->pool_size; $i++) {            $db = new mysqli;            $db->connect('127.0.0.1', 'root', 'root', 'test');            $db_sock = swoole_get_mysqli_sock($db);            swoole_event_add($db_sock, array($this, 'onSQLReady'));            $this->idle_pool[] = array(                'mysqli' => $db,                'db_sock' => $db_sock,                'fd' => 0,
            );
        }        echo "Server: start.Swoole version is [" . SWOOLE_VERSION . "]\n";
    }    function onSQLReady($db_sock)
    {        $db_res = $this->busy_pool[$db_sock];        $mysqli = $db_res['mysqli'];        $fd = $db_res['fd'];        echo __METHOD__ . ": client_sock=$fd|db_sock=$db_sock\n";        if ($result = $mysqli->reap_async_query()) {            $ret = var_export($result->fetch_all(MYSQLI_ASSOC), true) . "\n";            $this->serv->send($fd, $ret);            if (is_object($result)) {                mysqli_free_result($result);
            }
        } else {            $this->serv->send($fd, sprintf("MySQLi Error: %s\n", mysqli_error($mysqli)));
        }        //release mysqli object
        $this->idle_pool[] = $db_res;        unset($this->busy_pool[$db_sock]);        //这里可以取出一个等待请求
        if (count($this->wait_queue) > 0) {            $idle_n = count($this->idle_pool);            for ($i = 0; $i < $idle_n; $i++) {                $req = array_shift($this->wait_queue);                $this->doQuery($req['fd'], $req['sql']);
            }
        }
    }    function onReceive($serv, $fd, $from_id, $data)
    {        //没有空闲的数据库连接
        if (count($this->idle_pool) == 0) {            //等待队列未满
            if (count($this->wait_queue) < $this->wait_queue_max) {                $this->wait_queue[] = array(                    'fd' => $fd,                    'sql' => $data,
                );
            } else {                $this->serv->send($fd, "request too many, Please try again later.");
            }
        } else {            $this->doQuery($fd, $data);
        }
    }    function doQuery($fd, $sql)
    {        //从空闲池中移除
        $db = array_pop($this->idle_pool);        /**
         * @var mysqli
         */
        $mysqli = $db['mysqli'];        for ($i = 0; $i < 2; $i++) {            $result = $mysqli->query($sql, MYSQLI_ASYNC);            if ($result === false) {                if ($mysqli->errno == 2013 or $mysqli->errno == 2006) {                    $mysqli->close();                    $r = $mysqli->connect();                    if ($r === true) continue;
                }
            }            break;
        }        $db['fd'] = $fd;        //加入工作池中
        $this->busy_pool[$db['db_sock']] = $db;
    }
}$server = new DBServer();$server->run();
分类:LinuxPHPSwoole扩展标签:

异步AIO的研究

2014年3月5日没有评论

首先声明一下epoll+nonblock从宏观角度可以叫做全异步,但从微观的角度来看还是同步的IO。只是在数据到达后得到系统通知,然后同步执行recv取回数据,没有iowait。

真正的异步IO(下面会统一叫做AIO)应该像Windows IOCP一样,传入文件句柄,缓存区,尺寸等参数和一个函数指针,当操作系统真正完成了IO操作,再执行对应的函数。

实际上对于socket来说,epoll已经是最高效的模型了,虽然比AIO多一次recv系统调用,但总体来看没有任何IO等待,效率很高。而且epoll是天然的reactor模型,程序实现更容易。AIO如windows的IOCP,是异步回调的方式,开发难度很高。

为什么还是需要AIO呢,原因是文件句柄跟socket完全不同,它总是处于可读状态。不能使用epoll+nonblock来实现异步化。如果在一个epoll的全异步Server中,要读写文件那必须得使用AIO。下面说下AIO的几种实现方案。

gcc AIO

gcc遵循posix标准实现了AIO。头文件为 <aio.h>,支持FreeBSD/Linux。是通过阻塞IO+线程池来实现的。主要的几个函数是aio_read/aio_write/aio_return。

优点:支持平台多,兼容性好,无需依赖第三方库,阻塞IO可以利用到操作系统的PageCache。

缺点:据说有一些bug和陷阱,一直未解决。不过这个都是网上文章中讲的,gcc发展这么多年,不至于还有遗留bug吧。这里有待测试。

Linux Native Aio

由操作系统内核提供的AIO,头文件为<linux/aio_abi.h>。Native Aio是真正的AIO,完全非阻塞异步的,而不是用阻塞IO和线程池模拟。主要的几个系统调用为io_submit/io_setup/io_getevents。

优点:由操作系统提供,读写操作可以直接投递到硬件,不会浪费CPU。

缺点:仅支持Linux,必须使用DirectIO,所以无法利用到操作系统的PageCache。对于写文件来说native aio的作用不大,应为本身写文件就是先写到PageCache上,直接返回,没有IO等待。

Libeio

libev的作者开发的AIO实现,与gcc aio类似也是使用阻塞IO+线程池实现的。优点与缺点参见上面。它与gcc aio的不同之处,代码更简洁,所以bug少更安全稳定。但这是一个第三方库,你的代码需要依赖libeio。

总结

如果你的程序读写的文件很大,随即性强,这样PageCache的命中率低,那可以选择Native AIO,降低CPU使用率。

如果读写的文件很小,而且是固定的一些文件,这样PageCache的命中率高,可以选择gcc aio或者libeio。

  来源:韩天峰老大的博客 http://rango.swoole.com/archives/category/linux

已有 951 位网友参与,快来吐槽:

发表评论

站点统计