【科技新闻入口】【python派期货跟单软件】 【Quicklib首页】 【mdshare.cn行情数据中心】 【开户中国】 【酷操盘手】【量化界】【python派社区】【python资源导航】 你好,做量化的朋友,请加群点击链接加入群: python量化交易程序化回    A股程序和交易接口群     CTP_API开发技术核心群

Quicklib采用的异步IO架构的特点



  • QQ群:5172183

    异步式 I/O 与事件驱动
    Quicklib 最大的特点就是采用异步式 I/O 与事件驱动的架构设计。对于高并发的解决方
    案,传统的架构是多线程模型,也就是为每个业务逻辑提供一个系统线程,通过系统线程切
    换来弥补同步式 I/O 调用时的时间开销。Quicklib在和底层交互数据时使用的是单线程模型,对于所有 I/O 都采用异步式的请求方式,避免了频繁的上下文切换。Q uicklib在执行的过程中会维护一个事件队列,程序在执行时进入事件循环等待下一个事件到来,每个异步式 I/O 请求完成后会被推送到事件队列,等待程序进程进行处理。

    和其它常用的Python程序化框架不同,Quicklib的异步机制是基于事件的(底层C++代码实现事件驱动,效率更好,响应更快,不像之前的python框架的架构容易拥堵) 。

    所有的磁盘 I/O、网络通信、数据库查询都以非阻塞的方式请求,返回的结果由事件循环来处理。图1-1 描述了这个机制。Quicklib进程的回调线程在同一时刻只会处理一个事件,完成后立即进入事件循环检查并处理后面的事件。这样做的好处是,CPU 和内存在同一时间集中处理一件事(回调驱动),同时尽可能让耗时的 I/O 操作并行执行。 当获得回调驱动后,可采用多进程来进行耗时并行计算。

    Quicklib 只是在事件队列中增加请求,等待操作系统的回应,因而不会有任何多线程开销,很大程度上可以提高程序的健壮性和短事件内突然出现大量事件而造成的拥堵。
    替代文字
    这种异步事件模式的弊端也是显而易见的,因为它不符合开发者的常规线性思路,往往需要把一个完整的逻辑拆分为一个个事件,增加了开发和调试难度。

    用异步式 I/O 和事件驱动代替多线程,带来了可观的性能提升。

    例如,对于简单而常见的数据库查询操作, 代码在执行到第一行的时候,线程会阻塞,等待数据库返回查询结果,然后再继续处理。然而,由于数据库查询可能涉及磁盘读写和网络通信,其延时可能相当大(长达几个到几百毫秒,相比CPU的时钟差了好几个数量级),线程会在这里阻塞等待结果返回。对于高并发的访问,一方面线程长期阻塞等待,另一方面为了应付新请求而不断增加线程,因此会浪费大量系统资源,同时线程的增多也会占用大量的 CPU 时间来处理内存上下文切换,而且还容易短时间内介绍到大量事件导致程序响应缓慢和拥堵。

    看看Quicklib是如何解决这个问题的:

    以MD的事件驱动为例:

    所有的异步 I/O 操作在完成时都会发送一个事件到事件队列。 事
    件由 mddict字典对象提供。前面提到的 fs.readFile 和 http.createServer 的回
    调函数都是通过 来实现的。下面我们用一个简单的例子说明
    的用法:

    #回调类型
    MD_EMPTY = 8000 #无消息
    MD_LOGIN_SCUESS = 8001 #登录成功
    MD_LOGIN_DENIED = 8002 #登录被拒绝
    #MD_LOGIN_ERRORPASSWORD = 8003 #密码错误(行情没有密码错误)
    MD_LOGINOUT_SCUESS = 8004 #登出成功
    MD_NETCONNECT_SCUESS = 8005 #连接成功
    MD_NETCONNECT_BREAK = 8006 #断开连接
    MD_NETCONNECT_FAILER = 8007 #连接失败
    MD_SUBCRIBE_SCUESS = 8008 #订阅成功
    MD_UNSUBCRIBE_SCUESS = 8009 #取消订阅成功
    MD_NEWTICK = 8010 #新Tick到来
    MD_SYSTEM_ERROR = 8011 #错误应答
    MD_QRY_FORQUOTE = 8012 #询价通知
    MD_SYSTEM_LOG = 8013 #日志

    def MD_OnTick():
    #新的一笔Tick数据驱动
    #print “---------------MD_OnTick---------------“
    global num
    num=num+1
    #取得新TICK的合约代码
    Instrument =market.GetCmdContent_Tick()
    #print “Instrument %s”%Instrument
    #打印该合约数据, 可增加交易策略逻辑计算,计算进程放入其它线程或进程中,以免耗时计算阻塞行情接收和其它回调
    print u”(%d)%s %s [%0.02f][%0.00f]”%(num,Instrument,market.InstrumentID(Instrument), market.LastPrice(Instrument), market.Volume(Instrument))

    mddict={
    MD_EMPTY:MD_OnEmptyCmd,
    MD_LOGIN_SCUESS:MD_OnUserLogin,
    MD_LOGIN_DENIED:MD_OnUserLoginDenied,
    MD_LOGINOUT_SCUESS:MD_OnUserLogout,
    MD_NETCONNECT_SCUESS:MD_OnFrontConnected,
    MD_NETCONNECT_BREAK:MD_OnFrontDisconnected,
    MD_NETCONNECT_FAILER:MD_OnFrontConnectedFailer,
    MD_SUBCRIBE_SCUESS:MD_OnSubMarketData,
    MD_UNSUBCRIBE_SCUESS:MD_OnUnSubMarketData,
    MD_NEWTICK:MD_OnTick,
    MD_SYSTEM_ERROR:MD_OnError,
    MD_QRY_FORQUOTE:MD_OnForQuote,
    MD_SYSTEM_LOG:MD_OnLog

    }

    while(1): #死循环
    print(u"Wait for a New Cmd(MD)\n");
    mddict [ market.OnCmd() ] ()
    print(u"Get A New cmd(MD)\n");

    消息驱动,包括了各种回调,在没有消息到来时,一直处于阻塞状态,不占用CPU。当回调函数内有大量耗时的CPU计算时,建议回调函数内采用多进程或进程池来进行计算处理,以免阻塞消息驱动线程。

    运行这段代码,进入循环时,第一次循环中先 在控制台输出 Wait for a New Cmd,然后 运行 mddictmarket.OnCmd(),其中mddict是定义的事件回调函数字典,通过market.OnCmd()将不同整型值返回,并映射到不同的回调函数,这个整形值即使回调事件的编号。

    例如返回 8010,代表底层缓冲区有新的TICK出现,通过字典mddict映射后,开始执行 事件回调函数MD_OnTick(),去缓冲区取得最新一笔tick,并重缓冲区删除该tick数据。

    在底层API没有事件的时候,trader.OnCmd()将处于阻塞状态,不消耗CPU事件,当出现事件,将立刻映射到相应的事件回调函数去执行。

    执行完毕将输出Get A New cmd,然后再进入下一次的循环打印Wait for a New Cmd,再次进入阻塞状态。

    这么做需要注意,映射到的回调函数,尽量不要做耗时的计算,比如策略的计算,可以在回调函数中将数据交个另一个进程做计算处理,例如采用进程池等方式。

    这段代码中 mddict的 参数是一个函数,我们称为回调函数的编号。进程在执行的时候,不会等待结果返回,而是直接继续执行后面的语句,直到进入事件循环。

    当新TICK数据出现时,会将事件发送到事件队列,等到线程进入事件循环以后,才会调
    用之前的回调函数继续执行后面的逻辑。

    单线程事件驱动的异步式 I/O 比传统的多线程阻塞式 I/O 究竟好在哪里呢?简而言之,
    异步式 I/O 就是少了多线程的开销。对操作系统来说,创建一个线程的代价是十分昂贵的,
    需要给它分配内存、列入调度,同时在线程切换的时候还要执行内存换页,CPU 的缓存被
    清空,切换回来的时候还要重新从内存中读取信息,破坏了数据的局部性。①
    当然,异步式编程的缺点在于不符合人们一般的程序设计思维,容易让控制流变得晦涩
    难懂,给编码和调试都带来不小的困难。习惯传统编程模式的开发者在刚刚接触到大规模的异
    步式应用时往往会无所适从,但慢慢习惯以后会好很多。尽管如此,异步式编程还是较为困难。
    表比较了同步式 I/O 和异步式 I/O 的特点。
    替代文字
    Quicklib的事件循环机制

    在什么时候会进入事件循环呢?答案是Quicklib 程序由事件循环开始,到事件循
    环结束,所有的逻辑都是事件的回调函数,所以 Quicklib始终在事件循环中,程序入口就是
    事件循环第一个事件的回调函数,即在QuickLibDemo.py中的入口函数 main()函数中的while死循环提供,这个循环会运行一个阻塞函数。事件的回调函数在执行的过程中,可能会发出 I/O 请求或直接发射事件,执行完毕后再返回事件循环,事件循环会检查事件队列中有没有未
    处理的事件,直到程序结束。图3-5说明了事件循环的原理。
    替代文字
    异步式 I/O 与事件式编程Quicklib最大的特点就是异步式 I/O(或者非阻塞 I/O)与事件紧密结合的编程模式。这
    种模式与传统的同步式 I/O 线性的编程思路有很大的不同,因为控制流很大程度上要靠事件
    和回调函数来组织,一个逻辑要拆分为若干个单元。

    阻塞与线程
    什么是阻塞(block)呢?线程在执行中如果遇到磁盘读写或网络通信(统称为 I/O 操作),
    通常要耗费较长的时间,这时操作系统会剥夺这个线程的 CPU 控制权,使其暂停执行,同
    时将资源让给其他的工作线程,这种线程调度方式称为 阻塞。当 I/O 操作完毕时,操作系统
    将这个线程的阻塞状态解除,恢复其对CPU的控制权,令其继续执行。这种 I/O 模式就是通
    常的同步式 I/O(Synchronous I/O)或阻塞式 I/O (Blocking I/O)。
    相应地,异步式 I/O (Asynchronous I/O)或非阻塞式 I/O (Non-blocking I/O)则针对
    所有 I/O 操作不采用阻塞的策略。当线程遇到 I/O 操作时,不会以阻塞的方式等待 I/O 操作
    的完成或数据的返回,而只是将 I/O 请求发送给操作系统,继续执行下一条语句。当操作
    系统完成 I/O 操作时,以事件的形式通知执行 I/O 操作的线程,线程会在特定时候处理这个
    事件。为了处理异步 I/O,线程必须有事件循环,不断地检查有没有未处理的事件,依次予以处理。
    替代文字
    阻塞模式下,一个线程只能处理一项任务,要想提高吞吐量必须通过多线程。而非阻塞模式下,一个线程永远在执行计算操作,这个线程所使用的 CPU 核心利用率永远是 100%,
    I/O 以事件的方式通知。在阻塞模式下,多线程往往能提高系统吞吐量,因为一个线程阻塞
    时还有其他线程在工作,多线程可以让 CPU 资源不被阻塞中的线程浪费。而在非阻塞模式
    下,线程不会被 I/O 阻塞,永远在利用 CPU。多线程带来的好处仅仅是在多核 CPU 的情况
    下利用更多的核,而Node.js的单线程也能带来同样的好处。这就是为什么 Node.js 使用了单
    线程、非阻塞的事件编程模式。

    图3-3 和图3-4 分别是多线程同步式 I/O 与单线程异步式 I/O 的示例。假设我们有一项工
    作,可以分为两个计算部分和一个 I/O 部分,I/O 部分占的时间比计算多得多(通常都是这
    样)。如果我们使用阻塞 I/O,那么要想获得高并发就必须开启多个线程。而使用异步式 I/O
    时,单线程即可胜任。
    替代文字
    Node.js和Quicklib一样,都是基于异步IO架构,以 Node.js 与 PHP + Nginx为例对比异步IO和多线程并发的性能对比:有数据细对比了 Node.js 与 PHP+Nginx 组合,结果显示在3000并发连接、30秒的测试下,输出“hello world”请求:
     PHP 每秒响应请求数为3624,平均每个请求响应时间为0.39秒;
     Node.js 每秒响应请求数为7677,平均每个请求响应时间为0.13秒。
    而同样的测试,对MySQL查询操作:
     PHP 每秒响应请求数为1293,平均每个请求响应时间为0.82秒;
     Node.js 每秒响应请求数为2999,平均每个请求响应时间为0.33秒。


Log in to reply
 

社区手机APP介绍
社区APP通过手机扫描二维码下载2
社区 APP(Android)点击下载
沪ICP备17025576号-1
沪ICP备17025576号-1