分布式系统基础的基本概念

前言

最近在工做之余看了一些分布式系统的博客和一点书本知识，从理论上了解了一些分布式系统的基本知识。给我最深的感受就是全部的软件技术和架构都是随着业务的不断发展和底层技术的更新才有机会一步步的深刻。特别是学习cap和base时，了解到分布式事务与传统DB事务ACID的区别（其实分布式事务和传统DB事务不是一个层面的东西可是感受思想上仍是有一些共同之处的）。如今的分布式系统也都是由最初的集中式系统一步步发展过来的。

在这里总结一下最近学的一些基础吧~~

集中式与分布式

很容易理解：

• 集中式：一台或多态住计算机组成中心节点，数据集中存储于中心节点上，而且系统全部的业务单元都集中部署在这个中心节点上，并在其上处理系统全部功能。
  • 其实个人理解就是说全部的业务和逻辑都在这个中心节点上完成，其余的客户端就负责输入和输出就能够了。
• 分布式：分布式系统是一个硬件或软件组件分布在不一样的网络计算机上，彼此之间仅仅经过消息传递进行通讯和协调的系统。
  • 这是经典的分布式著做《分布式系统概念与设计》中的定义。其实在个人理解里，就是把一个大的系统拆分红不少个业务模块，并部署在多台网络计算机上。就是把集中式的中心节点拆分为多个节点去完成单个中心节点的工做。
  • 分布式系统的几个特色：
    • 分布性：分布式系统的多个节点或者说多个模块在空间上是随意分布的。
    • 对等性：系统模块的多个节点没有主从之分。其实这里我理解的没有主从之分并非说完彻底全没有主节点和从节点，而是在任什么时候候，若是有主节点，且主节点发生了不可用的状况下，能有必定的方法让别的节点去取代它，这样的话系统中就没有一个节点是所谓的特殊的，而全部的节点都是同样的能够互相替换的，这某种程度上应该就是分布式系统中的副本的概念。而副本的话应该是分为服务副本和数据副本的，由于服务和数据均可能会出现不可用的现象，因此必需要有副本去保持系统可用。
    • 并发性：很好理解，分布式系统中程序的并发性操做和对数据的并发访问是很常见的。其实也由于并发性，如何作到高效准确也就成为了分布式系统的一个难题。
    • 缺少全局时钟：一样的，由于分布式系统部署在多台网络计算机上，因为网络的存在很难定义事务的前后顺序。也就是说分布式系统缺乏全局的始终顺序控制。以前在学习的时候看到过度布式全局惟一ID能够解决部分问题，以后能够再看看总结一下。我目前了解的分布式全局ID的生成有UUID和SNOWFLAKE算法，可是具体的底层还不是很清楚。
    • 故障老是会发生：分布式系统相较集中式系统更容易发生故障，且在系统设计时考虑到的西昌在实际中是必定会发生的，因此必需要解决。（固然，若是是业务或者需求容许的能够考虑必定程度的放宽。）

分布式系统的问题

进程或节点之间的通讯异常

其实如在Zookeeper学习（一）中描述的同样，致使分布式系统通讯异常的根本罪魁祸首就在于网络！由于网络自己就是不可靠的。与单机系统不一样的是，因为分布式系统中网络通讯的存在，会致使系统之间的调用存在相对较大的延迟（可达到内存访问延迟的百倍）。并且网络随时会出现波动的状况，所以消息丢失和延迟会变得很广泛。

网络分区

因为网络发生异常，致使分布式系统中部分节点之间的网络延时不断增大，致使全部节点中只有部分节点能互相正常通讯，而其余的不能。这其实就是所谓的“脑裂”。最差的状况甚至会出现多个局部小集群的状况。

三态

三态即成功，失败，超时。

单机系统中调用服务成功失败很明显，可是在分布式系统中很明显，由于存在网络的因素，在调用服务失败的状况下可能并不必定是由于没有调用服务成功。

• 调用服务确实没有成功，网络请求没有发送到接收方。
• 调用服务成功，可是在返回响应时出现了消息丢失。

这时候就须要针对不一样的业务进行处理了。结合咱们以前作的业务，咱们的系统中处理办法是回写时会让服务发送接收OK的标志，若是没有收到OK，那么就会一直发，由于回写的接收方在逻辑里支持删除不存在的元素（其实就是不删），只有收到了OK才会把回写的内容从Redis里删掉。这样就保证了回写必定会成功。

节点故障

很好理解，每一台机器都是会出问题的，如何保证在部分节点出现问题时整个系统仍然可用，是分布式系统里永恒不变的问题！

从ACID到CAP/BASE

ACID

ACID是传统数据库中事务的特征，即原子性，一致性，隔离性和持久性。

• 原子性：指事务必须是一个原子的操做单元。也就是说事务要么所有执行成功，要么不执行，若是执行过程当中失败那么就回滚到最初的状态。
• 一致性：事务的执行不能够破坏数据库数据的完整性和一致性。也就是说事务在执行先后，数据库都必须处于一致性的状态。其实当初学数据库的时候一开始并不太理解为何既然有原子性了，事务要么执行完要么不执行，为啥还会出现一致性的问题。后来才知道是由于多个事务并发执行的时候，很容易出现a事务作了x=1的操做，而后b事务又作了x=0的操做，就至关于b事务直接把a事务的操做给覆盖了，这就破坏了数据库的一致性。
• 隔离性：并发坏境中，事务是互相隔离的，一个事物的执行不能被其余事务干扰。这就是为了防止上面说的一致性的问题。而数据库里规定了4个隔离级别：
  • 读未提交：会出现脏读，不可重复读，幻读问题。隔离级别最低。
  • 读提交：解决脏读，但不可重复读，幻读仍是会有。
  • 可重复读：会存在幻读问题，但前两个问题不会有。
  • 序列化：至关于事务顺序执行，不会有上述问题，但并发程度最低，效率也最低。
  • mysql里利用了MVCC和锁的机制实现了隔离级别，可是这部分我也只是知道个大概，底层的实现原理尚未来得及深究，以前看了几篇博客记录下，以后深刻学习Mysql的时候这部分要深刻学习下。
  • Mysql数据库事务的隔离级别和锁的实现原理分析
  • [MySQL的四种事务隔离级别](https://www.cnblogs.com/huanongying/p/7021555.html)
  • MySQL事务隔离级别的实现原理
  • Mysql锁详解
• 持久性：一个事物一旦提交，它对数据库中对应数据的状态变动应该是永久性的。也就是说事务一旦成功结束，那么它对数据库所作的更新必须被永久保存下来。

CAP

CAP理论是针对分布式事务的一套理论。所谓分布式事务就是事物的参与者，支持十五的服务器，资源服务器以及事务管理器分别位于分布式系统的不一样节点上。一般一个分布式事务会涉及对多个数据源或业务系统的操做。

CAP指的是一个分布式系统不可能同时知足一致性，可用性和分区容错性这三个基本要求，最多只能同时知足其中的两项。

• 一致性：在分布式环境中，一致性是指数据在多个副本之间是否可以保持一致的特性。也就是说，当一个系统在数据一致的状态下执行更新操做后，应该保证系统的数据仍然出于一致的状态。
  • 分布式系统里，若是数据副本分布在不一样分布式节点上，若对第一个节点的数据进行了更新操做而且更新成功后，却没有使得第二个节点上的数据获得相应更新，那么若是系统是从第二个节点上读的数据，那么就会读到老数据，就出现了不一致的状况。
  • 分布式系统的一致性和单机事务的一致性有很大的区别，以前本身一直能感受到不同可是很难用理论化的语言描述出来，ACID的C与CAP的C区别这篇博客介绍的很是很是好，能够看！！！
• 可用性：系统提供的服务必须一直处于可用的状态，对于用户的每个操做请求老是可以在有限的时间内返回结果。有限的时间某种程度上指的是系统的反应时间不能够超过用户的忍耐程度，返回结果则值得是系统对于用户的请求必需要返回一个能够接受的结果。
• 分区容错性：分布式系统由于是依赖网络的，因此不免会出现遇到网络分区故障的时候，而这个时候仍然要保证能对外提供一致性和可用性的服务，除非整个网络瘫痪。
  • 以前我一直分不清可用性和分区容错性的区别，感受只要高可用了不就知足了容错性了么。。。可是参考了不少资料以后才发现分区容错性和可用性，一致性的关系更像是因果（不必定准确）的关系。正是由于分区的存在，因此在须要解决一致性和可用性的问题。
  • CAP理论的P知乎上的这个回答是我认为解释的最通俗易懂的一篇。
  • CAP里的P ，CAP, ACID ，分布式系统设计系列 -- 基本原理及高可用策略， 分布式CAP理论的理解， 这几篇都很好，能够参考。

BASE

BASE = Basically Available + Soft state + Eventually consistent。

• 基本可用：分布式系统出现不可预知故障时，容许损失部分可用性。
  • 响应时间损失。0.5s-->2s
  • 功能损失。双十一淘宝扛不住了把评论服务先降级掉。
• 弱状态：容许系统数据存在中间状态，并认为该中间状态的存在不会影响系统总体可用性，即容许系统在不一样节点的数据副本之间进行数据同步的过程存在延时。
• 最终一致性：系统中全部数据副本，在通过一段时间同步后，最终能打到一个一致的状态。
  • 最终一致性其实是一种特殊的弱一致性。
  • 因果一致性（Casual Consistency）：A进程更新完后通知B，那么B对该数据项的访问应该能获取到A更新后的最新值，且B若是要更新该数据，必须基于进程A更新后的值。
  • 读己写（Read you writes）：A更新一个数据向后，本身老是能访问到更新过的最新值。是一种特殊的因果一致性。
  • 会话一致性（Session Consistency）：对系统数据的访问过程狂顶在一个绘画中，系统能保证在同一个有效的会话中实现Read your writes。即更新操做后，客户端能在同一个绘画中适中读取到该数据项的最新值。
  • 单调读一致性（Monotonic read consistency）：若是一个进程从系统中读取出一个数据项的某一个值后，那么系统对于该进程后续的任何数据访问都不该该返回更旧的值。
  • 单调写一致性（Monotonic write consistency）：一个系统须要可以保证同一个进程的写操做被顺序执行。
  • 数据库的主备通常都采用最终一致性的策略。有两种方式去实现，即同步和异步。同步的方式就是事务完成后主备之间数据就会进行同步，异步的方式备数据库的更新会有必定时间的延迟，可是效率会更高一些。