补偿一词不是很理解，为什么回滚叫补偿？

期待讲解下工作流引擎的实现

一直觉得补偿事务很烦琐，日常实现也是尽量避免。看了这篇后，发现是没有很好地记录起始状态，总是想着通过目标状态来反推，所以总感觉实现起来很烦琐，逻辑错踪复杂。也许是重度精神洁癖导致吧！总觉得对正向目标没意义的数据都没有记录的必要甚至认为是浪费，然而顾着正向目标却忘了反向目标，而两个方向的目标都同等重要。

这里有一篇介绍工作流和状态机差别的文章： https://workflowengine.io/blog/workflow-engine-vs-state-machine/ When companies decide to implement a system that will help them manage business processes, their choice will probably lie between a workflow engine and a state machine. Though the behavior of the two systems seems to be quite similar, they both have a number of distinct features. Accordingly, it is necessary to analyze the pros and cons of both to decide which of the systems suits most company’s needs. In general, the major difference between a workflow engine and a state machine lies in focus. In a workflow engine, transition to the next step occurs when a previous action is completed, whilst a state machine needs an external event that will cause branching to the next activity. In other words, state machine is event driven and workflow engine is not.

事物补偿机制TCC（Try、Confirm、Cancel），是由2PC演变而来在业务层面去解决一致性问题的一种方案。其精髓在于定于业务执行逻辑的时候，同时实现一个抵消（补偿）正向逻辑的cancel操作，以便在异常情况下对原有操作进行回滚。其主要操作如下： *Try操作做业务检查及资源预留--一般用户框架对外暴露服务 *Confirm做业务确认操作--真正执行的逻辑操作，一般认为Try成功Confirm一定成功 *Cancel实现一个与Try相反的操作既回滚操作--TCC的精髓，为业务操作定义一个补偿的操作 （对于不了解TCC的同学可以参考下，了解大致背景后再看晧哥的文章会有更深的体会。基本可以当做TCC的最佳实践去读。）

皓哥， 您好！我们业务上会面临一种情况，就是跨厂商跨系统保持系统间数据同步，无论是通过代码直接操作多个数据库进行同步，还是通过让厂商提供服务来进行同步，最终要么实现效果很差，要么就同步机制弄的略复杂（比如订阅发布，厂商不配合），让计划没法推进。您这边后续有计划说一下类似情况如何处理吗？ 说到库存的话，我们行业这边还有一种神奇的操作。这种操作的要求是，“你没货我理解，但是你说有货、我要了、你再说没有那就不行”。所以在我们行业，通常把库存分为实库存和用户库存。用户看到的库存永远小于实库存，由于并发量并不大，只需要用简单的事务控制，也能在很大程度上可以避免超卖。但当库存很低的情况下，代码就要用严格的事务控制，来避免超卖了，执行效率就很低，好在这样的情况很少。

workflow用过两种 jbpmn的activiti5以及netflix的conductor。 workflow与task是两个重点

陈老师好，有个疑问想请教: 衡量高可用一般用几个9来衡量，例如4个9的高可用是指一年的服务不可用时间不能超过53分钟，我的疑问有两个: 第一，到底怎么样定义服务不可用？例如返回业务的系统忙算不算可用？第二，直观理解，可用性应该是针对单个接口定义的，一个系统有很多接口，那么一个系统的可用性又应该怎么计算呢？ 非常感谢！

期待耗子叔可以讲讲如何设计一个补偿框架，可以讲讲具体地实现过程和相关技术和难点。谢谢

期待举例讲解补偿工作流引擎