多人操作数据的处理策略--讨论

用户故事如下：

电子商务后台管理，有多个客服人员可以操作同一个数据，当有的人正在对他进行修改的时候，其他人却觉得这个数据是垃圾数据，就直接删除了

如果是你，你在项目中如何处理这一小细节。

比如：当你载入订单修改的适合，有人已经把订单删除了，你去保存，不会有任何错误，反而操作成功

可以去数据库更新一个id不存在的字段，没有任何问题，只会
update  qqinfo set name='fdfd
' where id=90;

Query OK, 0 rows affected
Rows matched: 0  Changed: 0  Warnings: 0


我们目前策略如下：

对订单管理，很多工作人员都可以载入订单

特殊处理这个操作数据库的方法，设置一个字段--是否可用

可用才执行操作，操作的适合先把这个字段设为不可用

欢迎大家提出好的想法


----------------

非常谢谢大家的回复，第六页的 不知云 给出了很好的解决策略 大家可以看看

这贴就结了吧

评论

36 楼 nick.s.ni 2011-05-25  

railway 写道

yangyi 写道

railway 写道

yangyi 写道

railway 写道

rocketball 写道

szcs10138456 写道

小盆友们不用争了，先查询，加上乐观锁不就OK了。

这压根不是这个问题，主要是考虑后台操作人员工作重复，人家是通过这个统计工作量的

看到任务列表后，先把某笔任务申请下来（数据库表中记录申请人信息，便于统计工作量），申请成功则开始做该任务，如果不想做该任务，则可以释放，让别人去做。

这个是排它锁，和synchronized一样

这跟排它锁没什么关系，synchronized需要排队，而申请数据是将共用的数据申请为私有的数据，申请成功再进行操作，比如修改花了半个小时（由于是私有数据，别人无法操作，就不怕别人删除）；
修改数据或删除数据时，带有自己的用户信息（SQL的where条件中加入用户信息）。

就锁的本质效用而言是一样的，都需要排队访问临界区。唯一的区别可能就是是否block

我觉得楼主的困境应该在于两点：

1、B操作的数据可能被其他人操作了（甚至删除了）
    此时的解决方法是使用乐观锁，可以使用时间戳或者UUID。

2、工作量统计问题
   比如，A、B两人同时去操作同一数据（假设是填写复杂的表单），A花了30分钟去修改，B看了数据后，觉得没用，花了20秒钟的时间删除了它，因为B先提交，所以提交成功了（删除成功），而A不知道，还在那里卖力地填写，等到A提交的时候，提交失败，受影响的记录为0（Query OK, 0 rows affected），数据未保存。
  对于A来说，浪费了30分钟的时间去做“无意义”的事（结果未提交成功），如果要统计工作量的话，A这笔业务是无效的，如果一天下来，A倒霉地碰到了很多这样的情况，那要抓狂了，当然这不是A的原因，是系统设计的问题。

还有你的是删除的人权限大，还是修改的人权限大，如果是修改的权限大，那在修改的时候不能删除，反过来就是修改的时候可以删除。

如果是电子商务后台，订单肯定不会真的删除，应该只会修改某个字段进行判断。要有操作人员的记录。

还有就是实际情况，麻烦的是修改的时候可以删除，那删除的之后如何能及时通知前台还在修改的人员，B/S目前可以用
异步轮询，C/S 可以用JMS之类异步通信。

35 楼 skycray 2011-05-25  

Pessimistic Locking & Optimistic Locking..
但Optimistic可能不大复合LZ的情况...用Optimistic是意味着第二个修改的人会TransactionRollback

34 楼 spell 2011-05-25  

唉，这个是糟糕的设计导致的问题，有一些东西做出来是给一个人用的，不是大家可以一起用的。包括现在的很多商城，其实都有楼主所说的这个问题。

我的解决办法是，谁要处理特定的任务，先申领这条任务，每个人只可以处理自己申领或者主管分配给自己的任务，那不就OK了吗？从业务上彻底解决这个问题。表结构方面，增加user_id,处理情况等。刚开始user_id为空，分配给谁，这个user_id就记谁的，处理的时候先判断任务的user_id是不是目前登录的这个人，不是的话，不给处理。其实这个跟工作流的整合很有关系。

33 楼 TheMarine 2011-05-25  

如果一个系统的某资源对于a很重要，对于b不重要并且可以随意删除的话，这设计是何等的狗屎。a不会杀了b吧？另外删除的时候不要真删除，修改开关字段不就ok了？

32 楼 lovit 2011-05-25  

goooooon 写道

update时候判断sql%rowcount，更新不为1，就抛错误，保证数据一致，ok了

正解

31 楼 obullxl 2011-05-25  

对于特别敏感的数据，建议使用存储过程加乐观锁。

30 楼 lgsun592 2011-05-25  

如果你早一周提出此问题，那我上周五的面试通过的几率会大大的增加的，哎

29 楼 zjrstar 2011-05-25  

删除数据有点危险，应该设置数据的状态标志。如果某个工作人员觉得数据无用，可以给这行数据设置删除标志。这样下去库里面的数据量可能会增大。解决方案是定期删除库中设置了删除标志的数据。还有就是这种情况一定要采用乐观锁。更新的时候要检查数据的状态是否容许更新。

28 楼 xly_971223 2011-05-25  

加个乐观锁字段就ok了吧

27 楼 railway 2011-05-25  

yangyi 写道

railway 写道

yangyi 写道

railway 写道

rocketball 写道

szcs10138456 写道

小盆友们不用争了，先查询，加上乐观锁不就OK了。

这压根不是这个问题，主要是考虑后台操作人员工作重复，人家是通过这个统计工作量的

看到任务列表后，先把某笔任务申请下来（数据库表中记录申请人信息，便于统计工作量），申请成功则开始做该任务，如果不想做该任务，则可以释放，让别人去做。

这个是排它锁，和synchronized一样

这跟排它锁没什么关系，synchronized需要排队，而申请数据是将共用的数据申请为私有的数据，申请成功再进行操作，比如修改花了半个小时（由于是私有数据，别人无法操作，就不怕别人删除）；
修改数据或删除数据时，带有自己的用户信息（SQL的where条件中加入用户信息）。

就锁的本质效用而言是一样的，都需要排队访问临界区。唯一的区别可能就是是否block

我觉得楼主的困境应该在于两点：

1、B操作的数据可能被其他人操作了（甚至删除了）
    此时的解决方法是使用乐观锁，可以使用时间戳或者UUID。

2、工作量统计问题
   比如，A、B两人同时去操作同一数据（假设是填写复杂的表单），A花了30分钟去修改，B看了数据后，觉得没用，花了20秒钟的时间删除了它，因为B先提交，所以提交成功了（删除成功），而A不知道，还在那里卖力地填写，等到A提交的时候，提交失败，受影响的记录为0（Query OK, 0 rows affected），数据未保存。
  对于A来说，浪费了30分钟的时间去做“无意义”的事（结果未提交成功），如果要统计工作量的话，A这笔业务是无效的，如果一天下来，A倒霉地碰到了很多这样的情况，那要抓狂了，当然这不是A的原因，是系统设计的问题。

26 楼 yonghong915 2011-05-25  

正遇到这个问题，也在思考这个问题，如果并发量比较大怎么做呢？

25 楼 wuxianjun 2011-05-25  

1，数据库本身事务看你的事务策略。
2，业务事务，也就是订单在某个状态下有什么操作。如:订单删除只有取消未发货才能删除.多人同时载入的时候肯定只有一个人能操作成功，其他的抛业务异常就可以了。
删除时候，可以做逻辑删除。
3，并发操作可以加锁，如：悲观锁，乐观锁。

24 楼 songlixiao 2011-05-25  

1. 数据库表增加一个时间戳字段。
2. 查询显示数据时，将世界戳字段查询出，并带到表单中。
3. 表单修改提交后，时间戳字段一同提交，保存前校验此数据时间戳是否与数据库一致，不一致说明已经被别人修改，不允许执行操作。
4. 如果时间戳一致，将数据的时间戳赋予当前时间，并保存到数据库。

原则是所有人都可以查询，但是修改则只有在最后一个版本上修改的才算有效。

23 楼 kingkan 2011-05-25  

用时间戳，还要设置多久没提交该时间戳失效。

22 楼 goooooon 2011-05-24  

update时候判断sql%rowcount，更新不为1，就抛错误，保证数据一致，ok了

21 楼 yangyi 2011-05-24  

railway 写道

yangyi 写道

railway 写道

rocketball 写道

szcs10138456 写道

小盆友们不用争了，先查询，加上乐观锁不就OK了。

这压根不是这个问题，主要是考虑后台操作人员工作重复，人家是通过这个统计工作量的

看到任务列表后，先把某笔任务申请下来（数据库表中记录申请人信息，便于统计工作量），申请成功则开始做该任务，如果不想做该任务，则可以释放，让别人去做。

这个是排它锁，和synchronized一样

这跟排它锁没什么关系，synchronized需要排队，而申请数据是将共用的数据申请为私有的数据，申请成功再进行操作，比如修改花了半个小时（由于是私有数据，别人无法操作，就不怕别人删除）；
修改数据或删除数据时，带有自己的用户信息（SQL的where条件中加入用户信息）。

就锁的本质效用而言是一样的，都需要排队访问临界区。唯一的区别可能就是是否block

20 楼 railway 2011-05-24  

yangyi 写道

railway 写道

rocketball 写道

szcs10138456 写道

小盆友们不用争了，先查询，加上乐观锁不就OK了。

这压根不是这个问题，主要是考虑后台操作人员工作重复，人家是通过这个统计工作量的

看到任务列表后，先把某笔任务申请下来（数据库表中记录申请人信息，便于统计工作量），申请成功则开始做该任务，如果不想做该任务，则可以释放，让别人去做。

这个是排它锁，和synchronized一样

这跟排它锁没什么关系，synchronized需要排队，而申请数据是将共用的数据申请为私有的数据，申请成功再进行操作，比如修改花了半个小时（由于是私有数据，别人无法操作，就不怕别人删除）；
修改数据或删除数据时，带有自己的用户信息（SQL的where条件中加入用户信息）。

19 楼 yangyi 2011-05-24  

railway 写道

rocketball 写道

szcs10138456 写道

小盆友们不用争了，先查询，加上乐观锁不就OK了。

这压根不是这个问题，主要是考虑后台操作人员工作重复，人家是通过这个统计工作量的

看到任务列表后，先把某笔任务申请下来（数据库表中记录申请人信息，便于统计工作量），申请成功则开始做该任务，如果不想做该任务，则可以释放，让别人去做。

这个是排它锁，和synchronized一样

18 楼 yangyi 2011-05-24  

乐观锁，和ArrayList里面的ConcurrentModificationCount一样

17 楼 railway 2011-05-24  

rocketball 写道

szcs10138456 写道

小盆友们不用争了，先查询，加上乐观锁不就OK了。

这压根不是这个问题，主要是考虑后台操作人员工作重复，人家是通过这个统计工作量的

由于多人操作数据，数据是共用的，所以设立一个机制，做某笔数据前，先申请，申请成功再开始操作（修改、删除）。

看到数据列表后，先把某笔数据申请下来（数据库表中记录申请人信息，便于统计工作量），申请成功则开始做该任务，如果不想做该数据，则可以释放，让别人去做。

ps.如果要统计工作量，删除应该是逻辑删除。