1、从集中式到分布式
1.1：集中式的特点
所谓集中式系统就是指由一台或多台主计算机组成中心节点，数据集中存储在这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统所有功能均有其集中处理。在集中式系统中，每个终端或客户端机器仅仅负责数据的录入和输出，而数据存储与控制处理完全由主机来完成。
集中式系统最大特点就是部署结构简单，集中式系统往往基于底层性能卓越的大型主机，因此无需考虑如何对服务进行多个节点的部署，也就不用考虑多个节点之间的分布式协作问题。
1.2：分布式的特点
分布式系统定义：一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。
一个标准的分布式系统在没有任何特定业务逻辑约束的情况下，都会有如下几个特征有：
1、分布性：
分布式系统中的多台计算机都会在空间上随意分布，同时，机器的分布情况也会随时变动。
2、对等性：
分布式系统中计算机没有主/从之分，组成分布式系统的所有计算机节点都是对等的。
副本（Replica）是分布式系统对数据和服务提供的一种冗余方式。在常见的分布式系统中，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。即数据副本和服务副本。
数据副本：指在不同节点上持久化同一份数据，当某一节点上存储的数据丢失时，可以从副本上读取到该数据。这是解决分布式系统数据丢失问题最为有效的手段。
服务副本：指多个节点提供同样的服务，每个节点都有能力接收来自外部的请求并进行相应处理。
3、并发性：
在一个计算机网络中，程序运行过程中的并发性操作是非常常见的。例如同一个分布式系统的多个节点，可能并发地操作一些共享资源，诸如数据库或分布式存储等。如何准确并高效地协调分布式并发操作是分布式架构中的最大的挑战之一
4、缺乏全局时钟：
典型的分布式系统由一系列在空间上随意分布的多个进程组成，进程之间通过交换消息来相互通信。在分布式系统中，很难定义两个事件的先后顺序，原因是分布式系统缺乏一个全局的时钟序列控制。
5、故障的发送：
组成分布式系统中所有计算机，都可能发送任何形式的故障。
1.3：分布式环境的各种问题
通信异常：
分布式系统需要在各个节点之间进行网络通信，这必然会伴随网络不可用的风险。其次在分布式系统中，节点通信的延时远大于单机操作，因此消息丢失和消息延迟变得非常普遍。
网络分区：
当网络异常时，分布式系统中部分节点之间的网络延时不断增加，最终导致组成分布式系统的所有节点中，只有部分节点之间能够进行正常通行，而另一些节点不能。这种现象我们称为网络分区，俗称"脑裂"。当网络分区出现时，可能导致局部小集群独立原本要整个系统才能完成的功能，包括对数据的事务处理。这便极大的影响了分布式一致性。
三态：
我们已经了解到分布式环境下，网络可能出现的问题。因此分布式系统的每一次请求与响应，存在特有的“三态”概念。即：成功、失败与超时。
超时情况的分类：
由于网络原因，请求没有被成功发送到接收方。在发送过程中出现消息丢失
请求成功被接收方接收并处理，但在响应给发送方过程中，出现消息丢失。
节点故障：
组成分布式系统的服务器节点出现宕机或“僵死”。
2、从ACID到CAP/BASE
我们了解了集中式系统和分布式系统的特点，也看到了从集中式向分布式系统变迁过程中会碰到的问题。接下来我们看看在分布式系统中，事务处理与数据一致性的问题。
ACID：
事务（Transaction）是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元，狭义上的事务特指数据库事务。一方面，事务为多个应用程序并发访问数据库提供一个隔离方法，防止彼此的操作互相干扰。另一方面，事务为数据库操作序列提供了一个从失败中恢复到正常状态的方法，同时提供了数据库即使在异常状态下仍能保持数据一致性的办法。
事务的四个特征：
原子性（Atomicity）：事务必须是一个原子的操作序列单元，一次执行中要么全部成功执行，要么全部不执行。
一致性（Consistency）：一个事务在执行之前和执行之后，数据库都必须处于一致性状态。
隔离性（Isolation）：并发的事务相互隔离，一个事务的执行不能被其他事务干扰。
在标准的SQL规范中，定义了4个事务隔离级别：
读未提交（Read Uncommited）：允许读取到其他事务未提交的数据，其事务隔离级别最低。
读已提交（Read Commited）：允许读取到其他事务已提交的数据。
可重复读（Repeatable Read）：事务处理过程中，多次读取同一个数据，其值都和事务开始时刻是一致的。
串行化（Serializable）：最严格的事务隔离级别，要求所有事务被串行执行，即事务只能按顺序一个接一个地处理，不能并发执行。
| 隔离级别 | 脏 读 | 不可重复读 | 幻 读 |
| 读未提交 | 允许 | 允许 | 允许 |
| 读已提交 | 不允许 | 允许 | 允许 |
| 可重复读 | 不允许 | 不允许 | 允许 |
| 串行化 | 不允许 | 不允许 | 不允许 |
持久性（Durability）：事务一旦提交，它对数据库中对应数据的状态变更就应该是永久性的。
分布式事务：
单机环境下很容易实现ACID特性的事务处理系统，但分布式数据库中，数据分散在不同的机器上，对数据进行分布式处理具有非常大的挑战性。通常一个分布式事务会涉及对多个数据源或业务系统的操作。设想一个典型的分布式事务场景：跨行转账涉及调用两个异地的银行服务，其中是一个本地银行的取款服务，另一个是目标银行提供的存款服务。两个服务本身是无状态并且是相互独立的，共同构成一个完整的分布式事务。通过这个例子我们了解到一个分布式事务可以看作多个分布式操作序列组成。如上述的取款和存款服务，通常把这一系列分布式操作序列称为子事务。由于分布式事务中，子事务的执行是分布式的，因此要实现能保证ACID特性的分布式事务处理系统就显得格外复杂。
CAP和BASE理论
CAP理论告诉我们，一个分布式系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个基本需求。最多同时满足其中两项。
一致性（C）：在分布式环境中，一致性是指数据在多个副本之间是否能保持一致的特性。在分布式系统中，如果能做到针对一个数据项的更新操作执行完成后，所有的用户都可以读取到其最新的值，那么这样的系统就被认为具有强一致性（或严格的一致性）。
可用性（A）：指系统提供的服务必须一直处于可以的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。有限时间指对于用户的一个请求，系统必须在指定时间（即响应时间）内返回对应的处理结果，如果超过这个时间规范，那么系统就被认为不可以用。
分区容错性（P）：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可以性的服务，除非是整个网络环境都发送了故障。
CAP定理应用
| 放弃CAP定理 | 说 明 |
| 放弃P |
如果希望避免系统出现分区容错性问题，一种较为简单的做法就是将所有数据都放在一个分布式节点上。这样的做法不能100%保证系统不出错，但至少不会碰到由于网络分区带来的负面影响。同时放弃P也意味着放弃了系统的可扩展性 |
| 放弃A |
相对于放弃P来说，放弃可用性正好相反。其做法是一旦系统遇到网络分区或其他故障时，受影响的服务需要等待一定的时间，因此在等待期间系统无法对外提供正常服务，即不可用 |
| 放弃C |
放弃一致性，并不是完全不需要数据一致性，如果是这样的话，那么系统的数据都是无意义的。事实上，放弃一致性指放弃数据的强一致性，保留数据的最终一致性。这样的系统无法保证数据保持实时的一致性，但能够保证数据最终会达到一个一致的状态。这就引入了一个时间窗口的概念，具体多久能达到数据一致性取决于系统的设计。主要包括数据副本在不同节点之间的复制时间长短。 |
从CAP定理我们可以看出，一个分布式系统不可能同时满足一致性、可用性和分区容错性。但对于一个分布式系统而言，分区容错性可以说是最基本的要求。因为分布式系统中，组件必然要被部署到不同节点，否则就无所谓分布式。对于分布式系统，网络问题是一个必定会出现的异常情况，因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题。BASE是对CAP中一致性和可用性权衡的结果，核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身业务特点，采用适当的方式使系统达到最终一致性（Eventual consistency）。
BASE三要素
基本可用：指分布式系统在出现不可预知故障时，允许损失部分可用性。不等价于系统不可用。
典型例子：
1、响应时间上的损失：由于故障导致某功能，如查询结果的响应时间增加到1-2秒。
2、功能上的损失：正常情况下，在电商网站购物，消费者几乎能够顺利完成每一笔订单，当购物高峰时，由于消费者购物行为激增，为保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
弱状态：也称软状态，和硬状态相对、指允许系统中数据存在中间状态，并认为该中间状态的存在不影响系统的整体可用性。即允许系统在不同节点的数据副本之间进行数据同步的过程中存在延时。
最终一致性：强调系统中所有数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。并不需要实时保证系统数据的强一致性。