CAP
我们的CAP理论最多只能同时满足俩个
我们的Dubbo满足了cp没有满足a！！
比如我们Zookeeper是一个由多个server组成的集群一个Leader多个follower,假如我们的leader挂掉了，这是我们保证了分区容错性，会迅速从follower里选择出来一个leader(选举的过程中不对外提供服务)。但这是如果有请求进来就会出错(所以没有保证可用性)。dubbo进行数据修改时需要将主节点和从节点数据同时进行修改。
我们的Springcloud满足了ap没有满足c
springcloud通过熔断机制hystrix保证了他的可用性
分布式事务
- XA两段提交(强一致)
事务管理器通知俩个本地事务准备执行，事务1执行成功告诉事务管理器，事务2执行成功告诉事务管理器，事务管理器通知他们俩个事务提交。 - 三段提交3PC(强一致)
- TCC补偿机制
- 本地消息表(MQ+Table)（最终一致）
- 事务消息(RocketMq)（最终一致）
发送预消息(不会被消费者消费到)—>执行自己业务逻辑—>confirm消息(让之前发送的消费能够被消费者看到) —>消费者执行自己的业务逻辑 —>消费成功的话给rocketMQ发信息 删除队列的消息。 - Seata（alibaba）
分布式锁
分布式锁 本质上要实现的目标就是在 Redis 里面占一个“茅坑”，当别的进程也要来占时，发现已经有人蹲在那里了，就只好放弃或者稍后再试。
占坑一般是使用 setnx(set if not exists) 指令，只允许被一个客户端占坑，先来先占， 用完了，再调用 del 指令释放茅坑。
set test ture ex 5 nx
del test