问大家一个Java逻辑问题？

  • Z时代
  • 2024-03-01
  • 分类：IT

现在项目里有个逻辑关于数据流程状态的，两个用户在各自客户端同一个审核页面操作更新同一条数据，用户A做审核通过，用户B再审核驳回。

现有的方案是两边接口都传待审核的状态过去给接口校验，用户B点的审核页可能会获取最新数据状态，但也要存下其他用户操作前的待审核状态，我觉着这太麻烦了不符合逻辑，直接接口里拿最新的数据状态和要操作的类型比对不就行了，大家怎么看这种逻辑是否合适？

回答：

是拿最新的数据状态，和当前要操作的类型进行比对

回答：

前端传要改变成的状态，后端校验当前状态是否能够改变，不能改变则返回相应错误信息，前端展示

回答：

很常见的多人编辑冲突问题。

常见的解决方案就那么几种，具体还是要结合业务场景来选择。

  1. 悲观锁：
    只能有一个人进入编辑状态，其他人等着。
    优点是能百分百确保不会出现编辑冲突。缺点就是用户体验很差，前一个人不主动释放，那所有人都得等着，只适合 Wiki 锁定编辑之类的场景。
  2. 乐观锁：
    每条数据记录一个版本信息（比如叫 row_version），客户端获取时拿到它，提交修改时一并传回去。服务端 UPDATE 时增加 WHERE 条件 row_version=request.row_version，并且同时更新 row_version（比如 +1）。这样后提交的请求因为 row_version 与数据库值不同就不会更新。
    优点是实现起来超级简单。但缺点就是只适合简单场景，如果是一个复杂表单，几十个字段那种，后提交的用户你不让他更新入库倒是行，但你也不能就把人家辛辛苦苦填的东西给直接丢了，那用户得疯。所以要想用户体验好，就还得配合前端实现数据恢复的相关逻辑（比如重新拉一次最新数据，然后 diff 差异给出提示之类的，具体的看业务需求）。
  3. 版本合并：
    这个不展开了，比较复杂。一般适用于在线文档之类的场景。
  4. 协同编辑
    在版本合并的基础上引入增量 diff 和 WebSocket。适用场景同上。

以上是 问大家一个Java逻辑问题？ 的全部内容， 来源链接： utcz.com/p/945225.html

回到顶部