该项目为币安合约的架构，有超过100亿美金交易量和超过一年时间实盘验证，包含数据录入，风控，交易，数据分析，但不包含具体策略。
前端演示地址：8.217.121.203，初始930美金运行着一个年化100%~200%的左侧回归策略
你可以利用它简单，低成本的实现你的交易逻辑，其大量运用阿里云服务器进行分布式架构，多进程处理，以及飞书进行异常报错和交易信息披露
如果你愿意详细阅读该readme的所有信息，尤其是 模块详细解析 ，那么他同时也会是一部关于币安合约的交易风控，设计架构的经验理解历史，总结了几乎本人所有成功和失败的经验，希望能让后来者少踩些坑
低成本，高效率，简单实现是这套系统的三个优势
不到1000人民币一个月的成本，实现每分钟扫描约1500万次交易对是否满足交易条件
除了撮合服务器（C++）外都采用python编写，简单易懂
大量的分布式架构实现更快的速度，并且可以根据个人需求，自由伸缩的调控服务器数量来实现成本和性能的平衡
通过多重接口读取行情/账户信息，并根据更新时间戳进行整合，最大程度的降低数据风险
企业级别的风控安全解决方案
该系统通过一个C++服务器作为主撮合服务器，大量的可伸缩调整的分布式python服务器作为数据采集服务器。
将采集的数据，包括Kline ，trades，tick等，喂给C++服务器。
交易服务器再从C++服务器统一读取数据，并且在本地端维护一个K线账本，来避开交易所的频率限制，实现高效率，低成本的数据读取。
又比如，账户的余额，持仓数据，在币安上有三种方式获取，a是position risk，b是account，c是ws，那么会有三台服务器分别采用这三种方式读取，然后汇入C++服务器进行校对，通过对比更新时间截取最新的数据，然后服务给交易服务器
前端数据板块，通过阿里云oss为中介，网页读取oss数据的方式进行展示，隔离数据风险
2021年，我从一家top量化公司辞职后做起量化交易，主要战场在币安，这两年间，我从做市商->趋势->套利等类型均有涉及，最高峰的时候，在币安一个月有接近20亿美金的交易额。
至2023年7月，因为各种原因，大方向上失败了，只遗留下极少资金在继续运行一个比较稳定盈利的左侧交易策略。
这是在这两年时间里面探索出来的一套高效率，低成本的数据读取，录入框架，同时包含了一套风控系统，他更像一个架构，而不是一个实现，你同样可以通过简单的修改替换运用到okex，bybit等等上
资金合作或者工作机会（不谈任何涉及策略原理和源码，请开门见山节省双方时间），请联系微信号 melelery 或邮件至c.binance.quant@gmail.com
我方实盘的项目运行环境为Ubuntu 22.04 64位，Python 3.10.6
python文件采用以下方式运行，以webServer为例
ps -efwwww |grep webServer.py | awk '{print $2}' | xargs kill -9
dos2unix webServer.py
chmod +x webServer.py
nohup ./webServer.py >/dev/null &
但是更推荐使用 dataPy/uploadDataPy 的方式
react前端项目
npm install
npm start
C++文件
g++ wsServer.cpp -o wsServer.out -lboost_system
dos2unix wsServer.out
chmod +x wsServer.out
nohup ./wsServer.out >/dev/null &
由于项目使用的全部库和包都是官方或者热门项目，在google可以查找到安装方式，此处不再累述如何安装环境
如果需要最简启动方案，可邮件 c.binance.quant@gmail.com 联系我方，直接共享系统镜像到你方阿里云账号，收取100 USDT的技术费用
我方设计的模块包括 通用部分 ，数据处理部分 ，关键操作部分 ，安全风控部分 ，以及没有开源的具体交易逻辑部分
该项目的最小化开启需求为 一台web服务器，一台ws服务器，一台tick数据读取服务器，一台one min kline数据读取服务器，以及一台交易服务器
你可以根据自己的需求，扩展相关的服务器，例如需要 15 m 的kline，需要trades等等，只需要在这个基础上增加即可，这里没有盘口数据的整合，除了买一卖一。
对于更高维度的盘口数据，我方选择在交易服务器里面进行读取
因为除了kline数据，其他数据进行这种整合并没有太大的实际意义
200个交易对的kline数据，通过这种方式可以减少调用接口的频率，以及在某些接口有延迟的情况下依然能通过校对获得最新数据
但是盘口数据的api就一个，所有没有整合需求。
我方对于盘口数据延迟的解决方案是通过交易服务器的分布式运行。
如架设了五台交易服务器，运行着一样的开仓关仓逻辑，在满足前置开仓条件后，五台服务器会同时进入盘口数据读取的流程，同时间多进程的读取同一个数据，可以优化延迟等意外状况。
这里顺便引申出一个交易服务器发出订单的方式。
有两种，一种是直接在交易服务器上发出，一种是做一个发出交易指令的web服务器，交易服务器通过http请求到内网web服务器后统一发出。
比方，五台交易服务器，假设总交易量需求是100u，那么就每台服务器负责20u的交易量，如果延迟了或是其他问题，某一台服务器丢失了信号那就是损失20u的交易量
而如果采用web服务器统一发出，那么会在第一次接收到http请求的时候，即开出100%的交易量
两种方式各有适用的地方和优势，需要自行抉择，实际上在webserver文件里面已经整合了第二种方式。
我方目前维护的实盘项目，具体服务器配置为，（服务器名即为开源的文件名，在下方有更详细的单个文件介绍）
一台 wsPosition 服务器，用于通过ws的方式读取币安的仓位和余额数据，汇入ws数据撮合服务器
一台positionRisk服务器，用于读取/fapi/v2/positionRisk接口，通过该接口获取仓位信息并实时判断损失，以便于及时止损，该服务器和wsPosition，makerStopLoss，getBinancePosition具备类似功能，之所以设计多种交叉相同功能的服务器，是为了最大限度的防止风险，在币安的某一接口出现延迟的情况下，系统依然可以健壮的运行，以下不再重述
一台makerStopLoss服务器，用于从getBinancePosition服务器读取仓位信息后，读取单独的挂单信息，然后预设止损单，之所以与getBinancePosition服务器进行拆分，是因为读取挂单需要的权重较高，拆分成两个ip可以更高频率的进行操作
一台getBinancePosition服务器，用于读取/fapi/v2/account接口，获得仓位信息和余额后汇入ws数据撮合服务器
一台commission服务器，用于记录流水信息
一台checkTimeoutOrders服务器，用于读取/fapi/v1/openOrders接口，查询全部挂单，然后取消超过一定时间的挂单，或者进行一些额外的操作，例如挂单三秒没被吃，则转换成take订单等等
一台cancelServer服务器，本质上也是web server服务器，运行webServer文件，用于取消订单
一台webServer服务器，本质上也是web server服务器，运行webServer文件，用于大部分程序一开始读取交易对等等
两台oneMinKlineToWs服务器，用于低频率读取一分钟线的kline
两台volAndRate服务器，用于读取交易量数据做分析并提供给其他服务器
十台specialOneMinKlineToWs 服务器，用于高频率读取一分钟线的kline
十台tickToWs服务器，用于读取 tick 群信息
一台ws服务器，用于C++的数据戳合服务器
以及五台交易服务器，除了运行交易程序同时运行webServer，提供接口给checkTimeout获取全部挂单数据
合计38台服务器，以及一台最低配置的mysql数据库
其中对于开仓服务器和ws服务器，选择了高主频类型的服务器，约有一倍速度的提升，其他的行情和数据录取服务器并无必要进行这个优化，只需要选用最低配置的抢占式服务器
综合成本一个月不足3000元人民币，大头在流量费用，个人认为上述数目对半砍依然可以满足大部分量化的风控和延迟需求
在该项目里，一个单独的模块，需要一台服务器一个IP单独运行，目前基本已经将单模块的https读取频率调教到币安允许的最大值。
此处需要说明的是，这里都是以阿里云东京为例子，币安的服务器在亚马逊云东京。
而本文所叙述的延迟，其实包含两种延迟，一是读取频率的延迟，二是网络的延迟，这两种延迟综合计算后，才是真实环境下的最终延迟。
之所以使用阿里云是因为阿里云抢占式服务器具备成本优势，从而具备读取频率延迟的优势。
阿里云网络延迟约为10ms，而亚马逊在不申请内网权限的情况下预计为1~3ms，申请内网则面临锁定ip的问题，即无法通过铺开更多ip的手段去降低延迟。
虽然亚马逊云具备更低的延迟，但是由于
-
ws类型的数据读取通常被币安锁定100ms以上的延迟，且ws类型的读取数据具备某些不可确认的风险因素，所以该方式被排除
-
如果采取https读取的方式，某些数据的读取权重高达20，甚至是30，由此推演出需要多IP，进行分布式读取才能具备更高频率，而这个时候，单个IP的成本价格即成了需要考虑的因素，阿里云抢占式服务器的成本一个月不足20人民币，在综合的性价比考虑后，我方选择了日本阿里云。
-
该方案并不是一套服务于高频（纳秒级别）交易的解决方案，否则全部都会用C++编写，实际上他是一套追求成本，延迟，开发速度，三者均衡最优解的方案，并为毫秒级别的策略服务
前端文件，该网页为对外网页，所以强制锁定了一分钟的时间间隔，展示的数据也比较简单，毕竟是对外的
我亦有设计内网详细的数据分析网站，但是这一部分实际上需要根据自己的量化策略去进行定制，且一旦公开存在策略泄露的风险，所以不在此处披露。
另外一提，交易后的数据处理，以及前端代码，都是以实现功能为主，所以并不注重性能等其他指标，可参考最下方faq
服务器如何更新到前端数据的文件，主要原理是利用阿里云oss作为中间件，隔离数据风险
其中的tradesUpdate.py为更细trade记录，需要你在下单的时候先调用webServer的begin_trade_record接口插入交易数据
请注意这个接口的设计是基于我自身的需求，因为每个人的量化模型，参数等不同，需要研究的也不一样，所以建议这一块自己重写
positionRecord.py主要记录每分钟的账户余额和持仓价值 ，服务于下面的文件
webOssUpdate.py会整理数据，上传到oss，web前端则从oss中读取数据，并且会整理交易流水记录，形成一个以天为单位的统计表格，该处只是简单的统计了盈利和手续费，你可以自行扩展。
币安涉及到api key的接口的处理包，是从币安官网推荐的github下载后，进行了二次改造的版本
通用配置，需要自行配置mysql数据库，以及申请飞书api key等
通用方法
在数据库中生成trade_symbol表格，该表格将控制系统可执行交易的交易对信息
向trade_symbol表格录入交易对信息
此处进行了一些特殊处理，主要是适应我方的情况，包括只录入usdt的交易对，不录入指数类型的交易对（如btcdom，football这类型）
此处大部分字段为配合另一个项目，专业手操工具而设计，用于量化的数据字段实际上只有symbol，status
一个最基础的交易演示程序，当某个交易对，持仓价值为0且一分钟涨幅>1%的时候开多，当他持仓价值>0且一分钟跌幅小于-0.5%平多
如果你是新手，建议关注updateSymbolInfo()这个函数，价格精度，数量精度，最大平仓数量应该是新手会遇到最多的问题。
< 8000 div class="markdown-heading" dir="auto">