乐趣区

关于java:面试再问你CAPBase-理论是什么这篇文章仍甩给他

jiezi

作者：架构师小白, 起源：公众号 - 程序员虎哥

前言

什么是分布式事务？介绍这个之前，先理解下这几个问题

  1. 事务是什么？
  2. 本地事务是什么？
  3. 分布式是什么？
  4. 分布式事务是什么？

事务是什么？

实现某件事情，可能有多个参与者须要执行多个步骤，最终多个步骤要么全副胜利，要么全副失败。

举个栗子：支付宝上 A 给 B 转账 100 元，A 账户扣 100，B 账户减少 100，这就是一个事务，这个操作中要么都胜利，要么都失败。

事务的场景有很多，参与者也是多种多样。比方

  1. 用户胜利注册而后发送邮件，蕴含 2 个操作：向数据库插入用户信息，给用户发送邮件，次要的 2 个参与者：数据库、邮件服务器
  2. 应用微信充值话费，蕴含 2 个操作：微信账户资金缩小，手机余额减少，次要的 2 个参与者：微信账户、手机号服务商账户

事务的参与者是多种多样的，不过本文咱们次要以数据库中的事务来做阐明。

本地事务是什么？

本地事务，简略了解就是事务中所有操作产生在同一个数据库中的状况。

比方 A 给 B 转账，A 和 B 的账户位于同个数据库中。

通常咱们用的都是关系型数据库，比方：MySQL、Oracle，这些数据库默认状况，曾经实现了事务的性能，即在一个数据库中执行一个事务操作，数据库自身就能够确保这个事务的正确性，而不须要咱们本人去思考：怎么确保事务的正确性。

另外，关注公众号 java 锦囊，在后盾回复：面试，能够获取我整顿的 MySQL、分布式系列面试题和答案，十分齐全。

数据库事务的 4 大个性

  1. 一致性

事务操作之后的后果和冀望的后果是统一的，A 给 B 转账 100，事务完结之后，看到 A 的账户应该缩小 100，B 的账户应该减少 100，不会呈现其余状况

  1. 原子性

事务的整个过程如原子操作一样，最终要么全副胜利，要么全副失败，这个原子性是从最终后果来看的，整个过程是不能宰割的。

  1. 隔离性

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

  1. 持久性

一个事务一旦提交，它对数据库中数据的扭转就应该是永久性的。当事务提交之后，数据会长久化到硬盘，批改是永久性的。

分布式是什么？

实现某件事情有多个参与者，多个参与者散布在不同机器，这些机器之间通过网络或者其余形式进行通信。

比方应用工行卡给微信充值，工行卡的账户位于工商银行的数据库中，而微信账户位于微信的数据库中，2 个数据库位于不同的中央。

分布式事务是什么？

分布式、事务这 2 个概念讲清楚了，那么分布式事务就很容易了解：事务的多个参与者散布在不同的中央。

单个数据库中咱们很容易确保事务正确性，然而当事务的参与者位于多个数据库中的时候，如何确保事务的正确性呢？

比方：A 用户给 B 用户转账，A 用户数据位于 DB1 中，B 用户数据位于 DB2 中 

step1. 通过网络，给 DB1 发送指令：给 A 账户缩小 100
step2. 通过网络，给 DB2 发送指令：给 B 账户减少 100

step1 胜利之后，执行 step2 的时，网络呈现故障，导致 step2 执行失败，最终：A 缩小了 100，B 却没有减少 100，最终的后果和冀望的后果不统一，导致了事务的失败。

在介绍分布式事务的解决方案之前，咱们须要先理解另外 2 个概念：CAP 和 Base 实践，这 2 个实践为解决分布式事务的提供了根据。

CAP 实践

了解 CAP 概念

CAP 是 Consistency、Availability、Partition tolerance 三个词语的缩写，别离示意一致性、可用性、分区容忍性，下边咱们别离来解释。

为了不便对 CAP 实践的了解，咱们联合电商零碎中的一些业务场景来了解 CAP。

如下图，是商品信息管理的执行流程：

整体执行流程如下：

1、商品服务申请主数据库写入商品信息（增加商品、批改商品、删除商品）

2、主数据库向商品服务响应写入胜利。

3、商品服务申请从数据库读取商品信息。

C – Consistency

一致性是指写操作后的读操作能够读取到最新的数据状态，当数据分布在多个节点上，从任意结点读取到的数据都是最新的状态。

上图中，商品信息的读写要满足一致性就是要实现如下指标：

1、商品服务写入主数据库胜利，则向从数据库查问新数据也胜利。

2、商品服务写入主数据库失败，则向从数据库查问新数据也失败。

如何实现一致性？

1、写入主数据库后要将数据同步到从数据库。

2、写入主数据库后，在向从数据库同步期间要将从数据库锁定，待同步实现后再开释锁，免得在新数据写入从库的过程中，客户端向从数据库查问到旧的数据。

分布式系统一致性的特点

1、因为存在数据同步的过程，写操作的响应会有肯定的提早。

2、为了保证数据一致性会对资源临时锁定，待数据同步实现开释锁定资源。

3、如果申请数据同步失败的结点则会返回错误信息，肯定不会返回旧数据。

A – Availability

可用性是指任何事务操作都能够失去响应后果，且不会呈现响应超时或响应谬误。

上图中，商品信息读取满足可用性就是要实现如下指标：

  1. 从数据库接管到数据查问的申请则立刻可能响应数据查问后果。
  2. 从数据库不容许呈现响应超时或响应谬误。

如何实现可用性？

  1. 写入主数据库后要将数据同步到从数据库。
  2. 因为要保障从数据库的可用性，不可将从数据库中的资源进行锁定。
  3. 即便数据还没有同步过去，从数据库也要返回要查问的数据，哪怕是旧数据，如果连旧数据也没有则能够依照约定返回一个默认信息，但不能返回谬误或响应超时。

分布式系统可用性的特点

  1. 所有申请都有响应，且不会呈现响应超时或响应谬误。

P – Partition tolerance

通常分布式系统的各个结点部署在不同的子网，这就是网络分区，不可避免的会呈现因为网络问题而导致结点之间通信失败，此时仍可对外提供服务，这叫分区容忍性。

上图中，商品信息读写满足分区容忍性就是要实现如下指标：

  1. 主数据库向从数据库同步数据失败不影响读写操作。
  2. 其一个结点挂掉不影响另一个结点对外提供服务。

如何实现分区容忍性？

  1. 尽量应用异步取代同步操作，例如应用异步形式将数据从主数据库同步到从数据，这样结点之间能无效的实现松耦合。
  2. 增加从数据库结点，其中一个从结点挂掉其它从结点提供服务。

分布式分区容忍性的特点

  1. 分区容忍性分是布式零碎具备的根本能力

CAP 组合形式

上边商品治理的例子是否同时具备 CAP 呢？

在所有分布式事务场景中不会同时具备 CAP 三个个性，因为在具备了 P 的前提下 C 和 A 是不能共存的。

比方, 下图满足了 P 即示意实现分区容忍：

本图分区容忍的含意是：

1）主数据库通过网络向从数据同步数据，能够认为主从数据库部署在不同的分区，通过网络进行交互。

2）当主数据库和从数据库之间的网络呈现问题不影响主数据库和从数据库对外提供服务。

3）其一个结点挂掉不影响另一个结点对外提供服务。

如果要实现 C 则必须保证数据一致性，在数据同步的时候为避免向从数据库查问不统一的数据则须要将从数据库数据锁定，待同步实现后解锁，如果同步失败从数据库要返回错误信息或超时信息。

如果要实现 A 则必须保证数据可用性，不论任何时候都能够向从数据查问数据，则不会响应超时或返回错误信息。

通过剖析发现在满足 P 的前提下 C 和 A 存在矛盾性，如下：

主从库之间网络呈现故障的状况下，主库的数据无奈同步给从库，为了确保里面看到数据是统一的，此时从库不能让内部拜访，只能让主库对外提供服务，从库失去了可用性。

主从库之间网络呈现故障的状况下，主库的数据无奈同步给从库，此时 2 个库数据是不统一的，如果此容许 2 个库都能够对外提供服务（可用性），那么 2 个库拜访的数据是不统一的。

所以 CAP 无奈同时满足，通常状况下，在分布式系统中，多个节点分在不同的网络节点中，网络故障是无奈完全避免的，所以 P 是必定会存在的，此时咱们须要思考 P 和另外 2 个如何组合的问题。

CAP 有哪些组合形式呢？

所以在生产中对分布式事务处理时要依据需要来确定满足 CAP 的哪两个方面。

1）AP：

放弃一致性，谋求分区容忍性和可用性。这是很多分布式系统设计时的抉择。

例如：

上边的商品治理，齐全能够实现 AP，前提是只有用户能够承受所查问的到数据在肯定工夫内不是最新的即可。

通常实现 AP 都会保障最终一致性，前面讲的 BASE 实践就是依据 AP 来扩大的，一些业务场景 比方：订单退款，今日退款胜利，明日账户到账，只有用户能够承受在肯定工夫内到账即可。

2）CP：

放弃可用性，谋求一致性和分区容错性，咱们的 zookeeper 其实就是谋求的强统一。

3）CA：

放弃分区容忍性，即不进行分区，不思考因为网络不通或结点挂掉的问题，则能够实现一致性和可用性。

那么零碎将不是一个规范的分布式系统，咱们最罕用的关系型数据就满足了 CA。

上边的商品治理，如果要实现 CA 则架构如下：

主数据库和从数据库两头不再进行数据同步，数据库能够响应每次的查问申请，通过事务隔离级别实现每个查问申请都能够返回最新的数据。

另外，关注公众号 java 锦囊，在后盾回复：面试，能够获取我整顿的 MySQL、分布式系列面试题和答案，十分齐全。

总结

通过下面咱们曾经学习了 CAP 实践的相干常识，CAP 是一个曾经被证实的实践：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。它能够作为咱们进行架构设计、技术选型的考量规范。对于少数大型互联网利用的场景，结点泛滥、部署扩散，而且当初的集群规模越来越大，所以节点故障、网络故障是常态，而且要保障服务可用性达到 N 个 9（99.99..%），并要达到良好的响应性能来进步用户体验，因而个别都会做出如下抉择：保障 P 和 A，舍弃 C 强统一，保障最终一致性

Base 实践

了解强一致性和最终一致性

CAP 实践通知咱们一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项，其中 AP 在理论利用中较多，AP 即舍弃一致性，保障可用性和分区容忍性，然而在理论生产中很多场景都要实现一致性，比方前边咱们举的例子主数据库向从数据库同步数据，即便不要一致性，然而最终也要将数据同步胜利来保证数据统一，这种一致性和 CAP 中的一致性不同，CAP 中的一致性要求在任何工夫查问每个结点数据都必须统一，它强调的是强一致性，然而最终一致性是容许能够在一段时间内每个结点的数据不统一，然而通过一段时间每个结点的数据必须统一，它强调的是最终数据的一致性。

Base 实践介绍

BASE 是 Basically Available(根本可用)、Soft state(软状态) 和 Eventually consistent (最终一致性) 三个短语的缩写。BASE 实践是对 CAP 中 AP 的一个扩大，通过就义强一致性来取得可用性，当呈现故障容许局部不可用但要保障外围性能可用，容许数据在一段时间内是不统一的，但最终达到统一状态。满足 BASE 实践的事务，咱们称之为“柔性事务”。

根本可用

分布式系统在呈现故障时，容许损失局部可用性能，保障外围性能可用。如，电商网站交易付款呈现问题了，商品仍然能够失常浏览。

软状态

因为不要求强一致性，所以 BASE 容许零碎中存在中间状态（也叫软状态），这个状态不影响零碎可用性，如订单的 ” 领取中 ”、“数据同步中”等状态，待数据最终统一后状态改为“胜利”状态。

最终统一

最终统一是指通过一段时间后，所有节点数据都将会达到统一。如订单的 ” 领取中 ” 状态，最终会变为“领取胜利”或者 ” 领取失败 ”，使订单状态与理论交易后果达成统一，但须要肯定工夫的提早、期待。

退出移动版