分布式理论

分布式

分布式理论

CAP理论

  • 一致性（Consistency）：查出来是最新数据，指的是每次读取都能获得最新的写入数据，并且所有节点在同一时间看到相同的数据。简单来说，在一个一致性系统中，如果一个客户端提交了一个更新请求（如更新数据库），那么任何后续的读请求都会返回该更新后的最新值。
  • 可用性（Availability）：节点宕机了会有其他节点正确响应，指的是每个请求无论当前是否正在处理分布式状态的改变，都应该在合理的时间内得到响应。换句话说，系统中的每个节点在接收到请求后必须能够及时地给出响应，而不管其他节点的状态如何。
  • 分区容错性（Partition Tolerance）：因为故障导致部分节点不联通，网络产生分区，这个时候和这个节点不连通的部分就访问不到这个数据了，造成了数据的不可用，要控制这种情况其实就是控制分区的容错性

一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。

当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。

提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。

然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。

总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。

CAP定理的选择

一般来说系统都是基于P的，要么是CP要么是AP，CA无法同时保证

  • CP系统：在出现网络分区的情况下，优先保证一致性和分区容错性。这意味着在分区期间，系统可能会拒绝执行某些请求或延迟响应，直到网络恢复正常为止。这类系统适合于那些对数据一致性要求非常高的场景，比如金融交易系统。
  • AP系统：在出现网络分区的情况下，优先保证可用性和分区容错性。这意味着系统在分区期间仍然接受并处理请求，但可能会暂时牺牲一致性。这类系统适用于那些对数据的实时访问要求较高，但可以容忍一定范围内的数据不一致的情况，例如社交网络应用。

在实际应用中，设计者需要根据系统的具体需求来权衡这三个属性的重要性，并据此选择合适的架构和策略。例如，对于需要高一致性的金融交易系统，可能会更倾向于CP模型；而对于需要高可用性的Web服务，则可能更倾向于AP模型。

BASE理论

  • Basically Available（基本可用）：允许损失部分可用性

    分布式的可用性可以理解为响应时长，基本可用代表大部分时候响应很快，少数时刻响应较长

    在这里插入图片描述
    损失相应时间:CAP可用性的服务相应时间可能是10ms，而BASE基本可用性的相应时间1-2s，即允许损失部分可用性的(时间上的损失）

  • Soft state（软状态）：与强一致性相反，允许服务处于更新中的中间状态，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

  • Eventually consistent（最终一致性）：最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性

与CAP的关系？

对AP补充了一个最终一致性

arch-cap-2

事务理论 - ACID

  • Atomicity（原子性）：事务是一个不可分割的整体，事务内所有操作要么全做成功，要么全失败
  • Consistency（一致性）：务执行前后，数据从一个状态到另一个状态必须是一致的（A向B转账，不能出现A扣了钱，B却没收到）
  • Isolation（隔离性）： 多个并发事务之间相互隔离，不能互相干扰
  • Durability（持久性）：事务完成后，对数据库的更改是永久保存的，不能回滚

RPC

原理： 客户端定义一个代理类，在客户端调用RPC方法时，将方法函数、类、参数通过网络传输到服务端。服务端解析出来函数本地调用之后返回给客户端

  • 客户端（服务消费端）：调用远程方法的一端。
  • 客户端 Stub（桩）：这其实就是一代理类。代理类主要做的事情很简单，就是把你调用方法、类、方法参数等信息传递到服务端。
  • 网络传输：网络传输就是你要把你调用的方法的信息比如说参数啊这些东西传输到服务端，然后服务端执行完之后再把返回结果通过网络传输给你传输回来。网络传输的实现方式有很多种比如最基本的 Socket 或者性能以及封装更加优秀的 Netty（推荐）。
  • 服务端 Stub（桩）：这个桩就不是代理类了。我觉得理解为桩实际不太好，大家注意一下就好。这里的服务端 Stub 实际指的就是接收到客户端执行方法的请求后，去执行对应的方法然后返回结果给客户端的类。
  • 服务端（服务提供端）：提供远程方法的一端。

分布式事务

二阶段提交

保障分布式事务安全性（同时失败/成功）+存活性（响应超时、服务宕机重启）

存活性

  • 响应超时：超时终止协议
  • 宕机重启：将指令刷入磁盘，重启查看磁盘的操作

分布式事务往往涉及多个节点的事务操作，单机事务无法满足分布式要求；

事务二阶段提交策略通过引入事务协调者（TC）来协调多节点事务，它分为两个环节：Prepare、Commit/Abort

  • crepare： 收集业务结点是否有能力进行提交
  • commit：当都表示可以提交TC会向所有节点发送commit指令，保障所有节点同时提交

如果某个节点超时未收到commit/abort指令怎么办？

超时终止协议

同时满足安全性、存活性

等不到TC的commit指令，节点无法判断是否可以提交。于是向其他节点询问状况

1
2
3
if (其他节点收到了`commit`) { 同样执行`commit`操作 }
else if (其他节点返回了`Yes`) { 无法执行下一步操作 }
else { 终止协议 }

3859a76963e98377d1b21e2da9c33d4f

分布式算法

负载均衡算法

  • 轮询：Round Robin
  • 随机：Random
  • 加权随机：随机选择服务，按权值决定概率
  • 最小连接：选择最小连接的服务
  • 原地址Hash法：选择最近分区的服务

雪花算法

arch-z-id-3