《从零开始学架构、从paxos到zookeeper》读书笔记五：分布式系统基本理论

首先要说的就是何为分布式，在<<分布式系统概念与设计>>一书中，对分布式系统做了如下定义

分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息进行通信和协调的系统。

上面这个简单的定义几乎涵盖了所有有效地部署了网络化计算机的系统。这也就意味着没有地理约束。下面总结一下分布式系统的几个特征：
1.分布性
分布式系统中的多台计算机都会在空间上随意分布，同时，机器的分布情况也会随时变动。
2.对等性
分布式系统中的计算机没有主从之分，即没有控制整个系统的主机，也没有被控制的从机，组成分布式的所有计算机节点是对等的。副本是分布式系统常见的概念之一，指的是分布式系统对数据和服务提供的一种冗余的方式。
3.并发性
多个节点并发操作数据。
4.缺乏全局时钟
很难定义两个事件先后发生的顺序，因为缺乏全局时钟。
5.故障总是会发生
下面总结了几个经典的分布式环境中会遇到的问题：
1.通信异常（如何应对消息的延迟和消息丢失）
2.网络分区（当网络通信异常后，只有部分节点可以通信，另一些节点不能通信造成的网络分区，如何去解决出现分区时小规模集群独立完成任务的问题，并保证数据的完整性和一致性）
3.三态（即成功，超时，失败；具体包括请求发送失败和请求响应失败）
  在通常的集中式系统中，我们所谓的事务通常被狭隘的理解为数据库事务，数据库事务可以在应用程序之间提供一个隔离方法，以防止彼此的操作互相干扰，另一方面数据库事务还提供了一个从失败中恢复到正常状态的方法，同时提供了数据库即使在异常状态下任然能保证数据一致的办法。所以基本的ACID特性就可以保障我们在集中式系统中的数据的一致性，说到ACID我们并不陌生，让我们一起回顾一下这些基本的概念：
原子性(atomicity):事务中包含的各项操作在执行的过程中要么全成功，要么全失败
一致性(consistency):一个事务在执行之前和执行之后，数据库必须处于一致的状态
持久性(durability):事务一但提交，他对数据库的变更就应该是永久性的。
隔离性(isolation):并发的事务是相互隔离的，一个事务不能被其他事务干扰，在标准的SQL规范中定义了四个数据库事务的隔离级别：
1.未授权读：即读未提交，存在脏读，不可重复读，幻读
2.授权读取：即读已提交，不存在脏读，不可重复读，存在幻读（常用）
3.可重复读：简单的说，就是保证在事务的处理过程中，多次读取同一个数据时，其值是和数据开始时一样的。还是存在幻读的问题。
4.串行化：最高的事务隔离级别，可以防止幻读，不可重复读和幻读。
  但是随着计算机的发展，分布式系统的出现，为了保证ACID特性就显得格外复杂了，其中就诞生了很多经典的理论，这里要说的是CAP理论和BASE理论
CAP理论即是（consistence,availability,partition tolerance）三个单词的缩写，又被称作布鲁尔定律，埃里克.布鲁尔提出了一个假设，在一个分布式系统中，当涉及读写操作时，只能保证一致性，可用性，分区容错性三者中的两个，另外一个必须被牺牲。
一致性的描述：对某个指定的客户端来说，读操作保证能够返回最新的写操作的结果。
可用性的描述：非故障的节点在合理的时间返回合理的响应（正确的业务结果）
分区容错性的描述：当出现分区后系统能够继续履行职责（保证业务的正常处理）
CAP关注的粒度是数据而不是整个系统，CAP假设是忽略网络延时的这是需要我们关注的两个地方。我们在设计的时候不是说我们的系统是CP的或AP的，而是针对数据来说，比如用户重要的数据比如账号数据，我们需要CP的策略，而用户的兴趣爱好这些数据可以采用AP策略。因为现实中网络延时必不可少，对于严格的业务场景来说CP策略也不能保障我们的数据的安全，这时唯一的方案也只能是单点写入，其他节点做备份的策略。
  在实际的分布式环境下我们的分区容错性是个必选项，因为我们无法保证网络百分百可靠，那么在分布式实践中往往只能采用CP或者AP架构，但也不是放弃CA，因为系统99.999%的时间都是正常的,分区期间放弃C或A，并不意味着永久放弃，我们可以在分区期间做一些操作，从而让分区故障恢复后，系统能够重新达到CA的状态。最典型的的及是在分区期间记录日志，当故障解决后，系统根据日志来进行数据恢复，以用户管理系统为例，对于用户账号数据，假设我们选择了CP，则分区发生后，节点一可以继续注册新的用户，节点二无法注册新的用户，节点一可以重新注册节点二处理失败的任务，并记录在日志中，当节点二故障恢复后再从节点一同步数据过来这样又回到了CA状态。
对于用户信息数据，假设我们选择了AP，则分区发生后，节点一和节点二都可以修改用户信息，但是两边就有可能出现数据不一致的情况，当故障恢复后我们可以按照某种规则去合并数据，比如修改的先后顺序进行数据合并，这样我们的数据又回到了CA状态。
最后我们谈一下BASE理论，理解了CAP我们就很容易理解BASE理论，它强调的有三点
1.分布式系统出现故障时，允许损失部分可用性，即保证核心应用
2,允许存在中间状态，而该中间状态不会影响系统整体的可用性，即是CAP中的数据不一致的问题。
3.最终一致性，其实就是在讲CAP中谈到的如何在AP场景下保证CA，让数据最终一致就可以。
说白了BASE理论其实就是CAP中AP方案的延伸，保证了数据的最终一致性。