长业务事务的离线并发问题
事务指代一组操作同时成功或同时失败，事务可分为两类：
- 系统事务：即关系数据库事务，一次数据库连接中由
start transaction或begin开启，commit表示提交，rollback表示回滚； - 业务事务：完成一个业务目标包含的一系列业务动作，如让一个配置生效，需要经历
编辑->保存->提交审批->审批通过这4个步骤。
当事务持续时间过长，并发请求的概率就会越大，会导致一系列并发问题，如：脏读，不可重复读，更新丢失甚至死锁等问题。
解决大系统事务的方式通常是两个思路：减少事务持续时间 和 缩小事务锁定资源的范围，比如仅在写库时开启事务，前置的查询判断逻辑不在事务中进行，以此来避免并发更新，同时写库时可使用乐观锁（如：版本号）进行兜底判断，以此来检测并发更新。
而业务事务的持续时间和资源通常由业务流程所决定，并不能在这两个方面优化来避免离线并发问题， 但可以通过乐观锁机制检测并发更新。
考虑如下场景：运营人员发布一个商品需要经过 商品配置编辑 -> 商品配置保存 -> 商品配置审批 -> 商品发布 4步，
商品配置状态机如下：
如果不做任何离线并发控制，会存在业务保存的配置和实际提交的配置存在不一致，考虑以下情况：
张三预期提交审批的配置和实际提交的配置不一致。这里需要一个版本号关联保存的配置和发起审批的配置，通常在保存时，后台返回保存的版本，后面提交审批时携带保存的版本，后台进行版本比对，如果版本不一致，则表示配置已被更新，需终止发起审批：
这种丢失更新的场景通常是由于操作非原子导致，从保存到发起审批之间的时间间隔无法预知，不同业务人员在一段时间内同时编辑容易
触发离线并发问题。
这里使用乐观锁机制在最终提交步骤里检测是否被并发更新，为什么不使用悲观锁？其一，业务流程上不允许一个业务人员的一次操作独占该配置的写，其二，悲观锁锁定时间较长，耗费资源多，且容易引发死锁问题。
那么乐观锁有什么缺点呢？业务只有在最终提交时才会感知到此次修改保存是否有效，我辛辛苦苦编辑了10分钟，最后提交你和我说被别人改了提交不了，业务很"生气"。当然也可以在业务编辑时定时检测是否有新版本提交，提早主动发现而非最后被动告知，交互性上相对更人性化，现在的各种网站也都有主动检测变更机制，例如，B站在看评论时如果有新评论会自动插入到评论区中，不需要用户重新刷新。