业务数据并发互斥分析

在进行企业应用系统开发时，在多用户模式下，对各种业务数据如何避免并发操作引起数据异常是设计中非常重要的考量点。下面总结已遇到的一些场景及对应解决办法，并不完整全面。

场景：同时编辑同一业务数据

问题描述：

甲打开某业务数据编辑页眉，乙也打开此编辑页眉，甲乙先后执行保持操作。

如保存时不做控制，后保存者的数据覆盖先保存者的数据。

Ø  处理办法A：

打开编辑页眉后，保存业务数据时间戳，保存时检查是否一致，如不一致则提示，由用户选择是否保存。

优点：给以用户选择权。缺点：用户有时无法判断，可能造成数据异常。

注意事项：

当编辑页面包含子表的编辑和保存功能时，方案A很可能引起数据异常。除非子表的保存方法是先删除再新增。

 

Ø  处理办法B：

打开编辑页眉后，保存业务数据时间戳，保存时检查是否一致，如不一致则提示不允许保存。

 

Ø  处理办法C：

不做控制，仅记录保存时间和保存人员

 

  场景：在业务过程中改变业务数据的状态同时，业务数据发生改变

问题描述：

甲打开某业务数据进行审核，在其点击审核前，乙打开业务数据修改并先保持；

 

甲打开某业务数据进行审核，在其点击审核前，乙打开业务数据修改，甲点击审核后乙点击保存；

（业务数据的“审核”、“作废”或其他某特殊业务状态字段的改变均适用此场景）

Ø  处理办法A：

打开查看页面时，记录时间戳，审核时比较时间戳。保存业务数据时，同样比较时间戳，不同时不允许保存。

 

Ø  处理办法B：

将审核动作分为“提交审核”和“确认审核”两个步骤，提交审核后，不允许修改。

漏洞：甲提交审核页面动作发生前，乙打开修改页面，甲再确认审核，之后乙保存修改，如此则甲的审核操作从业务和数据状态上都有可能不正确。

 

Ø  处理办法C：

打开编辑页面时，记录业务状态值，保存时比较此值，如不同则不允许保存。

 

  场景：编辑的同时业务数据被删除

 

问题描述：

  甲打开业务数据进行编辑，乙将此数据删除，甲再进行保存动作

Ø  处理办法：

保存时，先检查该业务数据是否存在。通常是按ID取业务数据，判断是否存在，如存在则进行数据的修改和保存。

在不存在时，反馈客户相关信息，不允许保存。

 

  场景：业务关联数据被删除

问题描述：

  甲打开业务数据，此时业务数据中某一关联数据被删除，根据关联信息取不到关联数据的值。

甲编辑业务数据，选取某一关联数据，乙删除此关联数据，甲执行保持操作。

 

Ø  解决办法A：

通过数据库设置外键字段，在数据库层面避免数据异常。在程序中通过捕获异常来给以客户适当提示。

缺陷：依赖数据库，某种情况下会造成性能问题（备注1）；

备注1：假设A表被多张表设为外键关联，且关联表数据量大，则更新A表字段时有可能造成同时检查更新其他关联表，性能下降明显。

Ø  解决办法B：

对被关联的数据，从业务上不允许被删除

缺陷：代码量大，容易遗漏；

 

办法A和B可相互补充

 

场景：业务关联数据被修改

问题描述：

业务数据中，关联的数据被改，如合同表中的客户姓名本来为A，合同中保存客户表ID。之后客户表中A的名字被改为B。此时打开合同页面，客户名字变为B。

此场景的正确解决办法严重依赖于具体业务场景。如上例，假设修改客户名字的唯一途径就是修改客户表，可能上述现象是正常业务表现，假设合同中客户姓名不能随意被改动，上述现象就是数据异常。

 

Ø  解决办法A：

在修改客户姓名时，检查是否有关联合同，如有，则不允许修改，或设计另一页面（业务通道）来修改客户姓名。

缺陷：仅在关联及其强的情况下适用，代码量大，业务逻辑复杂。

 

Ø  解决办法B：

在合同中记录客户的姓名、联系方式等关键信息，实质上是通过冗余来避免关键信息被修改。同时提供同步客户信息表中相关字段的选择。

缺陷：仅在关联及其强的情况下适用，代码量大，业务逻辑复杂。

 

Ø  解决办法C：

不予处理，仅在实施时提示客户。