分布式事务与分布式锁

CAP

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

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

分布式事务

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

分布式锁

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

set  test ture  ex 5 nx
del  test

你可能感兴趣的:(分布式事务,java)