Saga是30年前一篇数据库伦理提到的一个观念。其焦点头脑是将长事宜拆分为多个当地短事宜，由Saga事宜和谐器和谐，假如正常竣事那就正常完成，假如某个步调失败，则按摄影反次序一次挪用赔偿操纵。 Saga的构成：

每个Saga由一系列sub-transaction Ti 构成 每个Ti 都有对应的赔偿举措Ci，赔偿举措用于取消Ti造成的功效,这里的每个T，都是一个当地事宜。 可以看到，和TCC对比，Saga没有“预留 try”举措，它的Ti就是直接提交到库。

Saga的执行次序有两种：

T1, T2, T3, ..., Tn

T1, T2, ..., Tj, Cj,..., C2, C1，个中0 < j < n Saga界说了两种规复计策：

向后规复，即上面提到的第二种执行次序，个中j是产生错误的sub-transaction，这种做法的结果是取消掉之前全部乐成的sub-transation，使得整个Saga的执行功效取消。 向前规复，合用于必必要乐成的场景，执行次序是相同于这样的：T1, T2, ..., Tj(失败), Tj(重试),..., Tn，个中j是产生错误的sub-transaction。该环境下不必要Ci。

这里要留意的是，在saga模式中不能担保断绝性，由于没有锁住资源，其他事宜依然可以包围可能影响当前事宜。

照旧拿100元买一瓶水的例子来说，这里界说

T1=扣100元 T2=给用户加一瓶水 T3=减库存一瓶水

C1=加100元 C2=给用户减一瓶水 C3=给库存加一瓶水

我们一次举办T1,T2，T3假如产生题目，就执行产生题目的C操纵的反向。 上面说到的断绝性的题目会呈此刻，假如执行到T3这个时辰必要执行回滚，可是这个用户已经把水喝了(其它一个事宜)，回滚的时辰就会发明，无法给用户减一瓶水了。这就是事宜之间没有断绝性的题目

可以望见saga模式没有断绝性的影响照旧较大，可以参照华为的办理方案:从营业层面入手插手一 Session 以及锁的机制来担保可以或许串行化操纵资源。也可以在营业层面通过预先冻结资金的方法断绝这部门资源， 最后在营业操纵的进程中可以通过实时读取当前状态的方法获取到最新的更新。

详细实例:可以参考华为的servicecomb

最后

照旧那句话，能不消漫衍式事宜就不消，假如非得行使的话，团结本身的营业说明，看看本身的营业较量得当哪一种，是在乎强同等，照旧最终同等即可。上面临办理方案只是一些简朴先容，假如然正的想要落地，着实每种方案必要思索的处所都很是多，伟大度都较量大，以是最后再次提示必然要判定好是否行使漫衍式事宜。最后在总结一些题目,各人可以下来本身从文章找寻谜底:

1. ACID和CAP的 CA是一样的吗？
2. 漫衍式事宜常用的办理方案的优弱点是什么？合用于什么场景？
3. 漫衍式事宜呈现的缘故起因？用来办理什么痛点？

【编辑保举】

1. 无处事器架构的三个重要意义
2. 互联网公司口中的架构优化、计谋调解？着实是裁人差异姿势
3. 措施员必要相识的赏识器缓存技能
4. 十年阿里架构师教你怎样阅读Java源码
5. IT架构的本质：事变12年，我的五点感悟

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!