doc.go 3.1 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344
  1. // Copyright 2013-2014 Fuzamei tech Ltd. All rights reserved.
  2. // 本程序实现K线数据以及行情数据的存储和转发
  3. package market
  4. // 1.从交易所下载历史行情数据, 转换为基本的K线周期数据, 向客户端转发
  5. // 2.从交易所请求实时行情数据, 存储并转发给客户端
  6. // 3.定期下载最新历史数据, 比如10分钟, 保证有最新的数据
  7. // 4.客户端请求时, 向客户端推送实时行情数据
  8. // 5.服务器实现文件下载服务, 客户端请求的历史数据以文件的形式下发, 这样将来客户端增多时, 可以分流服务器压力
  9. // 实现需要注意的问题:
  10. // 1, 缓存:1)因为历史数据是连续的数据, 一般来说客户端通常下载最新的数据, 可以缓存少量最新数据, 让客户端请求马上相应.
  11. // 2)如果太多, 可能对内存占用过多, 可以通过配置调节
  12. // 2, 存储:1)历史tick数据
  13. // 2)每个文件的开始和结束时间以及文件路径存储到数据库, 便于查找, 管理.
  14. // 3)存储基本的周期:M1, M5, H1, D1周期. 秒周期可以通过tick转换.
  15. // 4)存储的格式直接为Tick和Candle数据, lmax gzip压缩保存;其他直接二进制保存(因为通过tick转换,累增的)
  16. // 3, 兼容:1)通过自定义数据源和产品Id兼容其它产品, 比如马币.
  17. // 2)抽象出产品, 行情, Tick和Candle等通用数据, Lmax, ctp或者马币转换到通用数据中.
  18. // 3)这样客户端可以不区分lmax还是马币, 只关心产品ID, 名字就行了.
  19. // 4, 带宽: 1)客户端没必要下载所有历史数据, 而是下载用于计算和显示的数据.
  20. // 2)计算也应该在服务器中完成, 使用rpc. 因为服务器有所有的数据.
  21. // 3)客户端每次下载的数量不宜过多, 300个Candle
  22. // 5, 部署:1)需要2台以上冗余备份. tickserver可以同时运行多个实例, 互不影响.
  23. // 2)单服务器可以支持1W客户端的连接, 考虑到带宽限制, 需要分机房部署, 并作负载均衡.
  24. // TODO
  25. // 1, ctp会挂掉,所以在每天8:45自动重启tickserver. 下一步准备只重启ctp的DS,这样不影响其他数据
  26. // 2, DS存储现在过于复杂, ds.go中RunSave()函数。主要是把过来的tick数据,按品种分别存储为tick,M1,M5,H1,D1等不同格式。
  27. // 每种数据必须保持时间顺序。现在是其他4种数据都是通过tick转换,改为tick-->M1-->M5-->H1-->D1方式可能更好一些,
  28. // 代码清晰,容错也应该好些
  29. // 3, 对于lmax下载增加配置参数, 控制并发下载的goroutine数量. 现在感觉如过并发过大, 可能会影响实时行情的速度, 行情数据出现卡顿的现象
  30. // 或者使用其他的账号来进行下载,和行情分开来. 怀疑lmax通过用户控制一些资源
  31. // 4, 添加ctp合约列表保存, 也就是每次重启Ctp,加载本地的合约列表。 连接ctp服务器,获取合约列表时,更新本地保存的列表。
  32. // 这样在周末重启,客户端仍然能够获取合约列表,进行历史技术分析