有读者问，backtrader实盘交易的时候，是否支持实时更新画图，比如接收CTP的数据，合成一分钟的bar，然后在网页上显示行情，类似于通达信或者同花顺的行情软件的看盘功能。

很遗憾的告诉各位，backtrader中没有提供直接的方法。但是可以自己去实现。这篇文章就尝试梳理下backtrader实盘的时候数据处理与数据展示的一些问题。

使用程序化交易的目的

我们为什么想要使用程序化进行交易呢？这个问题就回到最开始我们已经回答过的问题：量化交易有什么优势？

1. 可以同时使用多个策略、交易多个资产，节省很多的时间与精力

2. 交易速度比较快，降低滑点

从这两个目标出发，谈一谈，backtrader在实盘中，如何更好的实现多品种多策略的交易。

硬件的限制

我们进行程序化交易的程序一定是运行在一定的设备当中，有一定量的CPU、一定量的内存、一定IO速度的硬盘和一定传输速度的网络。CPU、内存、IO速度，和网络，影响着或者或多或少决定着，我们的交易速度怎么样，我们能在多少个资产上跑多少个策略。

一般情况下，CPU频率越高，核数越多，内存越大，硬盘越好，网络越快，进行程序化也就更优优势。但是，很多情况下，资源都是有限的，硬件基本都是限定的。

我们需要考虑的是，在硬件设备一定的情况下，我们应该怎么提高我们在程序化交易的时候的优势。

使用程序化交易的编程语言的限制

不需要我解释，为什么在做高频的时候，C++比python好了吧？在做中低频的时候，C++的优势不明显，使用python编程相对容易简洁，所以，相对来说，python反而会有一定的优势。在日内交易中，C++和python就不太好对比了，我觉得，可能C++相对好一些。

所以，如果您的编程技能特别好，C++玩的比较顺，建议使用C++开发交易系统，实现程序化交易。

如果C++使用的不怎么好，那还是用python吧。python里面，现在有越来越多的支持程序化交易的框架了。

backtrader的限制

backtrader在实盘运行的时候是单核处理的，实际上，在回测的时候，也是单核处理的(参数优化除外)。既然是单核处理的，那么，很显然的一个问题就是，CPU的处理能力有限制，为了能在信号出来的时候尽快的下单，并把信号传递到交易所里面，降低交易的滑点，在策略里面进行的数据处理越少越好。

有一些人喜欢使用resample和replay之类的魔法，这里是不推荐的，在我的专栏里面也强调了很多次了，姑且不论这些resample是否存在不合理之处，在设计理念上就是不合理的。

实盘交易中bar的合成

既然比较明确的一件事是backtrader是单核运行的，我们也希望提高策略运行的速度，所以，bar的合成最好不要在策略里面去合成。我一直疑惑，为啥有些量化框架，在运行的时候，直接获取tick数据，在策略里面合成bar呢？这是明显的设计不合理之处。就不提那些平台是这样设计的了。

策略需要什么数据，就直接调用什么数据。最好不要再策略运行的那个进程中，还去合成数据。

比较好的一个实践方式是，用一个或者几个进程，获取到的行情数据，保存到内存中，然后计算合成具体的bar，然后供策略调用；获取到的数据，计算的bar，采用异步或者什么方式，保存到本地的数据库中。

如何实时更新行情到图表中

backtrader虽然不支持，但是还是比较容易实现的。把获取到的行情，要么保存到内存中，要么保存到本地，采用合理的方式计算成bar之后，画到图形中就可以了。画图和策略运行最好分开，不要使用一个进程。如果想要使用策略运行的信号，在backtrader运行过程中，把买卖信号保存下来就好了。原理上不难，中间有一些细节性的东西需要好好考虑下。