深入理解分布式事务一致性

分布式事务一致性

CAP，BASE理论，到一致性模型，再到分布式事务。

BASE理论

基本可用（Basically Available）：指分布式系统在出现故障时，允许损失部分的可用性来保证核心可用。
软状态（Soft State）：指允许分布式系统存在中间状态，该中间状态不会影响到系统的整体可用性。
最终一致性（Eventual Consistency）：指分布式系统中的所有副本数据经过一定时间后，最终能够达到一致的状态。

一致性模型

强一致性，弱一致性，最终一致性。

分布式事务

引入新概念：协调者和众多参与者    

二阶段提交：
    Prepare commit/rollback 两个阶段。Prepare第一个阶段协调者监控各个参与者是否可以提交。参与者会为当前事务提前锁定资源等动作，
    如果所有参与者可以提交/不可提交，进入第二阶段commit/rollback，这里有个问题，如果协调者故障接收不到参与者给的消息，就不能进入
    第二阶段，导致一直block，资源一直被锁定。
三阶段提交：
    三阶段提交多了CanCommit和超时机制，其实就是参与者如果超时会自动commit,解决了参与者长时间等待不到协调者的消息不会一直锁住资源
    问题，但是却没有解决不一致问题。协调者如果能支持基于CP的高可用也能解决。但是性能问题是硬伤，性能过低，不适合高并发系统使用。
TCC：
    Try-Confirm-Cancel 补偿事务，对于一个事务消息，要针对性建立一个确认和补偿操作。编码复杂，目前系统就是TCC，但是在系统服务中
    失败情况毕竟是少数。
    对于分布式事务，与其想着如何一直，不如想着如何补偿。
    TCC 补偿依然可能失败，依然需要其他操作，比如说报送个中台，落地人工处理，共同完成一致性的确定。

    Try阶段：主要是对业务系统做检测及资源预留。
    Confirm阶段：确认执行业务操作。
    Cancel阶段：取消执行业务操作。

    TCC属于应用层面的2PC，需要业务逻辑实现。编码虽复杂，但在一定情况下反而提高了性能，并不一定代码多性能就低。
    
事务消息：
    目前系统也在使用，最终一致性模型，只要我们将消息给到消息队列即可。消息队列要确保消息的可靠性等。

    可以做消息预存到数据库，然后再到消息队列，消费完成在更新状态。

目前一般是TCC 与 最终一致性的消息确保多系统一致性。