mysql撮合交易系统_这种简单的撮合交易系统思路合理不？

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

当一个请求(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后台，对着买卖盘数据列表，手动操作撮合，反正我这个也不是实时撮合的。

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