1.标准的分布式事务想要达到的效果：
A业务成功，B业务也成功。
A业务失败，B业务也失败。
即：A、B业务同时成功或失败（回滚）
但是这种要求较高，本地事务实现起来比较容易，但是对于分布式事务
有相关实现方式，类似于强一致性。（XA协议、两阶段提交2PC等）
对于SOA架构的应用，很多时候由于业务需求，并不需要强一致性，允许
存在弱一致性（异步、延迟）情况存在，因此采用柔性事务方式实现。
2.柔性事务不会像标准的分布式事务这么高的要求，可以不用同时保证A、B业务
同时成功或失败。
核心：我认为A、B业务 不用关心对方是否成功或失败，只要关心自己成功或失败。
然后由于A、B业务存在主动方和被动方，那么主动方其实只要关心自己的业务
成功，并抛出让被动方业务进行的请求或通知即可，最后通过正常反馈（同步）
或单独的结果确认（异步）保证一致即可：有的业务需要最终一致，有的业务
仅需要最大努力一致，因此就有了2种分布式事务的方案（包含但不仅限于）：
最终一致性方案、最大努力通知方案。
其实最终一致性也是一种通知方案
最大努力通知方案也是一种希望达到最终一致性的方案（分布式事务的本质目的）
两者只是略有区别而已，实现方式、要求、场景略不同。
具体不同有：
1)最终一致性适合在企业内部的应用和应用之间
2)最大努力通知适合在企业间的应用和应用之间
3.针对最终一致性方案，通常是通过消息中间件来实现。
但是消息中间件 并不可靠、或者网络并不可靠， 需要进行优化。
优化方案就是构建一套可靠消息服务方案，保证消息能够可靠的进行接收和转发，
并有对应的消息确认系统、恢复系统。
核心：由于构建了可靠消息系统，那么剩下的事情就很简单
1）消息系统只要收到了主动方应用的消息并成功存储，即可。 不管消息系统能否反馈
给主动方应用，都不会影响主动方应用（主动方应用同步或异步调用消息服务都可以，
dubbo可配置）。即，如果正常反馈，主动方正常执行；如果没有反馈，主动方正常
执行（异步调用）或不执行（同步调用）。
2）针对消息没有状态确认过的，有消息确认子系统进行确认，故可保证也可无视网络问题
造成的主动方没能正常更新消息状态的情况。
3）消息可发送后，如果由于被动方应用或网络问题导致消息发送失败，需要有消息恢复
子系统进行重新发送，确保 主动方的请求或调用能够顺利完成，这里被动方应用需要
实现幂等性。