一、什么是分布式系统

分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。在定义中,我们可用看出,分布式系统它通过多工作节点来解决单机系统面临的成本和可用性问题,但是它引入了对分布式系统内部工作节点的协调问题。

一个业务分拆多个子业务,部署在不同的服务器上。 然后通过一定的通信协议,能够让这些子业务之间相互通信。

二、分布式系统CAP

1. 分布式系统非常关注三个指标:

数据一致性

系统可用性

节点连通性与扩展性

关于一致性

数据“强一致性”,是希望系统只读到最新写入的数据,例如:通过单点串行化的方式,就能够达到这个效果。

关于session一致性,DB主从一致性,DB双主一致性,DB与Cache一致性,数据冗余一致性,消息时序一致性,分布式事务一致性,库存扣减一致性,详见文章《究竟啥才是互联网架构“一致性”》。

关于可用性

如果系统每运行100个时间单位,会有1个时间单位无法提供服务,则说系统的可用性是99%。

可用性和可靠性是比较容易搞混的两个指标,以一台取款机为例:

正确的输入,能够取到正确的钱,表示系统可靠

取款机7*24小时提供服务,表示系统可用

保证系统高可用的方法是:

冗余

故障自动转移

反向代理层,站点层,服务层,缓存层,数据库层各层保证系统高可用的方法,详见文章《究竟啥才是互联网架构“高可用”》。

关于连通性与扩展性

分布式系统,往往有多个节点,每个节点之间,都不是完全独立的,需要相互通信,当发生节点无法联通时,数据是否还能保持一致,系统要如何进行容错处理,是需要考虑的。

同时,连通性和扩展性紧密相关,想要加机器扩展性能,必须有良好的连通性。当一个节点脱离系统,系统就出现问题,往往意味着系统是无法扩展的。

反向代理层,站点层,服务层,缓存层,数据库层各层保证系统扩展性的方法,详见文章《究竟啥才是互联网架构“可扩展”》。

2. 什么是CAP定理?

CAP定理,是对上述分布式系统的三个特性,进行了归纳:

一致性(Consistency)

可用性(Availability)

分区容忍性(Partition Tolerance)

并且,定理指出,在系统实现时,这三者最多兼顾两点。

一致性,可用性,多节点扩展性三者只能取其二,既然加锁已经加上,常见的最佳工程架构实践是什么呢?

互联网,最常见的实践是这样的:

节点连通性,多节点扩展性,连通性异常的处理必须保证,满足P

一致性C与可用性A一般二选一

选择一致性C,举例:传统单库水平切分,就是这类选型的典型

选择可用性A,举例:双主库同步高可用,就是这类选型的典型

强一致很难怎么办?

单点串行化,虽然能保证“强一致”,但对系统的并发性能,以及高可用有较大影响,互联网的玩法,更多的是“最终一致性”,短期内未必读到最新的数据,但在一个可接受的时间窗口之后,能够读到最新的数据。

例如:数据库主从同步,从库上的数据,就是一个最终的一致。

三、BASE理论

eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结,在ACM上发表文章提出BASE理论,BASE理论是对CAP理论的延伸,核心思想是即使无法做到强一致性(StrongConsistency,CAP的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。

BASE是CAP理论中AP方案的延伸,对于C我们采用的方式和策略就是保证最终一致性。

(Basically Available)基本可用

在分布式系统出现故障的时候,允许损失部分可用性,即保证核心可用。

(Soft State)软状态

接受一段时间的状态不同步,及中间状态,而该中间状态不影响系统整体可用性。这里的中间状态就是CAP理论中的数据不一致性,即不同的 data replication(数据备份节点)之间的数据更新可以出现延时的最终一致性。

(Eventually Consistent)最终一致性

上面说软状态,然后不可能一直是软状态,必须有个时间期限。在期限过后系统能够保证在没有其他新的更新操作的情况下,数据最终一定能够达到一致的状态,因此所有客户端对系统的数据访问最终都能够获取到最新的值。