分布式

Ocean7732
116 阅读4分钟

分布式

CAP理论

一致性（Consistency）

一致性意思就是写操作之后进行读操作无论在哪个节点都需要返回写操作的值

可用性(Availability）

非故障的节点在合理的时间内返回合理的响应

分区容错性(Partition Tolerance)

当网络出现分区后，系统依然能够继续旅行社职责

image.png

ZooKeeper 保证的是 CP Eureka 保证的则是 AP Nacos 不仅支持 CP 也支持 AP

BASE 理论

image.png

ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。

Zookeeper用过吗，介绍一下

ZooKeeper 是一个开源的分布式应用程序协调服务器，其为分布式系统提供一致性服务。其一致性是通过基于 Paxos 算法的 ZAB 协议完成的。其主要功能包括：配置维护、分布式同步、集群管理、分布式事务等

Zookeeper一般用在什么场景

  • 分布式协调
  • 分布式锁
  • 元数据/配置信息管理
  • HA高可用性

分布式一致性协议(Zab、Paxos、Raft)

image.png

image.png

CAS原理，ABA问题

CAS（比较与交换，Compare and swap） 是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。实现非阻塞同步的方案称为“无锁编程算法”（ Non-blocking algorithm） 缺点：

  • ABA 问题
  • 循环时间长开销大
  • 只能保证一个共享变量的原子操作

分布式事务

两阶段提交（2PC）

1.1 准备阶段

协调者询问参与者事务是否执行成功，参与者发回事务执行结果。 1.2 提交阶段

如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。 存在的问题：

同步阻塞 所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其它操作。

单点问题 协调者在 2PC 中起到非常大的作用，发生故障将会造成很大影响。特别是在阶段二发生故障，所有参与者会一直等待状态，无法完成其它操作。 数据不一致 在阶段二，如果协调者只发送了部分 Commit 消息，此时网络发生异常，那么只有部分参与者接收到 Commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。 太过保守 任意一个节点失败就会导致整个事务失败，没有完善的容错机制。

补偿事务（TCC）

Try阶段主要是对业务系统做检测及资源预留 Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。 Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。 优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些 缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。

本地消息表（异步确保）

image.png

优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。 缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

MQ 事务消息

image.png

RocketMq半事务消息 优点： 实现了最终一致性，不需要依赖本地数据库事务。 缺点： 实现难度大，主流MQ不支持，RocketMQ事务消息部分代码也未开源。

分布式锁

分布式锁设计原则

排他性：被共享资源同意时间内只能被一台机器上的一个线程使用，这点和jvm锁是一个道理。
避免死锁：线程获取到锁，在执行完业务之后，一定要释放锁（包括异常情况下释放）。
高可用：获取和释放锁要保证高可用和性能。
可重入：最好是可重入锁，即当前机器的当前线程如果没有获取到锁，那么在等待一定时间后一定要保证可以再被获取到。
公平锁：不是硬性要求，指的是不同线程获取锁时最好保证几率一样

分布式锁实现方式

1. 基于数据库级别的锁
2. 基于redis的原子操作
3. 基于zookeeper的互斥排他
avatar
文章
阅读
粉丝