CAP

我们的CAP理论最多只能同时满足俩个

我们的Dubbo满足了cp没有满足a！！
比如我们Zookeeper是一个由多个server组成的集群一个Leader多个follower,假如我们的leader挂掉了，这是我们保证了分区容错性，会迅速从follower里选择出来一个leader(选举的过程中不对外提供服务)。但这是如果有请求进来就会出错(所以没有保证可用性)。dubbo进行数据修改时需要将主节点和从节点数据同时进行修改。

我们的Springcloud满足了ap没有满足c
springcloud通过熔断机制hystrix保证了他的可用性

分布式事务

1. XA两段提交(强一致)事务管理器通知俩个本地事务准备执行，事务1执行成功告诉事务管理器，事务2执行成功告诉事务管理器，事务管理器通知他们俩个事务提交。
2. 三段提交3PC(强一致)
3. TCC补偿机制
4. 本地消息表(MQ+Table)（最终一致）
5. 事务消息(RocketMq)（最终一致） 发送预消息(不会被消费者消费到)—>执行自己业务逻辑—>confirm消息(让之前发送的消费能够被消费者看到) —>消费者执行自己的业务逻辑 —>消费成功的话给rocketMQ发信息 删除队列的消息。
6. Seata（alibaba）