并发和隔离是您在此处理的两个主题 – 多个用户同时使用系统并且每个工作不受其他人影响的能力. RDBMS通过隔离级别和锁来处理这个问题.它们是如何设计的;这就是他们所做的.我们作为应用程序架构师的工作是选择满足要求的设置,并以最小化冲突发生时间窗口的方式构建系统.
在此系统中,您需要Order表中的行与其他表之间的一致性.为此你需要锁.这正是锁的用途.不要害怕他们.他们是您的朋友并保护您的数据.对于参考表,您希望确保仅通过读取而不是写入来获取共享锁,最好是行锁.这样,多个并发活动可以共享参考数据.
编写订单将创建一个独占锁.希望只是在新的一排,但可能在桌子上.因此,尽可能在插入后尽快提交事务,以快速释放该锁是很重要的.
您不想要的是在代理键入时保留这些锁.这是计算机术语中的永恒.通过所有方式验证输入,因为它们键入但仅作为单个语句,从不在跨越整个数据输入会话的事务中.然后在结束时,保存订单时,启动一个事务,重新读取参考数据,插入订单并提交.在任何应该在几毫秒内完成的平台上.其他操作符甚至都不会注意到它的发生.如果出现错误或冲突,代理将立即得到反馈,他们可以更正并重新提交.
有一个替代方案,我不推荐,但为了这个利益而列在这里.您可以在异步的消息处理设计上构建系统.当代理保存数据时,它将写入单个临时表,每个数据值有一列.没有验证,没有标准化.一个插入和数据持续存在.有7个运算符,一次在DB中进行两次操作的几率几乎为零.第二个进程轮询此表以一次读取一行.它验证并写入规范化模式.记录结果 – 成功或失败.然后处理登台表中的下一行,依此类推.这保证了所有插入都是完全序列化的,代价是设计复杂得多,没有对代理的即时反馈以及需要额外的业务流程和编程来纠正错误.此外,这也不能防止连接到数据库的其他程序的活动.毕竟有些事情必须要阅读这些订单.正如我所说,不推荐.
七个同时输入数据的代理人数不是很多.我保证,你将能够构建一个系统来处理这个问题.