随着计算机系统规模变得愈来愈大,将全部的业务单元集中部署在一个或若干个大型机上的体系结构,已经愈来愈不能知足当今计算机系统,尤为是大型互联网系统的快速发展,各类灵活多变的系统架构模型层出不穷。分布式的处理方式愈来愈受到业界的青睐——计算机系统正在经历一场史无前例的从集中式向分布式架构的变革。数据库
所谓的集中式系统就是指由一台或多台主计算机组成中心节点,数据集中存储于这个中心节点中,而且整个系统的全部业务单元都集中部署在这个中心节点上,系统的全部功能均由其集中处理。服务器
集中式系统的最大的特色就是部署结构很是简单,底层通常采用从IBM、HP等厂商购买到的昂贵的大型主机。所以无需考虑如何对服务进行多节点的部署,也就不用考虑各节点之间的分布式协做问题。可是,因为采用单机部署,极可能带来系统大而复杂、难于维护、发生单点故障(单个点发生故障的时候会波及到整个系统或者网络,从而致使整个系统或者网络的瘫痪)、扩展性差等问题。网络
分布式系统是一个硬件或软件组件分布在不一样的网络计算机上,彼此之间仅仅经过消息传递进行通讯和协调的系统。简单来讲就是一群独立计算机集合共同对外提供服务,可是对于系统的用户来讲,就像是一台计算机在提供服务同样。分布式意味着能够采用更多的普通计算机(相对于昂贵的大型机)组成分布式集群对外提供服务。计算机越多,CPU、内存、存储资源等也就越多,可以处理的并发访问量也就越大。架构
从分布式系统的概念中咱们知道,各个主机之间通讯和协调主要经过网络进行,因此分布式系统中的计算机在空间上几乎没有任何限制,这些计算机可能被放在不一样的机柜上,也可能被部署在不一样的机房中,还可能在不一样的城市中,对于大型的网站甚至可能分布在不一样的国家和地区。可是,不管空间上如何分布,一个标准的分布式系统应该具备如下几个主要特征:并发
分布性分布式
分布式系统中的多台计算机之间在空间位置上能够随意分布,同时,机器的分布状况也会随时变更。高并发
对等性网站
分布式系统中的计算机没有主/从之分,即没有控制整个系统的主机,也没有被控制的从机,组成分布式系统的全部计算机节点都是对等的。副本(Replica)是分布式系统最多见的概念之一,指的是分布式系统对数据和服务提供的一种冗余方式。在常见的分布式系统中,为了对外提供高可用的服务,咱们每每会对数据和服务进行副本处理。数据副本是指在不一样节点上持久化同一份数据,当某一个节点上存储的数据丢失时,能够从副本上读取该数据,这是解决分布式系统数据丢失问题最为有效的手段。另外一类副本是服务副本,指多个节点提供一样的服务,每一个节点都有能力接收来自外部的请求并进行相应的处理。搜索引擎
并发性计算机网络
在一个计算机网络中,程序运行过程的并发性操做是很是常见的行为。例如同一个分布式系统中的多个节点,可能会并发地操做一些共享的资源,如何准确并高效地协调分布式并发操做也成为了分布式系统架构与设计中最大的挑战之一。
缺少全局时钟
在分布式系统中,很难定义两个事件究竟谁先谁后,缘由就是由于分布式系统缺少一个全局的时钟序列控制。
故障老是会发生
组成分布式系统的全部计算机,都有可能发生任何形式的故障。除非需求指标容许,在系统设计时不能放过任何异常状况。
通讯异常
分布式系统须要在各个节点之间进行网络通讯,所以网络通讯都会伴随着网络不可用的风险或是系统不可用都会致使最终分布式系统没法顺利完成一次网络通讯。另外,即便分布式系统各节点之间的网络通讯可以正常进行,其延时也会远大于单机操做,会影响消息的收发的过程,所以消息丢失和消息延迟变得很是广泛。
网络分区
当网络因为发生异常状况,致使分布式系统中部分节点之间的网络延时不断增大,最终致使组成分布式系统的全部节点中,只有部分节点之间可以进行正常通讯,而另外一些节点则不能——咱们将这个现象称为网络分区,就是俗称的“脑裂”。当网络分区出现时,分布式系统会出现局部小集群,在极端状况下,这些局部小集群会独立完成本来须要整个分布式才能完成的功能,这就对分布式一致性提出类很是大的挑战。
三态
分布式系统的每一次请求与响应,存在特有的“三态”概念,即成功、失败与超时。当出现超时现象时,网络通讯的发起方是没法肯定当前请求是否被成功处理的。
节点故障
节点故障则是分布式环境下另外一个比较常见的问题,指的是组成分布式系统的服务器节点出现的宕机或“僵死”现象。
在单机数据库中,咱们很容易可以实现一套知足ACID特性的事务处理系统,但在分布式数据库中,数据分散在不一样的机器上,如何对这些数据进行分布式的事务处理具备很是大的挑战。可是在分布式计算领域,为了保证分布式应用程序的可靠性,分布式事务是没法回避的。
分布式事务是指事务的参与者、支持的服务器、资源服务器以及事务管理器分别位于分布式系统的不一样节点之上。一般一个分布式事务中会涉及对多个数据源或业务系统的操做。一个最典型的分布式事务场景:一个跨银行的转帐操做涉及调用两个异地的银行服务,其中一个是本地银行提供的取款服务,另外一个则是目标银行提供的存款服务,这两个服务自己是无状态而且是互相独立的,共同构成了一个完整的分布式事务。
对于一个高访问量、高并发的互联网分布式系统来讲,若是咱们指望实现一套严格知足ACID特性的分布式事务,极可能出现的状况就是在系统的可用性和严格一致性之间出现冲突——由于当咱们要求分布式系统具备严格一致性时,极可能就须要牺牲掉系统的可用性。但毋庸置疑的一点是,可用性又是一个全部消费者不容许咱们讨价还价的系统属性,好比淘宝网这样在线网站就要求可以7*24小时不间断地对外提供服务,而对于一致性,则更加是全部消费者对于一个软件系统的刚需。所以,在可用性和一致性之间永远没法存在一个一箭双鵰的方案,因而如何构建一个兼顾可用性和一致性的分布式系统成为了无数工程师探讨的难题,出现了诸如CAP和BASE这样的分布式系统经典理论。
CAP理论告诉咱们,一个分布式系统不可能同时知足一致性(C:Consistency)、可用性(A:Availability)和分区容错性(P:Partition tolerance)这三个基本需求,最多只能同时知足其中的两项。
一致性
在分布式环境中,一致性是指数据在多个副本之间是否可以保持一致性的特性。在一致性的需求下,当一个系统在数据一致性的状态下执行更新操做后,应该保证系统的数据仍然处于一致的状态。在分布式系统中,若是可以作到针对一个数据项的更新操做执行成功后,全部的用户均可以读取到其最新的值,那么这样的系统被认为具备强一致性(或严格的一致性)。
可用性
可用性是指系统提供的服务必须一直处于可用的状态,对于用户的每个操做请求老是可以在有限的时间内返回结果。
分区容错性
分区容错性约束了一个分布式系统须要具备以下特性:分布式系统遇到任何网络分区故障的时候,仍然须要可以保证对外提供知足一致性的可用性的服务,除非是整个网络环境环境都发生了故障。须要注意的是,组成一个分布式系统的每一个节点的加入与退出均可以看做是一个特殊的网络分区。
在进行对CAP定理的应用时,咱们就须要抛弃其中的一项,下表是抛弃CAP定理中任意一项特性的场景说明。
放弃CAP定理 | 说明 |
---|---|
放弃P | 若是但愿可以避免系统出现分区容错性问题,一种较为简单的作法是将全部的数据都放在一个分布式节点上。这样的作法虽然没法100%地保证系统不会出错,但至少不会碰到因为网络分区带来的负面影响。但同时须要注意的是,放弃P的同时也就意味着放弃类系统的可扩展性 |
放弃A | 放弃可用性,一旦系统遇到网络分区或其余故障时,那么受到影响的服务须要等待必定的时间,所以在等待期间系统没法对外提供正常的服务,即不可用 |
放弃C | 事实上,放弃一致性指的是放弃数据的强一致性,而保留数据的最终一致性。这样的系统没法保证数据保持实时的一致性,可是可以承诺的是,数据最终会达到一个一致的状态。这就引入了一个时间窗口的概念,具体多久可以达到数据一致取决于系统的设计,主要包括数据副本在不一样节点之间的复制时间长短 |
对于一个分布式系统,分区容错性能够说是一个最基本的要求。既然是分布式系统,那么分布式系统中的组件必然须要被部署到不一样的节点,不然也就无所谓分布式系统了,所以必然出现子网络。而对于分布式系统而言,网络问题又是一个一定会出现的异常状况,所以分区容错性也就称为了一个分布式系统必然须要面对和解决的问题。所以系统架构设计师每每须要把精力花在如何根据业务特色在C(一致性)和A(可用性)之间寻求平衡。
BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的简写,是由eBay的架构师提出的。BASE是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的总结,是基于CAP定理逐步演化而来的,其核心思想是即便没法作到强一致性(Strong consistency),但每一个应用均可以根据自身的业务特色,采用适当的方式来使系统达到最终一致性(Eventual consistency)。
基本可用
基本可用是指分布式系统在出现不可预知故障的时候,容许损失部分可用性——但请注意,这毫不等价于系统不可用。“基本可用”的典型例子:
一、响应时间上损失:正常状况下,一个在线搜索引擎须要在0.5秒以内返回给用户相应的查询结果,但因为出现故障,查询结果的响应 时间增长到了1-2秒。
二、功能上的损失:正常状况下,在一个电子商务网站上进行购物,消费者几乎可以顺利地完成每一笔订单,可是在大促购物高峰的时候,因为消费 者的购物行为激增,为了保护购物系统的稳定性,部分消费者可能被引导到一个降级页面。
弱状态
弱状态也称为软状态,和硬状态相对,是指容许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的总体可用性,即容许系统在不一样节点的数据副本之间进行数据同步的过程存在延时。
最终一致性
最终一致性强调的是系统中全部的数据副本,在通过一段时间的同步后,最终可以达到一个一致的状态。所以,最终一致性的本质是须要系统保证最终数据可以达到一致,而不须要实时保证系统数据的强一致性。
从Paxos到Zookeeper分布式一致性原理与实践