探讨模拟炒股的架构

Question

 开发一个模拟炒股项目。用户购买股票的时候，如果达到买入条件则直接成交；如果达不到买入条件则进入委托撮合系统进行等待撮合，卖出也一样。那么在进入委托待撮合过程中用户可能会进行撤单操作，也即不想买或卖股票（此时如果果撮合系统正在处理该笔单据，那么就锁定禁止用户撤本单，然后用户如果刚好要撤本单检测到系统正在撮合的锁，就SQL存储过程延迟检测撮合有无成功，没成功就允许撤单操作，否则就提示系统已经撮合成功。）。那么考虑到股票行情的实时性（3~~~6秒有新行情推算过来），那么该如何进行设计整个撮合系统。备注：
 用户买入、卖出的操作界面是Web 平台，撮合系统和行情系统都是服务器上面的WindowsForm程序。那么直接该怎么设计消息机制进行通知？或怎么把这个撮合系统架构弄的更好。

Answer 1

比如是用一个字段表达状态（比如有“正在等待撮合、正在进行撮合、正在撤单、撮合完成”等值），SQL Server的数据库操作全都是在事务控制内的，所以不可能一方面一个客户正在update这个记录的状态字段值，同时其它客户也update这个记录。对于多个表来处理它也是一样。假设用户开始撮合，那么系统就把数据记录从用户数据表移动到撮合数据表，这个事务未完成之前不可能同时另外一个用户又能把它同时移动回来。在1秒钟之后，事务提交，客户端系统才能继续处理数据。
这都是基本的数据库编程，谈不上架构这个概念。

Answer 2

另外，系统撮合是系统后台另外进行撮合，非用户什么在Update 然后用户又回来进行Update.
可能我对这个要求没写清楚，您没理解全对业务逻辑。数据库设计方面也很早就已经考虑你说的那个额外字段来辨识锁状态。

Answer 3

请大家可以先看看这个别人写的处理框架
============================
http://linkwis.blog.163.com/blog/static/99555230200942801643811/

Answer 4

你并没有说明白“锁”是什么流程。跟撮合操作没有关系，数据库用来记录状态而已。数据库记录又不是内存中的可执行代码。所以update只是针对修改状态而言的。你只是谈到了“锁”，其它的未谈及。这怎么会有“架构”概念出来呢？做架构是很具体的。我们给出测试用例，是具体的数据，然后拿来测试。如果通过了测试，就不去改变代码。如果没有通过测试，才去修改代码或者数据库设计。久而久之，上百个关键的测试用例综合在一起，自然形成了固定的“架构”。没有测试用例（也就是没有具体的测试数据设计），就根本不需要去修改你的程序代码。