分布式系统的理论发展

Posted 2021-09-13 thepoy

分布式是一种将单一的节点因不满足业务需求而扩展为分散式的多节点的解决思路。研究的就是如何将多个计算机的资源合并为一个大的资源。

一、事务的 ACID 特性

事务是恢复和并发控制的基本单位。其具有四个特性（ACID）：

• 原子性（atomicity）

  • 一个事务是不可分割的工作单位，事务中的任务要么都完成，要么都不完成。

• 一致性（consistency）

  • 事务必须是使数据库从一个一致性的状态变到另一个一致性的状态。
  • 一致性与原子性密切相关。

• 隔离性（isolation）

  • 一个事务的执行不能被其他事务干扰。
  • 即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

• 持久性/永久性（durability）

  • 一个事务一旦提交，对数据库中的数据的改变是永久性的，接下来的任何其他操作或故障都不应该对其有任何影响。

二、CAP 原则

CAP 原则也称 CAP 定理，指一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）只能同时实现两点，不可能三者兼顾。

2.1 一致性

在同一时间，所有的节点获取的数据是一样的数据。

一旦数据更新完并返回客户端后，那么分布式系统中的所有节点在同一时间获取到的同一份最新的数据。

所有的节点数据都需要同步为最新数据才能保证在取数据时是完全一致的。

如果只有两个节点，一个主节点和一个副节点，当客户端向主节点写数据时：

• 如果写入成功，则新写入的数据也必须同步到副节点中，当客户端从副节点读取数据时，读取到的就是刚向主节点写入的数据。
• 如果写入失败，主副节点的数据都不会有任何改变。

主副数据库的同步过程是需要上锁的，避免在此期间客户端从副节点获取到旧的数据导致从主副节点获取到的数据不一致的情况发生。

2.1.1 分布式一致性特点：

• 由于存在数据同步的过程，写操作的响应会有一定的延迟
• 为了保证数据一致性会对资源进行暂时锁定，数据同步完成时再释放资源
• 如果数据同步失败，在获取数据时将返回错误信息，而不是旧数据

2.2 可用性

每次请求都能获取到非错的响应，但非错就不能保证获取到的所有的数据都是最新数据。

可用性程度的标准如下表所示：

可用性分类	可用性（%）	年故障时间
容错可用性	99.9999	32秒
极高可用性	99.999	5分15秒
具有故障自动恢复能力的可用性	99.99	52分34秒
高可用性	99.9	8小时46份
商品可用性	99	3天15小时36分

可用性实现过程：

• 当主节点正在被更新时，副节点接收到数据查询的请求时会立即响应数据查询结果
• 副节点不能响应超时或响应错误

在追求可用性时，在数据同步时不能上锁，所以使用异步请求进行数据同步。

2.3 分区容错性

多个节点之间不能在时限范围内达到数据一致性，就意味着发生了分区的情况，此时就必须在一致性和可用性之间做出选择，以保证个别节点出现故障时，系统依然能正常运行。

分区容错性是分布式系统要具备的最基本的能力。

必要实现流程：

• 尽量使用异步取代同步操作，这样节点之间能有效地实现松耦合
• 添加更多的副节点，当其中一个出现故障，其他副节点依然能提供服务

2.4 3选2该怎么选

既然无法同时满足 CAP 三个特性，而分区容错性又是分布式系统必需的特性，所以只能在可用性和一致性做出选择。

2.4.1 放弃可用性

如果一个分布式系统不要求强的可用性，即允许系统停机或长时间无响应的话，就可以放弃可用性，追求一致性和分区容错性。

场景举例：

跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。

2.4.2 放弃一致性

现在多数分布式系统追求的都是 AP，高可用和分区容错，允许数据同步有一定的延迟（最终一致即可）。

场景举例：

抢购。在某些电商中经常会有一些抢手的商品，因为供不应求，所以需要用户进行抢购。在抢购过程中，有很多用户明明已经抢到了商品，且形成了订单，但在付款时却提示商品已售完。这就是为了保证系统的正常运行，在数据一致性上做出了妥协，虽然会给一些用户带来不好的体验，但却能保证大部分用户的正常访问浏览。

从付款失败时提示商口告罄可以看出来，<u>数据最后还是一致的</u>。

三、BASE 原则

BASE原则与CAP原则出自同一人之手，是Basically Available(基本可用）、Soft state(软状态）和Eventually consistent(最终一致性）三个短语的简写，但这个缩写是特意拼凑的（ACID 也是特意拼凑的）。

BASE主张放弃一致性而追求高可用性，但最后要使用合适的办法使系统数据达成最终一致。

3.1 基本可用

基本可用只能保证系统可用，系统可以响应慢或者某些功能无法正常使用。

例如，一个购物网站，正常时查询一件商品只需要100ms服务器就能返回商品数据，但系统因为发生一些问题，最终查询用时增加到了5秒。

又如，这个购物网站有一个大力优惠的活动，导致访问量激增，为了保证此活动能顺利开展，当部分用户参加其他活动时可能直接跳转到主页或其他活动页面或返回活动已结束。

3.2 软状态

软状态表示系统的状态可能会随着时间而改变，即便没有任何数据输入，也会因为最终一致性而发生变化。

3.3 最终一致性

各个节点在同一时间可能保存的数据不相同，但随着时间推移，各个节点的数据将最终会一致。