分布式事务与分布式锁

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）

分布式锁

分布式锁 本质上要实现的目标就是在 Redis 里面占一个“茅坑”，当别的进程也要来占时，发现已经有人蹲在那里了，就只好放弃或者稍后再试。
占坑一般是使用 setnx(set if not exists) 指令，只允许被一个客户端占坑，先来先占， 用完了，再调用 del 指令释放茅坑。

set  test ture  ex 5 nx
del  test