文章转自华为云社区，作者：刘丹冰Aceld；原文链接：https://bbs.huaweicloud.com/blogs/327392
分布式实际上就是单一的本地一体解决方案，在硬件或者资源上不够业务需求，而采取的一种分散式多节点，可以扩容资源的一种解决思路。它研究如何把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分，然后把这些部分分配给多个计算机进行处理，最后把这些计算结果综合起来得到最终的结果。
那么在了解分布式之前，我们应该从一体式的构造开始说明。
一、从本地事务到分布式理论
理解分布式之前，需要理解一个问题就是"事务"
事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。
简单地说，事务提供一种“ 要么什么都不做，要么做全套（All or Nothing）”机制。
二、ACID理论
事务是基于数据进行操作，需要保证事务的数据通常存储在数据库中，所以介绍到事务，就不得不介绍数据库事务的ACID特性，指数据库事务正确执行的四个基本特性的缩写。包含：
-
原子性（Atomicity）
-
一致性（Consistency）
-
隔离性（Isolation）
-
持久性（Durability）
(1) 原子性（Atomicity）
整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。
例如：银行转账，从A账户转100元至B账户：
A、从A账户取100元
B、存入100元至B账户。 这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。
(2) 一致性（Consistency）
在事务开始之前和事务结束以后，数据库数据的一致性约束没有被破坏。
例如：现有完整性约束A+B=100，如果一个事务改变了A，那么必须得改变B，使得事务结束后依然满足A+B=100，否则事务失败。
(3) 隔离性（Isolation）
数据库允许多个并发事务同时对数据进行读写和修改的能力，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
例如：现有有个交易是从A账户转100元至B账户，在这个交易事务还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的。
(4) 持久性（Durability）
事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
本地事务ACID实际上可用”统一提交，失败回滚“几个字总结，严格保证了同一事务内数据的一致性！
而分布式事务不能实现这种ACID。因为有CAP理论约束。接下来我们来了解一下，分布式中是如何保证以上特性的，那么就有了一个著名的CAP理论。
三、CAP理论
在设计一个大规模可扩放的网络服务时候会遇到三个特性：一致性（consistency）、可用性（Availability）、分区容错（partition-tolerance）都需要的情景.
CAP定律说的是在一个分布式计算机系统中，一致性，可用性和分区容错性这三种保证无法同时得到满足，最多满足两个。
如上图，CAP的三种特性只能同时满足两个。而且在不同的两两组合，也有一些成熟的分布式产品。
接下来，我们来介绍一下CAP的三种特性，我们采用一个应用场景来分析CAP中的每个特点的含义。
该场景整体分为5个流程：
流程一、客户端发送请求(如:添加订单、修改订单、删除订单)
流程二、Web业务层处理业务，并修改存储成数据信息
流程三、存储层内部Master与Backup的数据同步
流程四、Web业务层从存储层取出数据
流程五、Web业务层返回数据给客户端
(1) 一致性Consistency
“all nodes see the same data at the same time”
一旦数据更新完成并成功返回客户端后，那么分布式系统中所有节点在同一时间的数据完全一致。
在CAP的一致性中还包括强一致性、弱一致性、最终一致性等级别，稍后我们在后续章节介绍。
一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意结点读取到的数据都是最新的状态。
一致性实现目标：
-
Web业务层向主Master写数据库成功，从Backup读数据也成功。
-
Web业务层向主Master读数据库失败，从Backup读数据也失败。
