这种简单的撮合交易系统思路合理不?

现有一个简单的撮合系统思路,大神指点一下合理不。

交易系统

当一个请求(request)进入交易系统后,首先由用户系统(User)识别用户身份,然后由账户系统(Account)对用户资产进行冻结,买入冻结USD,卖出冻结BTC,冻结如果成功,订单被送入撮合引擎(Match)。

撮合引擎维护一个买卖盘列表,然后按时间、价格优先原则对订单进行撮合,能够成交的就输出成交结果,不能成交的放入买卖盘。

当撮合系统输出了成交结果后,该成交记录由清算系统(Clearing)进行清算。清算的工作就是把买单冻结的USD扣掉,并加上买入所得的BTC,同时,把卖单冻结的BTC扣掉,并加上卖出所得的USD。根据taker/maker的费率,向买卖双方收取手续费。

清算系统完成清算后,更新订单状态,再通知用户,用户就可以查询到买卖的成交情况。

订单系统是负责持久化数据,这里订单系统(Order),怎样规划表设计比较合理,

我想的是 有个买卖盘的表,记录买入,卖出数据。然后发给撮合系统,进行撮合,然后生成交易记录。应该有一个交易记录的表,保存交易数据。

这里的,买卖盘数据,是放在两个表(买入表,卖出表)里合理?还是放在一个表里合理,有一个订单类型来区分,是买入,还是卖出。

还有一个问题,这个撮合系统,感觉更像两个队列,一个买入队列,一个卖出队列。然后他们撮合起来。这里撮合的过程,用队列实现吗?

我这个客户要求,不实时撮合,封闭式撮合。撮合过程中,不允许,买卖盘下单。

我查到各个web用的语言php,net,java,都有队列组件,都可以实现队列。一般他们好像,都是单独开启一个进程,轮询执行任务。大致看了一下,实现比较复杂。

如果我用php这种,写一个循环算法这样可以不?就是取出买盘,取出卖盘。循环对比,能交易就交易,不能交易就不交易。这种的话,好像不能异步了,同步执行效率低。

或者我在服务器上面,单独写一个dos界面的脚本程序来撮合,这个脚本程序,可以用net,java写都可以。php应该也而可以dos脚本化执行。

还有一种是我在系统web后台,对着买卖盘数据列表,手动操作撮合,反正我这个也不是实时撮合的。

想用这种笨方法做,可以偷懒,但是做为程序猿来讲,我还是追求高效的撮合过程,成就感好。

阅读 3.5k
1 个回答

队列你就用rabbitmq就好了, 感觉没啥毛病 异步化,起个线程消费. 关键点是你的流程合理
订单表 还要有个订单详情表 ,下订单还得有订单日志表 我这边之前是这么设计

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题
宣传栏