共计 2134 个字符，预计需要花费 6 分钟才能阅读完成。
分布式是一种将繁多的节点因不满足业务需要而扩大为分散式的多节点的解决思路。钻研的就是如何将多个计算机的资源合并为一个大的资源。
一、事务的 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 最终一致性
各个节点在同一时间可能保留的数据不雷同，但随着时间推移，各个节点的数据将最终会统一。
