0%

发表于 更新于 分类于

我的微信公众号：pyquant

概念

股指期货（Stock Index Futures）的全称是股价指数期货，也可称为股价指数期货、期指，是指以股价指数为标的物的标准化期货合约，双方约定在未来的某个特定日期，可以按照事先确定的股价指数的大小，进行标的指数的买卖。期货分为商品期货和金融期货，股指期货属于金融期货，作为期货交易的一种类型，股指期货交易与普通商品期货交易具有基本相同的特征和流程。

主要作用

  1. 规避投资风险

    当投资者不看好股市,可以通过股指期货的套期保值功能在期货上做空,锁定股票的账面盈利,从而不必将所持股票抛出,造成股市恐慌性下跌

  2. 套利

    所谓套利，就是利用股指期货和现货指数基差在交割日必然收敛归零的原理,当期货升水超过一定幅度时通过做空股指期货并同时买入股指期货标的指数成分股，或者当期货贴水超过一定幅度时通过做多股指期货并同时进行融券卖空股票指数ETF，来获得无风险收益。

  3. 降低股市波动性

    股指期货可以降低股市的日均振幅和月线平均振幅,抑制股市非理性波动,比如股指期货推出之前的五年里沪深300指数日均振幅为2.51%月线平均振幅为14.9%,推出之后的五年里日均振幅为1.95%月线平均振幅为10.7%,双双出现显著下降

  4. 丰富投资策略

    股指期货等金融衍生品为投资者提供了风险对冲工具，可以丰富不同的投资策略，改变目前股市交易策略一致性的现状，为投资者提供多样化的财富管理工具，以实现长期稳定的收益目标。

风险

除了金融衍生产品的一般性风险外，由于标的物自身的特点和合约设计过程中的特殊性，股指期货还具有一些特定的风险。

基差风险

基差是某一特定地点某种商品的现货价格与同种商品的某一特定期货合约价格之间的价差。基差=现货价格-期货价格。

合约品种差异造成的风险

合约品种差异造成的风险，是指类似的合约品种，如日经225种股指期货和东京证券股指期货，在相同因素的影响下，价格变动不同。表现为两种情况：
1〉是价格变动的方向相反。
2〉是价格变动的幅度不同。类似合约品种的价格，在相同因素作用下变动幅度上的差异，也构成了合约品种差异的风险。

标的物风险

股指期货的标的物是市场上各种股票的价格总体水平，由于标的物设计的特殊性，是其特定风险无法完全锁定的原因。从套期保值的技术角度来看，商品期货、利率期货和外汇期货的套期保值者，都可以在一定期限内，通过建立现货与期货合约数量上的一致性、交易方向上的相反性来彻底锁定风险。而股指期货由于标的物的特殊性，使现货和期货合约数量上的一致仅具有理论上的意义，而不具有现实操作性。因为，股票指数设计中的综合性，以及设计中权重因素的考虑，使得在股票现货组合中，当股票品种和权数完全与指数一致时，才能真正做到完全锁定风险，而这在实际操作中的可行性几乎是零。因此，股指期货标的物的特殊性，使完全意义上的期货与现货间的套期保值成为不可能，因而风险将一直存在。

交割制度风险

股指期货采用现金交割的方式完成清算。相对于其他结合实物交割进行清算的金融衍生产品而言，存在更大的交割制度风险。如在利率期货交易中，符合规格的债券现货，无论如何也可以满足一部分交割要求。股指期货则只能是百分之百的现金交割，而不可能以对应股票完成清算。

规则制度

合约价值

沪深300和上证50一个点是300元，中证500是200元

保证金

投资者在进行期货交易时，必须按照其买卖期货合约价值的一定比例来缴纳资金，作为履行期货合约的财力保证，然后才能参与期货合约的买卖。这笔资金就是我们常说的保证金。

买卖一手股指期货合约占用的保证金比例一般为合约价值的10%-20%(具体由交易所规定)，自20170918起中金所将保证金比例调整为15%，假如沪深300指数为3900点，相当于3900*300*15%=17.5万元，但在开户时账户上必须有50万的资金，完成开户验资过后留够一手保证金加上一定的余额即可，所以大致需要20万以上的资金，而中证50期指大致需要50万资金，上证50期指大致需要15万的资金。

手续费

在正常情况下手续费为合约价值的万分之零点七，比如20150302沪深300指数点位为3600点，手续费为万分之零点七，即3600*300*0.00007=75元，

20170918起平今仓手续费调整为万分之六点九，假设沪深300指数为3900点，当天买入且当天卖出一手沪深300期指需要付出3900*300*0.00069=807元的手续费，平昨仓手续费依然是万分之零点七，即昨天买入今天卖出一手沪深300期指的手续费为3900*300*0.00007=82元，等同于变相抑制T+0。

结算制度

每日无负债结算制度也称为“逐日盯市”制度，简单说来，就是期货交易所要根据每日市场的价格波动对投资者所持有的合约计算盈亏并划转保证金账户中相应的资金。

期货交易实行分级结算，交易所首先对其结算会员进行结算，结算会员再对非结算会员及其客户进行结算。交易所在每日交易结束后，按当日结算价格结算所有未平仓合约的盈亏、交易保证金及手续费、税金等费用，对应收应付的款项同时划转，相应增加或减少会员的结算准备金。

交易所将结算结果通知结算会员后，结算会员再根据交易所的结算结果对非结算会员及客户进行结算，并将结算结果及时通知非结算会员及客户。若经结算，会员的保证金不足，交易所应立即向会员发出追加保证金通知，会员应在规定时间内向交易所追加保证金。若客户的保证金不足，期货公司应立即向客户发出追加保证金通知，客户应在规定时间内追加保证金。投资者可在每日交易结束后上网查询账户的盈亏，确定是否需要追加保证金或转出盈利。

交易规则

  • 交易时间: 周一至周五，上午：9:30-11:30，下午：13:00-15:00

  • 涨跌幅: 上一个交易日收盘价的±10%

  • 最大下单数

    中金所暂时规定限价指令每次最大下单数量为20手，市价指令每次最大下单数量为10手,进行投机交易的客户单个合约的最大持仓限额为5000手,单个账户日内交易超过20手视为过度交易行为，套期保值交易开仓数量和持仓数量不受此限.

  • 合约代码

    • 沪深300股指期货：IF
    • 中证500股指期货：IC
    • 上证50股指期货：IH

  • 合约类型

    • 当月现货合约
    • 下月
    • 下季
    • 隔季

    随着每个月的交割以后，进行一次合约的滚动推进。比如在九月份，就具有九月、十月、十二月和次年三月四个合约进行交易，在十月底需要对十月合约进行交割。

  • T + 0

    T+0即当日买进当日卖出,没有时间和次数限制,而T+1即当日买进,次日卖出,买进的当日不能当日卖出,当前期货交易一律实行T+0交易,大部分国家的股票交易也是T+0的,我国的股票市场由于历史原因而实行T+1交易制度。

  • 卖空

    股指期货合约可以十分方便地卖空，等价格回落后再买回。股票融券交易也可以卖空，但难度相对较大。当然一旦卖空后价格不跌反涨，投资者会面临损失。

  • 合约交割

    股票买入后可以一直持有，正常情况下股票数量不会减少。但股指期货都有固定的到期日，到期就要进行平仓或者交割。因此交易股指期货不能象买卖股票一样，交易后就不管了，必须注意合约到期日，以决定是平仓，还是等待合约到期进行现金结算交割。

    沪深300指数期货会在每个月第三个星期五交割，并且以沪深300现货指数截止15:00之前两个小时的算术平均价作为交割结算价，所以不论平时期货和现货的基差有多大，沪深300指数期货最终必然会强制向沪深300现货指数收敛归零，导致期货会紧跟现货指数，具有很强的联动性，就好比小狗跟着主人散步时一样，小狗有时候会跑在主人前面，有时会在主人后面，但最终前进方向是由主人决定的，套利机制就是那根狗绳。

  • 合约结算

    股指期货合约采用保证金交易，一般只要付出合约面值约10-15%的资金就可以买卖一张合约，这一方面提高了盈利的空间，但另一方面也带来了风险，因此必须每日结算盈亏。买入股票后在卖出以前，账面盈亏都是不结算的。但股指期货不同，交易后每天要按照结算价对持有在手的合约进行结算，账面盈利可以提走，但账面亏损第二天开盘前必须补足（即追加保证金）。而且由于是保证金交易，亏损额甚至可能超过你的投资本金，这一点和股票交易不同。

基差

股指期货合约与对应股票指数之间的价差，基差=现货价格-期货价格，当期货价格高于现货被称为升水，当期货价格低于现货价格被称为贴水，比如20160302 IF1603股指期货的价格为3009点，沪深300指数为3051点，基差为3051-3009=42点，2015年度沪深300股指期货主力合约与现货指数的平均基差为±1.5%，这是不太正常的，原因在于国内融资与融券的比例失衡，国外的融资和融券比例一般为3:1，而国内达到300:1以上，融资融券比例失衡致使融券套利机制无法发挥正常作用，会导致基差出现偏差。

持仓量

多头和空头尚未平仓的合约总数，比如20160302 IF1603合约的持仓量为3.87万手，2015年沪深300股指期货单边日均持仓量13万手，占用的(双边)保证金规模约500亿元，假设其中一半的空单是套期保值盘则对应的股票市值约700亿元，而沪深300指数300只成分股的股票总市值达20万亿以上，也就是说依靠股指期货对冲风险的股票占比还不到1%，说明国内股指期货的规模依然不够大，需降低门槛让更多的中小投资者能够参与进来.2012年，2013年，2014年，2015年，2016年每月月末平均持仓量分别为78300手，102000手，164000手，131000手，44000手，2012年成交持仓比为5.5，2013年为7.9，2014年为5.4，2015年为8.6，2016年为0.39。

参与主体

套期保值者、投机者、套利者

主要策略

1. 套期保值

股指期货套期保值和其他期货套期保值一样，其基本原理是利用股指期货与股票现货之间的类似走势，通过在期货市场进行相应的操作来管理现货市场的头寸风险。

由于股指期货的套利操作，股指期货的价格和股票现货（股票指数）之间的走势是基本一致的，如果两者步调不一致到足够程度，就会引发套利盘入这种情况下，那么如果保值者持有一篮子股票现货，他认为当前股票市场可能会出现下跌，但如果直接卖出股票，他的成本会很高，于是他可以在股指期货市场建立空头，在股票市场出现下跌的时候，股指期货可以获利，以此可以弥补股票出现的损失。这就是所谓的空头保值。

另一个基本的套期保值策略是所谓的多头保值。一个投资者预期要几个月后有一笔资金投资股票市场，但他觉得如今的股票市场很有吸引力，要等上几个月的话，可能会错失建仓良机，于是他可以在股指期货上先建立多头头寸，等到未来资金到位后，股票市场确实上涨了，建仓成本提高了，但股指期货平仓获得的的盈利可以弥补现货成本的提高，于是该投资者通过股指期货锁定了现货市场的成本。

2. 投机交易

股市指数期货提供了很高风险的机会。其中一个简单的投机策略是利用股市指数期货预测市场走势以获取利润。若预期市场价格回升，投资者便购入期货合约并预期期货合约价格将上升，相对于投资股票，其低交易成本及高杠杆比率使股票指数期货更加吸引投资者。他们亦可考虑购入那个交易月份的合约或投资于恒生指数或分类指数期货合约。

3. 套利

针对股指期货与股指现货之间、股指期货不同合约之间的不合理关系进行套利的交易行为。股指期货合约是以股票价格指数作为标的物的金融期货和约，期货指数与现货指数（沪深300）维持一定的动态联系。但是，有时期货指数与现货指数会产生偏离，当这种偏离超出一定的范围时（无套利定价区间的上限和下限），就会产生套利机会。利用期指与现指之间的不合理关系进行套利的交易行为叫无风险套利（Arbitrage） ，利用期货合约价格之间不合理关系进行套利交易的称为价差交易（Spread Trading）。

Python量化交易实战
欢迎您扫码订阅我的微信公众号: pyquant

发表于 更新于 分类于

我的微信公众号：pyquant

概念

虚拟合约是合约交易的买卖对象，是由合约交易所统一制定的，规定了某一特定的时间交割一定数量商品的标准化合约。

OKEX的合约是OKEX推出的以BTC/LTC等币种进行结算的虚拟合约产品，每一张合约分别代表100美元的BTC，或10美元的其他币种（LTC,ETH等）,投资者可以通过买入做多合约来获取虚拟数字货币价格上涨的收益，或通过卖出做空来获取虚拟数字货币收益。合约的杠杆倍数为10或20倍。

OKEX在设计虚拟合约时做了相应的调整，每一张合约代表价值100美元的比特币，这样的设计使得虚拟合约的杠杆倍数始终稳定在一个固定值，从而利于套保和套利。

OKEX比特币虚拟合约的杠杆表现为法币收益层面的杠杆稳定：投入100美元，所能得到的收益=100美元 * 比特币的涨跌幅 * 固定的杠杆倍数。

合约类型

目前OKEX根据合约时间长短提供三种合约交易，分别是当周、次周、季度。

  • 当周合约：指在距离交易日最近的北京时间周五下午4点进行交割的合约。
  • 次周合约：指在距离交易日最近的北京时间第二个周五下午4点进行交割的合约。
  • 季度合约：指交割日为3,6,9,12月中距离当前最近的一个月份的北京时间最后一个周五下午4点进行交割的合约。

新合约将于交割日当日下午16:10开始交易

合约品种

BTC面值为100美元，报价时的最小变动单位为0.01美元,其他币种合约的面值为10美元，报价时的最小变动单位为0.001美元

BTC、LTC、ETH、ETC、BCH、XRP、EOS、BTG

交易规则

买入开多，卖出开空，买入平空，卖出平多

开仓:

未实现盈亏的计算公式：多仓未实现盈亏=（合约面值 / 结算基准价 - 合约面值 / 当前价格）* 持仓数量； 空仓未实现盈亏=（合约面值 / 当前价格 - 合约面值 / 结算基准价）* 持仓数量

平仓:

已实现盈亏的计算公式：多仓已实现盈亏=（合约面值 / 结算基准价 -合约面值 /平仓价格） * 平仓数量； 空仓已实现盈亏=（合约面值 / 平仓价格-合约面值 /结算基准价）* 平仓数量

风控规则

  • 全仓保证金制度、逐仓保证金制度、限价爆仓制度
  • 全仓保证金制度与逐仓保证金制度，投资者二者只能选其一
  • 全仓保证金: 当用户选择全仓保证金时，用户转入虚拟合约账户的所有余额，所有合约产生的盈亏都将作为合约的持仓保证金

全仓保证金模式下，开仓的要求是10倍杠杆开仓后，保证金率不低于90%，20倍杠杆开仓后，保证金率不低于80%

所有虚拟合约账户中的BTC和LTC都将作为虚拟合约持仓的保证金，保证金数量将会随价格变化而变动。当虚拟合约价格朝着不利于投资者方向运动时，账户权益即会发生损失。当用户的保证金率变为0%时，账户即被爆仓，此时被爆仓的用户的损失接近或等于其虚拟合约账户中的所有资产。用户通过转入保证金和开仓合约的数量调整时机杠杆倍数。转入的保证金越多，开仓的合约数量越少，虚拟合约的实际杠杆倍数即越小，越不容易被爆仓。

用户的保证金率=用户所有保证金/用户持仓所需的保证金-调整系数。在10倍杠杆时，合约的调整系数=10%，20倍杠杆时，合约的调整系数=20%；当保证金率小于等于0时，账户将被爆仓，所有仓位将被限价强平，未能强平的委托将在交割时进行爆仓分摊

  • 逐仓保证金制度：

    用户在合约开仓时所需要的保证金作为虚拟合约持仓的固定保证金，当虚拟合约价格发生变化时，保证金数值不发生变化。当虚拟合约价格朝向不利于用户方向运动时，未实现盈亏将发生损失。当用户的该合约该仓位的保证金率((固定保证金+未实现盈亏) * 开仓均价 * 杠杆 / (合约面值 * 持仓数量) - 调整系数；10倍杠杆，合约的调整系数=10%；20倍杠杆，合约的调整系数=20%，保证金率小于等于0%时，该合约的该仓位将被爆仓，此时被爆仓的用户损失接近或等于其该合约该方向仓位下的固定保证金。

采用逐仓保证金模式时，每个合约的双向持仓将会独立计算其保证金和收益，只有开仓可用保证金大于等于开仓所需的保证金数量，用户才能进行委托。而逐仓保证金时，每个合约的开仓可用保证金可能不一致。

委托方式

1. 计划委托

计划委托指令指的是预先设置委托和触发条件，当最新的成交价格达到事先设定的触发价格时，即会将事先设置的委托送入市场。

2. 跟踪委托

跟踪委托指的是在行情发生较大幅度回调的情况下，将客户事先设定的委托送入市场的策略。当市场的最新价格达到投资者设定该策略后最高（最低）市场价格的（1±客户设定回调幅度）后，即会触发客户设定的策略，将客户事先设定的委托送入市场中。

3. 冰山委托

冰山委托指的是投资者在进行大额交易时，为避免对市场造成过大冲击，将大单委托自动拆为多笔委托，根据当前的最新买一/卖一价格和客户设定的价格策略自动进行小单委托，在上一笔委托被全部成交或最新价格明显偏离当前委托价时，自动重新进行委托。

4. 时间加权委托

时间加权委托指的是客户希望大额交易BTC时，为避免过大冲击成本，通过策略将大单拆细为多个小额委托，根据最新的对手方委托量自动选择委托量，主动与对手方成交进行连续买入的策略。

保证金制度

  • 10倍
  • 20倍

手续费

开仓和平仓都征收手续费；若 maker 的手续费为负数，意味着您主动挂单为合约提供流动性，平台将赠送您手续费。合约交割手续费不受用户等级影响(BTC收取0.015%，非BTC收取0.05%)；爆仓导致的平仓不收手续费。

等级 近30天交易量(BTC) 挂单成交手续费 吃单成交手续费

Lv1 <10000 0.03% 0.05%

Lv2 ≥10000 0.025% 0.045%

Lv3 ≥20000 0.02% 0.04%

Lv4 ≥30000 0.015% 0.035%

Lv5 ≥60000 0.01% 0.03%

Lv6 ≥100000 0.005% 0.025%

Lv7 ≥200000 0% 0.02%

Lv8 ≥300000 -0.01% 0.02%

借币利息

  • 计息规则：单笔借币订单独立计息。借币成功时首次计息，之后满24小时计息一次。每满15天，系统将未还清借币进行复息结算（未还利息计入下一阶段本金中），并开始下一阶段计息。

  • 还币规则：优先还最早生成的借币订单。优先还利息，再还本金。单笔借币订单的本金和应还利息全部还清后，单笔借币订单状态转换为已还清，随后此订单不再计息。

借币日息usdt eth btc 0.1%，其他0.02%，不满一天按一天算

爆仓

用户资产：本金+已借-已产生的利息

负债：所有“已借”资产

风险率=用户资产/负债

当风险率跌到130%将有短信提示接近爆仓水平；当风险率跌到110%单仓将被强平。

风险率：评估币币杠杆账户爆仓风险的指标。当风险率≥150%时，账户中多余的资产部分可通过资金划转转出；当风险率≤130%，风险率评估为风险，系统会给用户发短信提示风险；当风险率≤110%，系统将强制爆仓，并发短信告知用户。

风险率计算公式：风险率=[(计价货币总资产-计价货币未还利息)/最新成交价+(交易货币总资产-交易货币未还利息)]/(计价货币借入资产/最新成交价+交易货币借入资产)*100%

爆仓：当某币币杠杆账户的风险率≤110%时，系统会执行爆仓操作，使用该账户内所有资产去偿还借币债务。

爆仓风险率=110%

预计爆仓价格：在OKEx.com每一笔借币均须交纳一定比例的保证金，当市场发生不利变化，比如市场发生行情逆转，朝相反方向变化时，当前币币杠杆账户总资产缩水到一定限度时，系统会强制将该币币杠杆账户资产按市场最优价格以挂单形式卖出清算借币以及利息。

预计爆仓价格计算公式：预计爆仓价格=(计价货币借入资产*爆仓风险率+计价货币未还利息-计价货币总资产)/(交易货币总资产-交易货币未还利息-交易货币借入资产*爆仓风险率)

其他

合约限价机制

  • 新合约生成10分钟内：最高价=现货指数（1+5%），最低价=现货指数（1-5%）。
  • 合约生成了10分钟后：最高价=近10分钟溢价平均值+现货指数（1+3%）,最低价=近10分钟溢价均值+现货指数（1-3%），溢价=合约价格-现货价格。
    若计算后的价格超过最高偏离度的现货指数25%或价格小于0，则最高价=现货指数（1+25%），最低价=现货指数（1-25%）。
  • 以上规则，开平仓都受限制，若开多或平空，当委托价高于最高价，则将触发限价；若开空或平多，当委托价低于最新价，则将触发限价。

术语

清算已实现盈亏：

每周五下午4:00会进行清结算，需要每个合约的本周已实现盈亏结转到用户余额中，此部分金额可以用于开仓和提现。

清算未实现盈亏：

每周五下午4:00会进行清结算，若用户持有次周，季度合约的仓位，则需将仓位中未实盈亏结转到已实现盈亏中。

爆仓平多/平空：

逐仓：当用户将仓位中的”已用保证金“亏完时，则该仓位会被爆仓，系统将该持仓进行强制平仓.

全仓：当用户将账户权益（存入金额+已实现盈亏+未实现盈亏）亏损完后，系统将用户的所有持仓进行强制平仓。

交割平多/交割平空：

当合约到期时（如每周五下午4:00当周合约到期），系统以最近一小时现货指数的算术平均值作为交割价对所有开仓的合约进行交割平仓，交割平仓后产生的盈亏部分加入已实现盈亏。

爆仓平仓剩余：

当用户爆仓时，系统会按爆仓价格进行强制平仓，但在撮合成交时可能与爆仓价格有所偏差，价格偏差所导致的盈余则称之为爆仓平仓剩余。

穿仓分摊：

当市场行情波动较大，用户爆仓后，按照爆仓价格无法成交时，导致亏损范围大于保证金。因此OKEX平台采用“分摊”制度，从本周盈利的用户中，每个人等比例分摊穿仓部分的损失。

合约爆仓问题

https://support.okex.com/hc/zh-cn/articles/360000139652-合约爆仓问题

合约结算交割问题

交割规则有关于穿仓的介绍

https://support.okex.com/hc/zh-cn/articles/360000105511-合约结算交割问题

Python量化交易实战
欢迎您扫码订阅我的微信公众号: pyquant

发表于 更新于 分类于

一维零投资组合

先对股票按因子大小排序， nt是top，nb是bottom，nb中停牌的股票跳过停牌的股票，已纳入的股票如果停牌的也不能调出且需要保留仓位

公式一：每只股票期末收益累加除以股票数
公式二：计算零投资组合当期收益
公式三：计算累计收益，把第一期净值作为1，连成每期收益率，最后减去1






关键点

  • PE -> EP，使取值空间连续
  • 停牌
  • 复权（后复权）

自定义股票池

调仓周期

Python量化交易实战
欢迎您扫码订阅我的微信公众号: pyquant

发表于 更新于 分类于

最近在处理数字货币行情数据，使用websocket接收行情数据写入磁盘，发现运行时间久了偶尔出现socket close的异常，重试多次无效后程序异常退出，所以考虑将python程序作为linux 守护进程运行，了解了supervisord和systemd，决定使用更强大的systemd。

基本概念

systemd 是一个 Linux 系统基础组件的集合，提供了一个系统和服务管理器，运行为 PID 1 并负责启动其它程序。功能包括：支持并行化任务；同时采用 socket 式与 D-Bus 总线式激活服务；按需启动守护进程（daemon）；利用 Linux 的 cgroups 监视进程；支持快照和系统恢复；维护挂载点和自动挂载点；各服务间基于依赖关系进行精密控制。systemd 支持 SysV 和 LSB 初始脚本，可以替代 sysvinit。除此之外，功能还包括日志进程、控制基础系统配置，维护登陆用户列表以及系统账户、运行时目录和设置，可以运行容器和虚拟机，可以简单的管理网络配置、网络时间同步、日志转发和名称解析等。

systemd架构图

常用工具

  • systemd-analyze: 查看启动耗时
  • systemctl: 用来查看系统状态、启动停止服务，在systemctl参数中添加-H <用户名>@<主机名>可以实现对其他机器的远程控制。该过程使用ssh链接
  • journalctl: Systemd统一管理所有Unit的启动日志

unit

一个单元配置文件可以描述如下内容之一：系统服务(.service)、挂载点(.mount)、sockets(.sockets) 、系统设备(.device)、交换分区(.swap)、文件路径(.path)、启动目标(.target)、由 systemd 管理的计时器(.timer)

如何编写服务脚本


[Unit]

Description=Network Manager

Wants=network.target

Before=network.target network.service

                                                                                                                                                                               

[Service]

Type=dbus

BusName=org.freedesktop.NetworkManager

ExecStart=/usr/sbin/NetworkManager --no-daemon

# NM doesn't want systemd to kill its children for it

KillMode=process

 

[Install]

WantedBy=multi-user.target

Alias=dbus-org.freedesktop.NetworkManager.service

Also=NetworkManager-dispatcher.service

整个文件分三个部分，[Unit]·[Service]·[Install]

  • [Unit]：记录unit文件的通用信息。

  • [Service]：记录Service的信息

  • [Install]：安装信息。

Unit主要包含以下内容：

● Description：对本service的描述。

● Before, After：定义启动顺序，Before=xxx.service，代表本服务在xxx.service启动之前启动。After=xxx.service,代表本服务在xxx之后启动。

● Requires: 这个单元启动了，那么它“需要”的单元也会被启动; 它“需要”的单元被停止了，它自己也活不了。但是请注意，这个设定并不能控制某单元与它“需要”的单元的启动顺序（启动顺序是另外控制的），即 Systemd 不是先启动 Requires 再启动本单元，而是在本单元被激活时，并行启动两者。于是会产生争分夺秒的问题，如果 Requires 先启动成功，那么皆大欢喜; 如果 Requires 启动得慢，那本单元就会失败（Systemd 没有自动重试）。所以为了系统的健壮性，不建议使用这个标记，而建议使用 Wants 标记。可以使用多个 Requires。

● RequiresOverridable：跟 Requires 很像。但是如果这条服务是由用户手动启动的，那么 RequiresOverridable 后面的服务即使启动不成功也不报错。跟 Requires 比增加了一定容错性，但是你要确定你的服务是有等待功能的。另外，如果不由用户手动启动而是随系统开机启动，那么依然会有 Requires 面临的问题。

● Requisite：强势版本的 Requires。要是这里需要的服务启动不成功，那本单元文件不管能不能检测等不能等待都立刻就会失败。

● Wants：推荐使用。本单元启动了，它“想要”的单元也会被启动。但是启动不成功，对本单元没有影响。

● Conflicts：一个单元的启动会停止与它“冲突”的单元，反之亦然。

Service主要包含以下内容：

● Type：service的种类，包含下列几种类型：

----simple 默认，这是最简单的服务类型。意思就是说启动的程序就是主体程序，这个程序要是退出那么一切都退出。

-----forking 标准 Unix Daemon 使用的启动方式。启动程序后会调用 fork() 函数，把必要的通信频道都设置好之后父进程退出，留下守护精灵的子进程

-----oneshot种服务类型就是启动，完成，没进程了。

notify,idle类型比较少见，不介绍。

● ExecStart：服务启动时执行的命令，通常此命令就是服务的主体。

------如果你服务的类型不是 oneshot，那么它只可以接受一个命令，参数不限。

------多个命令用分号隔开，多行用 \ 跨行。

● ExecStartPre, ExecStartPost：ExecStart执行前后所调用的命令。

● ExecStop：定义停止服务时所执行的命令，定义服务退出前所做的处理。如果没有指定，使用systemctl stop xxx命令时，服务将立即被终结而不做处理。

● Restart：定义服务何种情况下重启（启动失败，启动超时，进程被终结）。可选选项：no, on-success, on-failure,on-watchdog, on-abort

● SuccessExitStatus：参考ExecStart中返回值，定义何种情况算是启动成功。

eg：SuccessExitStatus=1 2 8 SIGKILL

Install主要包含以下内容：

● WantedBy：何种情况下，服务被启用。

eg：WantedBy=multi-user.target（多用户环境下启用）

● Alias：别名

例子

新建文件 /etc/systemd/system/huobi.service

内容如下:

[Unit]
Description=huobi downloader
After=rc-local.service

[Service]
Type=simple
User=root
Group=root
WorkingDirectory=/usr/lib/code/atom
ExecStart=/home/ubuntu/anaconda3/bin/python3.6 exchange/downloader.py huobi /data2/huobi/huobi.log
Restart=always

[Install]
WantedBy=multi-user.target

观察系统日志，发现程序异常退出后systemd重启的了服务

root@ip-172-31-4-62:/usr/lib/code/atom#  journalctl -u huobi.service
-- Logs begin at Mon 2018-03-26 17:51:39 CST, end at Thu 2018-03-29 16:39:27 CST. --
Mar 29 10:58:46 ip-172-31-4-62 systemd[1]: Started huobi downloader.
Mar 29 11:02:18 ip-172-31-4-62 systemd[1]: huobi.service: Main process exited, code=killed, status=9/KILL
Mar 29 11:02:18 ip-172-31-4-62 systemd[1]: huobi.service: Unit entered failed state.
Mar 29 11:02:18 ip-172-31-4-62 systemd[1]: huobi.service: Failed with result 'signal'.
Mar 29 11:02:18 ip-172-31-4-62 systemd[1]: huobi.service: Service hold-off time over, scheduling restart.
Mar 29 11:02:18 ip-172-31-4-62 systemd[1]: Stopped huobi downloader.
Mar 29 11:02:18 ip-172-31-4-62 systemd[1]: Started huobi downloader.
Mar 29 11:29:58 ip-172-31-4-62 python3.6[9124]: Traceback (most recent call last):
Mar 29 11:29:58 ip-172-31-4-62 python3.6[9124]:   File "./exchange/ex_huobi.py", line 66, in dispatch
Mar 29 11:29:58 ip-172-31-4-62 python3.6[9124]:     raw_data = await ws.recv()
Mar 29 11:29:58 ip-172-31-4-62 python3.6[9124]:   File "/home/ubuntu/anaconda3/lib/python3.6/site-packages/websockets/protocol.py", line 323, i
Mar 29 11:29:58 ip-172-31-4-62 python3.6[9124]:     raise ConnectionClosed(self.close_code, self.close_reason)
Mar 29 11:29:58 ip-172-31-4-62 python3.6[9124]: websockets.exceptions.ConnectionClosed: WebSocket connection is closed: code = 1006 (connection
Mar 29 11:29:58 ip-172-31-4-62 systemd[1]: huobi.service: Service hold-off time over, scheduling restart.
Mar 29 11:29:58 ip-172-31-4-62 systemd[1]: Stopped huobi downloader.
Mar 29 11:29:58 ip-172-31-4-62 systemd[1]: Started huobi downloader.
Mar 29 13:30:44 ip-172-31-4-62 python3.6[19180]: Traceback (most recent call last):
Mar 29 13:30:44 ip-172-31-4-62 python3.6[19180]:   File "./exchange/ex_huobi.py", line 66, in dispatch
Mar 29 13:30:44 ip-172-31-4-62 python3.6[19180]:     raw_data = await ws.recv()
Mar 29 13:30:44 ip-172-31-4-62 python3.6[19180]:   File "/home/ubuntu/anaconda3/lib/python3.6/site-packages/websockets/protocol.py", line 323,
Mar 29 13:30:44 ip-172-31-4-62 python3.6[19180]:     raise ConnectionClosed(self.close_code, self.close_reason)
Mar 29 13:30:44 ip-172-31-4-62 python3.6[19180]: websockets.exceptions.ConnectionClosed: WebSocket connection is closed: code = 1006 (connectio
Mar 29 13:30:45 ip-172-31-4-62 systemd[1]: huobi.service: Service hold-off time over, scheduling restart.
Mar 29 13:30:45 ip-172-31-4-62 systemd[1]: Stopped huobi downloader.
Mar 29 13:30:45 ip-172-31-4-62 systemd[1]: Started huobi downloader.

参考

https://wiki.archlinux.org/index.php/systemd_(简体中文)

https://www.hi-linux.com/posts/3761.html

https://blog.csdn.net/fu_wayne/article/details/38018825

Python量化交易实战
欢迎您扫码订阅我的微信公众号: pyquant

发表于 更新于 分类于

我的微信公众号：pyquant

逐笔成交：

交易过程中的单次成交，是交易过程的真实成交情况。这是Level-2的专有数据，用一个实例来解释这个概念：假设目前的卖一是10元、100手，这时有人以10元委托买入100手，那么这100手是如何成交的呢？这要取决于卖盘由几个委托单构成，如果卖一是一个委托单，那就是一笔成交，即100手；而如果卖一是由40手和60手两笔委托构成，那么这100股就会分成两次成交，即40手一次，60手一次，逐笔成交就是2笔。

一般显示的数据格式为在几分几秒以多少价格分几笔成交了多少手。在这里我们要注意的是成交手数有时候是带小数点的，这是因为股票买进的股数最少是100股，委托的股数也应是100的整数倍，卖出却没有限制，因此成交的手数会有小数点。 另外一点就是如果在成交价格和手数前面没有显示，则一半是默认的1笔。

分笔/分时成交：

3-5秒一次的行情采集期间累计的成交量和最后的成交价，可能是几笔成交的集合。这是大家长期以来唯一能看到的成交数据.

一般显示的数据格式为在几分几秒以多少价格成交了多少手。**这里需要注意的是成交手数永远是整数，不会出现小数点数字。**其中现手累计数就是总手数。总手数也叫做成交量。有些软件在现量后面标注蓝色S和红色B，前者代表卖，后者代表买。（软件自己根据时间估计主动买还是主动卖）

目前市面上出现了LEVEL-2行情数据，比较具有代表性的是大智慧，在那里把分笔成交是叫分时成交，实际上就是我们在普通分析软件上F1看到的“分笔成交明细”，但是他和LEVEL-2行情数据提供的逐笔成交明细是不一样的。**分笔数据由于是合成混合数据，它是以最后1笔的买卖方向来表示该时间内（3秒或者5秒）的买卖方向。**目前市面上的成交明细数据都是分笔成交，有些号称是LEVEL-2逐笔的明细数据其实也是分笔，即LEVEL-2行情软件里右侧小窗口显示的3秒分笔数据，虽然来自LEVEL-2行情，但仍然是分笔（分时）成交，而不是LEVEL-2行情软件里左侧显示的逐笔成交。因为左侧显示的逐笔成交在LEVEL-2行情软件里是不能保存的，也不能够导出供二次开发。能够导出的只有右侧小窗口里的分笔成交

逐单/委托单：

我们每次向系统发出委托时，都有个委托合同编号，这个就是单。例如你一次买2000股股票，则是20手，那么这一单就是20手。但目前每种软件的推测统计都不一致，会导致不同软件显示数据出现差异。

委托单的明细，这是交易所行情系统中没有发布的数据，还以刚才的例子说明，交易所只发出了40手和60手两笔成交（逐笔），并没有指出是一笔100手的买单吃掉了40手、60手两笔卖单。LEVEL-2行情能够根据成交的时间和队列等数据计算出全部已成交的委托单明细，这在交易分析中具有重大意义。（股票盘子越大，推测逐单数据误差越大,因为委托队列只显示前50个委托单;相对来说小盘股的DDE指标更为可靠）

分时:

一般指一分钟成交集合;

问题：

盘中数据的统计分析长期以来是对分时数据的统计分析，比如最简单的内盘和外盘，大单买入/卖出等，这种统计有两个明显的缺陷：

第一、仅统计了主动成交方单方面的成交数据，而机构交易完全可能在被动成交方

第二、分时数据不是真实的成交数据，大单不一定是大单，可能是很多散户在几秒中之内同时交易的结果，虽然使用level-2的逐笔成交来统计可以避免这一情况的发生，但立即就又产生了新的问题，即一笔真实的大单委托往往被分割成数笔成交，又捕捉不到真实的大单了。

其他：一个孤独的数字是缺乏意义的，但是一些连续的数字则是充满想像的。一般来说，成交手数比较大而集中的时候，表示有大资金活跃迹象，该股出现价格异动的概率就大，应该引起投资者的注意。而如果半天也没人买或者都是一些小单子在交易，则至少短期不大可能成为好股。

Python量化交易实战
欢迎您扫码订阅我的微信公众号: pyquant

发表于 更新于 分类于

比特币介绍

比特币（BitCoin）的概念最初由中本聪在2009年提出，根据中本聪的思路设计发布的开源软件以及建构其上的P2P网络。比特币是一种P2P形式的数字货币。点对点的传输意味着一个去中心化的支付系统。

货币特征

  • 去中心化：比特币是第一种分布式的虚拟货币，整个网络由用户构成，没有中央银行。去中心化是比特币安全与自由的保证 。
  • 全世界流通：比特币可以在任意一台接入互联网的电脑上管理。不管身处何方，任何人都可以挖掘、购买、出售或收取比特币。
  • 专属所有权：操控比特币需要私钥，它可以被隔离保存在任何存储介质。除了用户自己之外无人可以获取。
  • 低交易费用：可以免费汇出比特币，但最终对每笔交易将收取约1比特分的交易费以确保交易更快执行。
  • 无隐藏成本：作为由A到B的支付手段，比特币没有繁琐的额度与手续限制。知道对方比特币地址就可以进行支付。
  • 跨平台挖掘：用户可以在众多平台上发掘不同硬件的计算能力。

比特币与分叉币比较

什么是挖矿

比特币是怎么产出的？

首先我们来了解一下“区块链”，比特币的核心原理是“区块链”，每一个区块对应一个帐单，将所有的区块链接起来就是区块链，任何交易信息和转账记录都记录在区块链中。要注意的是区块链存在于整个互联网中，所以任何比特币持有者都不担心比特币遭受损失。

每隔一个时间点，比特币系统会在系统节点上生成一个随机代码，互联网中的所有计算机都可以去寻找此代码，谁找到此代码，就会产生一个区块，随即得到一个比特币，这个过程就是人们常说的挖矿。

挖矿设备介绍

现在市面上起码有几百种加密货币，主流的可以流通交易的也有不下20种。这么多的加密货币虽然都基于区块链技术，但不管是为了实现某些功能，还是为了形成差异，都会有所不同，从而导致挖不同的币使用的矿机也有所不同。通常来说，一台矿机只能挖一种或几种币，所以要挖什么比就要买什么型号的矿机。当然也存在全能选手，比如电脑就是，只是好多币种用电脑（CPU+显卡）挖的效率太低，无法盈利。

矿机可以有多种分类方式，硬件上可以分为ASIC矿机、GPU矿机、FPGA矿机，以及玩客云那类CDN矿机等等。按照所有权划分，可以分为本地矿机和云矿机。

首先，比特币（BTC）、以太坊（ETH）、比特币现金（BCH）、莱特币（LTC）、达世币（DASH）等主流币种，普遍采用PoW共识机制，挖矿就是通过贡献算力来维护网络安全、稳定的运行，并由此获得奖励币，所以都需要性能尽可能强大的矿机。但针对不同币种的算法，又细分出两种不同的矿机：ASIC矿机与GPU矿机。

中本聪打造比特币的时候，希望比特币是一个去中心化的货币，不仅使用、交易如此，挖矿也应该如此。但是事与愿违，随着比特币等加密货币的价值越来越高，挖矿成为了一个产业，竞争越来越激烈，对挖矿算力的追求越来越高，所以从普通电脑挖矿，进化出了ASIC矿机与GPU矿机。

主流矿机比较

目前市场上最热门的矿机是蚂蚁矿机S9，具体配置如下

矿池的选择

矿池的选择主要考虑以下两个因素：

  • 分配模式
  • 手续费

分配模式说明：

  1. Slush方式

Slush矿池基于积分制，较老的shares将比新的shares拥有更低的权重，以减少一轮中切换矿池的投机分子。
2. Pay-Per-Share方式

该方式为立即为每一个share支付报酬。该支出来源于矿池现有的比特币资金，因此可以立即取现，而不用等待区块生成完毕或者确认。这样可以避免矿池运营者幕后操纵。这中方法减少了矿工的风险，但将风险转移给了矿池的运营者。运营者可以收取手续费来弥补这些风险可能造成的损失
3. Luke-Jr方式

该方式借用了其他方式的长处，如Slush方式一样，矿工需要提供工作证明来获得shares，如puddinpop方式一样，当区块生成时马上进行支付。但是不象之前的方式，针对一个区块的shares，会被再次利用于生成下一个区块。为了区分一下参与矿工的交易传输费用，只有当矿工的余额超过1BTC时才进行支付。如果没有达到1BTC，那么将在下一个区块生成时进行累计。如果矿工在一周内没有提供一个share，那么矿池会将剩下的余额进行支付，不管余额是多少。
4. Triplemining方式

该方式是将一些中等大小矿池的计算力合并起来，然后将获得奖励的1%按照各个矿池计算力的比例分发给矿池运营者。
5. P2Pool方式

P2Pool的挖矿节点工作在类似比特币区块链的一种shares链上。由于没有中心，所以也不会受到DoS攻击。和其他现有的矿池技术都不一样—每个节点工作的区块，都包括支付给前期shares的所有者以及该节点自己的比特币。99%的奖励（注：50BTC+交易费用）会平均分给矿工，另外0.5%会奖励给生成区块的人。
6. Puddinpop方式

一种使用“元哈希”技术的方式，使用特定的puddinpop挖矿软件，现在没有矿池用这种方式

注意：

一个share（注：贡献/股份）为一个矿池给客户端的一个合法的工作证明，这也同时是用来生成区块的工作证明，但是没有这么复杂，只需要很少的时间就能达到一个share。

收益预测

蚂蚁矿机单机价格18000元，功率为1350w - 1512w，电费按0.3元/度计算，收益情况如下

计算方式1

矿池算力排名
https://btc.com/stats/pool?pool_mode=day

每十分钟产生一个区块，每个区块12.5个比特币，每天全球产生12.5*24*6=1800BTC

s9算力13.5T，当前全网算力22.52EH/s，1E=1024P,1P=1024T,1T=1024G,一台s9一天产生的比特币是[13.5/(22.5210241024)]*1800≈.001029054BTC

总收入

13.5/(22.52*1024*1024) * 1800 * 65000 * 365 = 24414.295 元

每天耗电36度，每年13140度电，电费约为 1.5*24*0.3 * 365 = 3942 元

总利润为 24414.295 - 3942 = 20472.295 元

计算方式2

挖矿算器

https://btc.com/tools/mining-calculator

参考

http://www.kuangjijia.com/category/492.html
https://shop.bitmain.com/productDetail.htm?pid=00020180205094056650FrOW7847062D
https://www.zhihu.com/question/20792042

挖掘机哪家强？主流矿机比拼，蚂蚁矿机领先
http://www.sohu.com/a/155209866_114877
彩云评测：比特大陆蚂蚁S9比特币挖矿机
https://www.cybtc.com/article-2338-1.html
一个挖矿者血本无归的教训总结
http://www.hnr.cn/finance/zt/b/df/201706/t20170626_2980454.html

Python量化交易实战
欢迎您扫码订阅我的微信公众号: pyquant

发表于 更新于 分类于

我的微信公众号：pyquant

区块链的价值是共识

共识算法其实分很多种，目前最常提到的，比特币和以太坊所用到的，是叫做POW的共识算法，基于工作量证明的一种信息保障的算法。

POW共识算法，效率低下

POW目前的局限是出块速度被限定了，比特币差不多10分钟出一个区块，所有交易均需要记录在区块内，所以这样也就限制了交易频率，由于一个区块只有1M，可以承载的交易信息是有限的，所以目前比特币的交易频次被限定在非常低的量级上，差不多一秒才可以支撑不到10个交易。

升级方案：

  • 提升出块大小，比特现金把区块大小提升到了8M区块
  • 提升出块速度，降低出块奖励
  • 区块分片化存储的方案，现在比特币这样的区块链虽然是去中心化分布式存储，但每个全节点存储的是记录全集，也就是规模总量和本地查询明显是受到制约的。
  • 闪电网络是指将小额的，频繁交易，先通过一些分支节点进行储存和计算，并在一定时间内整合归并到主链

以太坊是平台

以太坊可以认为是区块链的第二代平台，因为对智能合约的支持，以太坊的应用想象空间增加了很多，而且其出块效率也明显高于比特币。交易结算周期也明显有了更好的表现。

以太坊是一个平台，上面跑了几千种虚拟货币，其中之一是以太坊自身的代币。而这个平台不但可以发布货币，还可以发布应用，智能合约的应用

智能合约

在区块中传递的合约，或者说传递的字符串，不是单纯的字符串和信息，而是一段可执行的脚本，比如说，有触发条件，有交互能力。

比特币是资产还是货币？

硬分叉

硬分叉，是分叉方约定，在某个区块节点开始，启用新的系统架构继续前进，不再和主链保持一致，但同时也继承了该节点之前的所有区块。在这个节点之后，双方各自挖各自的矿，各自爆各自的块，各自走各自的路

其实硬分叉不需要主链允许或通过，任何人都可以发起硬分叉，都可以基于自己的理解和判断发起一个新的分支，但对于信仰者来说，每个分叉都是对共识的撕裂，是在破坏共识。共识算法本身就是防范故障或者恶意分叉的，而人为强行分叉显然是算法所不能处理的。

EOS

99%的ICO是基于以太坊的，其实EOS的ICO，目前而言，也是基于以太坊的。但EOS要做的并不只是躺在以太坊身上薅点韭菜的钱。他们的野心还是蛮大的，按照白皮书的说法，感觉是想成为第三代区块链的平台，

零知识证明

可以有效保护交易隐私，隐藏交易来源并防止追溯，同时也能保证交易是安全的，因为任何试图修改交易的行为都无法通过验证。

信息安全

第一，算力劫持，其实共识算法并非是完美无瑕的，其存在的假设前提是，大部分节点是正确的，可信任的。所以不同的共识算法，理论上都存在一些风险，就是如果坏人掌握了足够多的节点。比如说基于POW共识的比特币，如果一家矿场或者矿池掌握了超过全网51%的算力，理论上可以劫持所有交易，改变交易数据。而基于DPOS的需要保障2/3的节点是可靠的，否则也存在强行分叉或者干扰主链的风险。

第二，重放攻击，这是硬分叉首先需要小心解决的问题，如果系统设计不周全，会导致在分叉上执行的交易被复制到主链，从而带来币拥有者未确认的交易发生，造成损失。所以很多交易所和钱包服务商，不敢去支持名目繁多的分叉币，也是担心由此带来风险。

第三，关于私钥安全，由于新入场的区块链玩家很多，实际上很多人并不明白区块链私钥的意义和价值，会出现这样的情况，认为在交易所，或者钱包的账号和密码是最关键的，保护好了账号密码就万无一失，但糊里糊涂就被人钓鱼，把私钥拱手送出。

第四，交易平台和钱包工具的安全，这在历史上出现过很多起，最近也出现过，一些交易所失窃，或者钱包工具失窃，导致用户的币丢失，而且基本上全都无可挽回。

第五，智能合约的安全，有一个基于区块链众筹的风险投资基金，叫做the DAO，这个众筹计划是用一段智能合约代码约束的，这段代码被发布到了网上，并募集了超过数亿美元的资金，看上去是一个非常不错的故事，但很遗憾，这段代码中有一个安全风险，结果，黑客通过代码漏洞轻松劫持了超过5500万美元

回顾

1、共识算法是区块链的核心技术；
2、当前的共识算法存在一些问题，是区块链应用场景普及所需要面对的重大问题。
3、从比特币到以太坊，实际上区块链的技术方案正在演进，但谁是第三代，目前还有待争议。
4、智能合约是区块链应用场景扩展最具有想象力的地方，不过受限于基础架构和算力问题，目前智能合约还很难做出复杂应用，图灵完备在当前阶段尚不具备应用意义。
5、零知识证明还没有全面应用起来，但这个逻辑被认可度是非常高的。
6、共识算法，零知识证明，都是人类数学和信息科学的重大进步，并不单纯是为区块链服务的，更不是为发币的骗子们服务的。
8、信息安全在区块链投资中的重要性非常高，而目前绝大部分新入场的用户对此并没有足够清醒的认识，整个区块链产业出现的严重安全事故已经很多起了，入局者希望能引以为诫。

代币

现在主要有两种模式，一种是跟法币绑定的，一个很神奇的东西，叫做USDT，是香港一家公司发行的，他宣称 ，每发行一个USDT，背后都有1美元的储蓄作为担保，并且有多个商业银行担保。也就是和美元1：1购买，1：1赎回，那么他的商业模式是什么呢？赎回的时候收取1%的手续费。

Python量化交易实战
欢迎您扫码订阅我的微信公众号: pyquant

发表于 更新于 分类于

安装gitlab-runner

https://docs.gitlab.com/runner/install/index.html

国内镜像地址

https://mirrors.tuna.tsinghua.edu.cn/help/gitlab-ci-multi-runner/

注册Runner

https://docs.gitlab.com/runner/register/

步骤

注意：用户为root用户

root@sw:/home/sw# gitlab-runner register xuqi
Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://10.168.2.114/

Please enter the gitlab-ci token for this runner:

输入gitlab的token

Please enter the gitlab-ci description for this runner:
[sw]: xuqi
Please enter the gitlab-ci tags for this runner (comma separated):

Whether to lock the Runner to current project [true/false]:
[true]: true
Registering runner... succeeded                     runner=wzb81TcG
Please enter the executor: docker, parallels, shell, virtualbox, docker+machine, kubernetes, docker-ssh, ssh, docker-ssh+machine:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

注意： token位置在http://localhost/xxx/xxx/settings/ci_cd 页面里的Runners settings里

如何删除在gitlab中不再使用的runner

gitlab-runner verify --delete

关于executors的选择

https://docs.gitlab.com/runner/executors/README.html

如何编写.gitlab-ci.yml

官方文档

https://gitlab.com/help/ci/yaml/README.md

stages

stages用来定义可以被job调用的stages。stages的规范允许有灵活的多级pipelines。

Jobs

.gitlab-ci.yml允许指定无限量jobs。每个jobs必须有一个唯一的名字，而且不能是上面提到的关键字。job由一列参数来定义jobs的行为

demo

image: python:3.6.1

before_script:
   - export BIZDATE=`date +%Y%m%d`
   - export PROJECT_NAME=$CI_PROJECT_NAME
   - export VERSION=$CI_COMMIT_TAG-$CI_COMMIT_SHA

stages:
  - build
  - package
  - deploy

build:
  stage: build
  script: 
    - /home/gitlab-runner/anaconda3/bin/python3.6 -O -m compileall .
    - find . -name '*.pyc' -exec rename 's/.cpython-36.opt-1//' {} \;
    - find . -name '*.pyc' -execdir mv {} .. \;
    - find . -name '*.py' -type f -print -exec rm {} \;
    - find . -name '__pycache__' -exec rm -rf {} \;
    
package:
  stage: package
  script:
    - rm -rf .git
    - rm -rf .gitlab-ci.yml
    - $(tar -zcf ../deploy-$VERSION.tar.gz .)
    - $(mkdir -p /home/gitlab-runner/backup/$PROJECT_NAME/$BIZDATE)
    - $(cp ../deploy-$VERSION.tar.gz /home/gitlab-runner/backup/$PROJECT_NAME/$BIZDATE/)
    - $(rm -rf ../deploy-$VERSION.tar.gz)
    - rm -rf .

deploy:
  stage: deploy
  script:
    - echo 'deploy'

服务器版本，使用脚本编写如上内容

before_script:
   - export PROJECT_NAME=$CI_PROJECT_NAME
   - export VERSION=$CI_COMMIT_TAG-$CI_COMMIT_SHA
   - export WORK_DIR=`pwd`
   - export HOST=''

stages:
  - deploy

deploy:
  stage: deploy
  only:
    - /^release-.*$/
  script:
    - ~/script/deploy.sh $WORK_DIR $HOST

deploy.sh 脚本内容

workdir=$1
BIZDATE=`date +%Y%m%d`
echo $workdir
cd $workdir
rm -rf .git
rm -rf .gitlab-ci.yml
tar -zcf ../bak-$VERSION.tar.gz .
mkdir -p /home/gitlab-runner/backup/$PROJECT_NAME/$BIZDATE
cp ../bak-$VERSION.tar.gz /home/gitlab-runner/backup/$PROJECT_NAME/$BIZDATE/
rm -rf ../bak-$VERSION.tar.gz
/home/gitlab-runner/anaconda3/bin/python3.6 -O -m compileall .
find . -name '*.pyc' -exec rename 's/.cpython-36.opt-1//' {} \;
find . -name '*.pyc' -execdir mv {} .. \;
find . -name '*.py' -type f -print -exec rm {} \;
find . -name '__pycache__' -exec rm -rf {} \;
#rm -rf $1/*

tar -zcf ../deploy-$VERSION.tar.gz .
for line in `cat hosts`
do
   pem=`echo $line | cut -d \: -f 1`
   host=`echo $line | cut -d \: -f 2`
   echo $pem
   echo $host
   scp -i ~/keys/$pem ../deploy-$VERSION.tar.gz ubuntu@$host:/home/ubuntu/
done
echo 'finish'

参考

https://scarletsky.github.io/2016/07/29/use-gitlab-ci-for-continuous-integration/

https://segmentfault.com/a/1190000010442764

Python量化交易实战
欢迎您扫码订阅我的微信公众号: pyquant

发表于 更新于 分类于

Filled相关Order类型：

  1. Market Order

    • 当订单规模很大时，broker可能会将订单拆分成多个规模较小的订单，导致以不同价格成交不同订单
    • bid-ask spreads 较大时风险较大

  2. Limit Order

    • Some brokers may charge different commissions between Market & Limit Orders.

  3. Market On Close(MOC) Order

    A Market-on-Close (MOC) order is a market order that is submitted to execute as close to the closing price as possible.

  4. Limit On Close(LOC) Order

    A Limit-on-close (LOC) order will be submitted at the close and will execute if the closing price is at or better than the submitted limit price.

  5. Market On Open(MOO) Order

    A Market-on-Open (MOO) order combines a market order with the OPG time in force to create an order that is automatically submitted at the market’s open and fills at the market price.

  6. Limit On Open(LOO) Order

    A Limit-on-Open (LOO) order combines a limit order with the OPG time in force to create an order that is submitted at the market’s open, and that will only execute at the specified limit price or better. Orders are filled in accordance with specific exchange rules.

  7. Martet To Limit(MTL) Order

    A Market-to-Limit (MTL) order is submitted as a market order to execute at the current best market price. If the order is only partially filled, the remainder of the order is canceled and re-submitted as a limit order with the limit price equal to the price at which the filled portion of the order executed.

  8. Iceberg/Reserve Orders

    提交大额股票、权证、期货和期权定单的投资者可能希望取消其定单的所有欲交易量以避免其他市场参与者可以预见并采取相应行动。冰山/保留属性（可在显示尺寸区域设置）可以帮助投资者以增量方式提交提交大宗定单，同时又只公开显示整体定单尺寸的某一特定部分。客户可以通过设置布局管理者或选择相应的区域向TWS的交易页面添加显示尺寸区域，输入定单时客户可以填充此项以显示整个定单的一部分。

    Investors submitting large volume orders for stocks, warrants, futures and options may wish to conceal the full size of their order to avoid anticipatory action from other market participants. The Iceberg/Reserve attribute, applied through the Display Size field, provides a way to submit large volume orders to the market in increments while publicly displaying only a specified portion of the total order size. The Display Size field can be added to a trading page within TWS by configuring the Layout Manager and selecting the appropriate field, which can be user-populated at the time of order input, to display just a fraction of the entire order.

TIMING / DURATION：

档提交一个订单后，当我们希望订单在指定时间内有效或订单的持续时间，可以使用如下订单类型

  1. Day Order

    A day order is an order to buy or sell a security that automatically expires if not executed on the day the order was placed. If it is not filled, it is canceled, and it is not filled if the limit or stop order price was not met during the trading session. It is one of several different order duration types that determines how long the order is in the market before it is canceled.

  2. Good Till Cancelled(GTC)

    A good 'til canceled (GTC) order can be placed by an investor to buy or sell a security at a specified price that remains active until it is either rescinded by the investor or the trade is executed. GTC orders offer an alternative to placing a sequence of day orders, which expire at the end of each trading day. Rather than leave orders open ended, which poses the risk of being forgotten by investors until an eventual execution, GTC orders are commonly set to expire of 30 to 90 days after the trades are entered.

    • GTC Buy Orders
    • GTC Sell Orders

  3. Good Till Date/Time(GTD)

    The GTD (Good-til-Date/Time) time in force lets you select an expiration date and time up until which an order will continue to work. Setting this attribute requires both a time in force selection of GTD, a date entry in the Expiration Date field, and a time entry in the Expiration Time field if that level of detail is required. Note that if you only enter a good-till date, the unfilled order will cancel at the close of the market on the specified day.

  4. Time Of Day Order

    An order to buy or sell an asset that is placed at a specific time period during a trading session. A time-of-day order enters the market at a predetermined minute and remains good until canceled, unless otherwise specified.

CONTIGENCY ORDERS

如果我们希望订单在满足某些特定条件才执行的话，特别是当你无法一直监视市场的时候。
这些订单类型允许交易者在一定条件满足时自动开仓或平仓。

  1. Fill Or Kill(FOK): 全额即时订单

    全额即时订单也称为全部即刻执行否则撤销订单，指要求立即以特定的价格（通常只能为限价）予以执行，否则撤销订单。全额即时订单只能全部成交，而不能成交订单数量的一部分。

    Fill or kill (FOK) is a type of time-in-force designation used in securities trading that instructs a brokerage to execute a transaction immediately and completely or not at all. This type of order is most likely to be used by active traders and is usually for a large quantity of stock. The order must be filled in its entirety or canceled (killed).

  2. Fill And Kill(FAK): 非全额即时订单

    非全额即时订单指要求立即以特定的价格（可以为限价或市价）予以执行，否则撤销的订单。非全额即时订单允许部分成交，在部分成交时未成交的部分立刻撤销。

  3. Immediate Or Cancel(IOC)

    The Immediate-or Cancel (IOC) time in force applied to an order dictates that any portion of the order that does not fill immediately will be canceled.

  4. All Or None(AON)

    All or none (AON) is an instruction used on a buy or sell order that instructs the broker to fill the order completely or not at all. ** If there are not enough shares available to fill the order completely, the order is canceled when the market closes. ** An AON order is considered a duration order because the investor provides instructions to the trader about how the order must be filled, which impacts how long the order remains active.

For Automatic OPENING of a Position

  1. Market If Touched(MIT) Order

    触价指令是指市场价格只要触及客户所规定的价格水平时就生效的指令。当市场价格触及指定价格时才执行买进或卖出动作。

    A Market if Touched (MIT) is an order to buy (or sell) an instrument below (or above) the market. Its purpose is to take advantage of sudden or unexpected changes in share or other prices and provides investors with a trigger price to set an order in motion. Investors may be waiting for excessive strength (or weakness) to cease, which might be represented by a specific price point. MIT orders can be used to determine whether or not to enter the market once a specific price level has been achieved. This order is held in the system until the trigger price is touched, and is then submitted as a market order. An MIT order is similar to a stop order, except that an MIT sell order is placed above the current market price, and a stop sell order is placed below.

  2. Limit If Touched(LIT) Order: 触及限价定单

    触及限价定单是一种以特定或更优的价格，以及低于（或高于）市价的价格买入（或卖出）金融产品的定单。这类定单被持有在系统中直到触发价格被触及。触及限价定单与限价止损定单相似，除了触及限价卖出定单以高于当前市场价格被下达，而限价止损卖出定单则是以低于市价被下达的。
    使用触及限价定单帮助确保，如果定单被执行的话，定单将不会以劣于限价的价格执行。

For Automatic CLOSING of a Position

  1. Stop Order: 止损定单

    止损定单指令系统在用户指定的止损触发价格被达到提交一份买或卖的市价单。止损定单不担保某个特定的执行价格且有可能执行价格远离其止损价格。卖出止损定单总是以低于当前的市场价格下达，通常用于限制某个多头股票头寸的损失或保护其利润。买入止损定单总是以高于当前的市场价格下达，通常用于限制某个卖空头寸的损失或帮助其保护利润。

  2. Stop Limit Order: 止损限价单

    止损限价单指令系统在用户指定的止损触发价格被触碰或超越时提交一份买或卖限价单。该定单由两个基本部分组成：止损价和限价。当一笔交易以止损价或通过止损价发生时，定单成为可执行的并以限价单（以某个特定的价格或更好的价格买入或卖出的定单）的形式进入市场。
    止损限价单避免了止损单具有的价格风险（此风险是指不能担保执行价格），但投资人需承担即使在止损价格达到时定单仍不能执行的风险。投资人有可能完全“失去市场”。

  3. Trailing Stop Order: 追踪止损定单

    一个卖出追踪止损定单将止损价格设置为低于市场价格的一个固定金额，并带有附加的“追踪”金额。随着市场价格上涨，止损价格上涨的幅度为追踪金额，但如果股票价格下跌，止损价格不改变，当止损价格被触及时，一份市价定单将被提交。这种方法被设计用来允许投资者对可能损失的最大值指定限额，而不用对可能收益的最大值设定限额。“买入”追踪止损定单是卖出追踪止损定单的镜像，最适合用在下跌的市场中。

  4. Trailing Stop Limit Order: 追踪止损限价定单

    追踪止损限价定单允许投资者对可能损失的最大值指定限额，而不用对可能收益的最大值设定限额。追踪止损限价卖出定单与市场价格一起移动，并根据用户定义的“追踪”金额，连续地以低于市价的固定金额重新计算止损触发价格。限价定单价格同样根据限价抵消被连续地计算。随着市场价格上涨，止损价格和限价的上涨幅度分别为追踪金额和限价抵消，但如果股票价格下跌，止损价格保持不变，当止损价格被触及时，一份限价定单将以最后计算的限价被提交。追踪止损限价“买入”定单是追踪止损限价卖出定单的镜像，并通常被用在下跌的市场中。

More COMPLEX Types of Contingency Orders

  1. Conditional / Contingent Order

  2. Bracketed Order: 括号定单

    括号定单旨在通过用两个方向相反的定单将定单“括”起来以帮助您限制损失、锁定利润。给买单加括号，使用的是一份高位卖出限价定单和一份低位卖出止损定单。给卖单加括号，使用的是一份高位买入止损定单和一份低位买入限价定单。
    高位和低位括号定单的定单数量与最初的定单数量相匹配。默认情况下，括号定单从当前价格偏离1.0。您能够在特定定单的定单行上更改该偏离金额，也可使用全局配置中的定单预设功能修改产品、合约或策略的默认水平值。

  3. One Cancels Other(OCO) & One Cancels All(OCA) Orders

    A one-cancels-the-other order (OCO) is a pair of orders stipulating that if one order is executed, then the other order is automatically canceled. A one-cancels-the-other order (OCO) combines a stop order with a limit order on an automated trading platform. When either the stop or limit level is reached and the order executed, the other order will be automatically canceled. Seasoned traders use OCO orders to mitigate risk.
    one-Cancels All (OCA) order type allows an investor to place multiple and possibly unrelated orders assigned to a group. The aim is to complete just one of the orders, which in turn will cause TWS to cancel the remaining orders. The investor may submit several orders aimed at taking advantage of the most desirable price within the group. Completion of one piece of the group order causes cancellation of the remaining group orders while partial completion causes the group to rebalance. An investor might desire to sell 1000 shares of only ONE of three positions held above prevailing market prices. The OCA order group allows the investor to enter prices at specified target levels and if one is completed, the other two will automatically cancel. Alternatively, an investor may wish to take a LONG position in eMini S&P stock index futures in a falling market or else SELL US treasury futures at a more favorable price. Grouping the two orders using an OCA order type offers the investor two chances to enter a similar position, while only running the risk of taking on a single position.

  4. One Triggers Other(OTO) & One Triggers All(OTA) Orders

订单优先原则

  1. 价格优先原则

    价格优先原则指交易所（或做市商）在对投资者的订单进行撮合时，按照价格的高低原则进行排序，较高价格的买进订单优先于较低价格的买进订单，较低价格的卖出订单优先于较高价格的卖出订单。

  2. 时间优先原则

    按比例分配原则是指所有订单在价格相同的情况下，成交数量基于订单数量按比例进行分配。纽约证券交易所的大厅交易、芝加哥期权交易所等采取了按比例分配的订单优先原则。

  3. 按比例分配原则

    按比例分配原则是指所有订单在价格相同的情况下，成交数量基于订单数量按比例进行分配。纽约证券交易所的大厅交易、芝加哥期权交易所等采取了按比例分配的订单优先原则。

  4. 数量优先原则

    在价格一样、甚至价格一样且无法区分时间先后的情况下，有些交易所规定应遵循数量优先原则。数量优先原则而有两种形式，一是在订单价格相同且时间也相同的情况下，订单数量较大者优先于订单数量较小者；二是在数量上完全匹配的订单（即买进订单和卖出订单在数量上相等）优先于数量不一致的订单。第一种形式使得经纪商优先处理数量较大的订单，因而提高了流动性；第二种形式则减少了订单部分执行的情况。

  5. 客户优先原则

    客户优先原则通常指在同一价格条件下，公共订单优先于经纪商自营账户的订单。纽约证券交易所采取这一原则，客户的订单优先于专家的订单。客户优先原则减轻了客户与经纪商自营之间的利益冲突。

参考

https://www.interactivebrokers.com/cn/index.php?f=3361
https://www.zhihu.com/question/23667442

Python量化交易实战
欢迎您扫码订阅我的微信公众号: pyquant

发表于 更新于 分类于

资源

https://github.com/kennethreitz/awesome-coins

数据

  1. https://www.cryptocompare.com/api

Cryptocurrency data API for over 40 exchanges and 600 coins(BTC,ETH,XMR + 600 other cryptos)

Get open, high, low, close, volumefrom and volumeto from the each minute historical data. This data is only stored for 7 days, if you need more,use the hourly or daily path. It uses BTC conversion if data is not available because the coin is not trading in the specified currency

  1. https://bitcoincharts.com/about/markets-api/

Bitcoincharts’ API is accessable through HTTP
Parameters are passed using GET-requests
returned data is JSON encoded
Don’t query more often than once every 15 minutes!

Trade data is available as CSV, delayed by approx. 15 minutes. It will return the 2000 most recent trades.

  1. http://api.bitcoincharts.com/v1/csv/

  2. https://www.coinigy.com/bitcoin-data/

  3. https://www.quora.com/Where-can-I-get-per-tick-historical-bitcoin-price-data

  4. https://coinmarketcap.com/historical/

  5. https://github.com/CoinCapDev/CoinCap.io

  6. http://www.yucezhe.com/product/data#!?series=digital_currency

回测&交易

  1. https://github.com/CoinTK/CoinTK

Bitcoin Trading Algorithm Backtesting and Analysis Toolkit

  1. https://gekko.wizb.it/docs/introduction/about_gekko.html

A bitcoin trading bot written in node - https://gekko.wizb.it/

  1. https://cryptotrader.org/

  2. http://www.abuquant.com/lecture/lecture_10.html

比特币, 莱特币的走势数据分析 http://www.abuquant.com/

  1. https://github.com/ctubio/Krypto-trading-bot

Self-hosted crypto trading bot (automated high frequency market making) in node.js, angular, typescript and c++ https://127.0.0.1:3000

  1. https://www.kaggle.com/smitad/bitcoin-trading-strategy-simulation

API

Python

https://python-binance.readthedocs.io/en/latest/overview.html

binance

Java

https://github.com/timmolter/XChange

XChange is a Java library providing a streamlined API for interacting with 60+ Bitcoin and Altcoin exchanges providing a consistent interface for trading and accessing market data.

https://www.botvs.com/api

源码实现

https://github.com/bisq-network/exchange

The decentralized bitcoin exchange https://bisq.network

https://github.com/bitcoin/bitcoin

Bitcoin Core integration/staging tree

https://github.com/jamesob/tinychain

A pocket-sized implementation of Bitcoin

Python量化交易实战
欢迎您扫码订阅我的微信公众号: pyquant