分布式事务的那些解决方案.docxVIP

分布式事务的那些处理方案 1、一个服务操作一个数据库 一个服务一个数据库 一个服务操作一个对应的数据库，这就是我们大多数服务的场景，这种场景的事务很好保证，利用数据库本身的事务特性即可，我们称之为本地事务。 2、同一个服务操作多个数据库 一个服务多个数据库 随着系统功能的添加，数据量的增多，我们可能需要队数据库进行划分，依据划分方式，分为垂直划分和水平划分： 垂直划分随着服务功能的增多，我们可能会把某些功能方法放到一个单独的其他数据库中，或者我们会直接去访问其他服务的数据库，这时就会操作多个数据库了，我们把这种情况，称为数据库的垂直划分。（其实这种场景不应当存在，由于假如是本服务的，那么就应当是同一个数据库为好；假如是其他的服务，那么不应当直接操作其他服务的数据库，而是应当调用其他服务供应的接口），因而这种场景不是很常见； 水平划分上面那种场景不常见，但还有一种情况，却是经常遇到的，尤其是数据量很大的情况下。那就是当我们对数据库进行分库分表后，这时候就需要操作多个数据库了，这种情况我们称为水平划分； 3、微服务SOA跨服务调用 微服务调用 上面说到直接操作其他服务的DB，并不合适，正确的方式是使用其他服务供应的接口。 “一个服务操作一个数据库”的场景的事务，我们称之为本地事务；“同一个服务操作多个数据库”和“微服务SOA跨服务调用”这两种的事务，我们称之为分布式事务。 对于本地事务,我们可以利用数据库本身的事务特性保证事务，那么在分布式场景下，我们该如何保证事务了？ 基础 谈到事务，就必需晓得三个规章，分别是：ACID,CAP和BASE。单机系统一般遵照ACID规章；而分布式系统则一般遵照CAP规章或者BASE规章。 ACID ACID是事务的四个基本性质，属于传统数据库常用的设计理念，追求强全都性模型。ACID是指Atomicity（原子性）、Consistency（全都性）、Isolation（隔离型）、Durability（长久性）： A：原子性（Atomicity) 一个事务(transaction)中的全部操作，要么全部完成，要么全部不完成，不会结束在两头某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开头前的形态，就像这个事务从来没有执行过一样。 C:全都性（Consistency) 事务的全都性指的是在一个事务执行之前和执行之后数据库都必需处于全都性形态。假如事务成功地完成，那么系统中全部变化将正确地应用，系统处于有效形态。假如在事务中消灭错误，那么系统中的全部变化将自动地回滚，系统前往到原始形态。 I:隔离型（Isolation) 指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必需与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的形态要么是另一事务修改它之前的形态，要么是另一事务修改它之后的形态，事务不会查看到两头形态的数据。 D:长久性（Durability) 指的是只需事务成功结束，它对数据库所做的更新就必需永久保存下来。即便发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的形态。 CAP CAP CAP是Consistent(全都性)、Available(可用性)和Partition Tolerance (分区容错性)三个词的缩写： C (全都性):对某个指定的客户端来说，读操作能前往最新的写操作。对于数据分布在不同节点上的数据上来说，假如在某个节点更新了数据，那么在其他节点假如都能读取到这个最新的数据，那么就称为强全都，假如有某个节点没有读取到，那就是分布式不全都。 A (可用性)：非毛病的节点在合理的时间内前往合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间，一个是合理的响应。合理的时间指的是恳求不能无限被堵塞，应当在合理的时间给出前往。合理的响应指的是系统应当明确前往结果并且结果是正确的，这里的正确指的是比如应当前往50，而不是前往40。 P (分区容错性):当消灭网络分区后，系统能够连续工作。打个比方，这里个集群有多台机器，有台机器网络消灭了问题，但是这个集群仍旧可以正常工作。 CAP三者不行能共有，一个分布式系统最多只能同时满足全都性（Consistence）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项: CA without P 这种情况在分布式系统中几乎是不存在的。在分布式环境下，主机众多、部署分散，分区是一个必定的现实。在这个存在分区的现实下，我们选择了CA而放弃了P，那么为了保证全都性，这个时候必需拒绝恳求，但是A又不允许。因而在分布式场景下，不行能选择CA架构，只能选择CP或者AP架构。 我