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