理解分布式系统— ---- 从ACID到BASE

集中式系统

分布式系统广泛使用之前，我们更多的是熟悉集中式系统，它采用一个或多个计算机构成中心节点，中心节点上集中部署了各个业务单元(war包)，客户端通过某种方式请求服务。

分布式系统

多个节点分布在不同的网络计算机中，彼此通过消息传递来通信并且相互协作。

每个节点都是一个完整逻辑的程序个体。

特点:

• 分布性
  多个进程分布在不同网络中的计算机上。

• 没有全局时钟
  因为多个进程分布在不同网络上的机器中，没有一个全局统一的时钟，来确定谁的消息事件早，谁的消息事件晚。

• 对等性
  系统中的计算机不存在主\从关系，组成分布式系统中的节点都是对等的。副本(replica)在分布式系统中通常指数据的冗余 或者 服务的冗余，通过副本的冗余方式，来解决整体系统的可用性。

• 并发性
  分布式系统中的节点往往会存在数据竞争，如何更好的相互协调各个进程，就要充分考虑并发性

事务

事务：事务是一系列对数据库操作所组成的逻辑单元。

事务具有ACID特点:

Atomicity

原子性，也就是要么事务执行成功、要么事务不执行(失败回滚)，不存在中间状态。

Consistency

一致性，也就是说数据库要么是执行成功的最终结果状态，要么是不执行的状态。数据库不存在事务的中间执行状态。

Isolation

隔离性，多个事务之间执行过程中隔离不可见(不绝对，视隔离级别而定)。

Durability

持久性，就是说是事务一旦提交，数据就会落地，即使发生宕机，重启后看到的也是事务提交后的状态

数据库隔离级别

read uncommited：允许事务A读取到事务B中未提交的对数据的修改(脏读)。

read commited：不允许事务A读取到事务B中未提交的对数据的修改(不允许脏读)。
允许在一个会话中读取另一个会话中事务commit后的数据。

大多数数据库的默认级别（mysql默认是Repeatable Read）。该隔离级别会产生同一个事务中相同查询产生不同结果的情况(故也称为不可重复读)。

**Repeatable read **不允许在一个事务中执行相同查询却返回不同结果。不允许脏读、不允许"不可重复读"，但是依旧可能出现幻读。MySql默认级别。

SerializableRead通过对事务A中依赖的数据加行锁保证其他事务无法对这些数据访问，事务间互斥，最高隔离级别，性能消耗大。

Read Uncommitable——>Read Commitable——>Repeatable Read——>SerializableRead.
从左到右隔离级别递增，整体性能递减.

数据库详细分析请查看：深入理解Mysql——锁、事务与并发控制(辟谣)

分布式事务

分布式系统本身的特点就是“分布”(系统的节点常常部署在不同的网络中），在无法避免分布的前提下，如何保证系统的可用性与数据的一致性便是分布式系统的难点。

CAP

CAP理论主要是说分布式系统在Consistency一致性、Avaliable可用性、Partition tolerance分区容错性三点中，只能保证两点。由于分布式系统无法避开P，那么如何恰当的取舍、平衡A、P便是重点。

Consistency

分布式系统中各个副本的数据保存一致性，比如一个用户对数据做了更新，那么需要保证这个变更的数据对其他用户及时可见。

如果牺牲C(这里指强一致性)，也就是说出现网络分区问题或者其他问题，依旧保证A不受影响，C折中为数据的最终一致性。

---

Avaliable

系统及时响应并无异常的返回数据。(及时响应，正确返回数据)

如果牺牲A，也就是说出现网络分区问题或者其他问题，停止修复，直到问题解决。当然这基本是不能接受的。

---

Partition tolerance

分区：由于分布式系统各个节点存在部署在不同机器、网络的情况，有时会无法避免的因为网络问题，导致一部分节点与其他节点无法正常通信，称为孤立的网络分区。

分区容错性就是要保证当网络分区问题出现时，能够保证系统的可用性与一致性不受影响。

如果牺牲P，也就是说要避免分区问题对CA的影响，我们可以考虑集中式系统或者把事物中依赖的关键数据集中在一个节点，当然也意味着放弃了系统的可扩展行。

CAP总结：分布式系统无法避免P的问题，往往设计系统时根据业务特点，主要考虑如何处理C\A之间的关系。

BASE

BASE主要是在大量实践经验上提出通过合理设计业务模块，在放弃C强一致性的前提下，通过最终一致性保证系统在出现分区等异常时基本可用(Basic Avaliable)。

Basic Avaliable

怎么算基本可用？

• 响应时间上的折中，比如正常情况下系统响应需要10ms，当出现分区异常时，同样的请求损耗为60ms响应。

• 功能上的折中 比如在系统出现分区异常时无法承载大量请求，通过将一部分请求转到降级服务上来满足需求。

Soft State

允许系统中的某些副本不一致的存在(同步数据延迟，认为不影响可用性)，只要保证最终一致性即可。

Eventually Consistency

最终一致

传统数据库的最终一致性常用手段：

以mysql的master slave简单说明下:

通常情况下，mysql的更新只需要master更新成功即可响应客户端，slave可以通过binlog慢慢同步，这种情形读取slave会有一定的延迟，一致性相对较弱，但是系统的可用性有了保证；

另一种slave更新策略，数据的更新操作不仅要求master更新成功，同时要求slave也要更新成功（作为事务的一部分），master 和slave数据保持同步，系统保证强一致性，但可用性相对较差，响应时间变长。

分布式系统常见问题

通信异常
简单来说就是网络异常导致的消息延迟或者消息丢失。

网络分区(脑裂)
就是网络延迟不断加大，导致只有部分的节点之间可以正常通信，而一部分节点无法通信。形成了具备的小集群。

三态问题
三态指的是：成功、失败、超时。相比于传统单机系统，只有成功失败两种状态。

超时又有两种情况：

• 发送方消息未到达服务方处理时丢失
• 服务方反馈消息未到达客户端时丢失
  当出现超时问题，发送方无法知道消息是否被成功处理（可用分布式监控系统监控）。