关于分布式系统的思考

摘要

谈及一些分布式系统的理论和思想，包括CAP、BASE、NWR等。并简单分析一些主流数据库分布式方案的利弊，以便咱们在开发时更深刻全面地进行思考、选择和设计。

正文

在讨论常见架构前，先简单了解下CAP理论：

CAP 是 Consistency、Availablity 和 Partition-tolerance 的缩写。分别是指：

1. 一致性（Consistency）：每次读操做都能保证返回的是最新数据；

2. 可用性（Availablity）：任何一个没有发生故障的节点，会在合理的时间内返回一个正常的结果；

3. 分区容忍性（Partition-tolerance）：当节点间出现网络分区，照样能够提供服务。

CAP理论指出：CAP三者只能取其二，不可兼得。其实这一点很好理解：

• 首先，单机系统都只能保证CP。

• 有两个或以上节点时，当网络分区发生时，集群中两个节点不能互相通讯。此时若是保证数据的一致性C，那么必然会有一个节点被标记为不可用的状态，违反了可用性A的要求，只能保证CP。

• 反之，若是保证可用性A，即两个节点能够继续各自处理请求，那么因为网络不通不能同步数据，必然又会致使数据的不一致，只能保证AP。

1、单实例

单机系统很显然，只能保证CP，牺牲了可用性A。单机版的MySQL，Redis，MongoDB等数据库都是这种模式。

实际中，咱们须要一套可用性高的系统，即便部分机器挂掉以后仍然能够继续提供服务。

2、多副本

相比于单实例，这里多了一个节点去备份数据。

对于读操做来讲，由于能够访问两个节点中的任意一个，因此可用性提高。

对于写操做来讲，根据更新策略分为三种状况：

1. 同步更新：即写操做须要等待两个节点都更新成功才返回。这样的话若是一旦发生网络分区故障，写操做便不可用，牺牲了A。

2. 异步更新：即写操做直接返回，不须要等待节点更新成功，节点异步地去更新数据。
   这种方式，牺牲了C来保证A。即没法保证数据是否更新成功，还有可能会因为网络故障等缘由，致使数据不一致。

3. 折衷：更新部分节点成功后便返回。

这里，先介绍下类Dynamo系统用于控制分布式存储系统中的一致性级别的策略——NWR：

• N：同一份数据的副本个数

• W：写操做须要确保成功的副本个数

• R：读操做须要读取的副本个数

当W+R>N时，因为读写操做覆盖到的副本集确定会有交集，读操做只要比较副本集数据的修改时间或者版本号便可选出最新的，因此系统是强一致性的；反之，当W+R<=N时是弱一致性的。

如：(N,W,R)=(1,1,1)为单机系统，是强一致性的；(N,W,R)=(2,1,1)为常见的master-slave模式，是弱一致性的。

举例：

• 如像Cassandra中的折衷型方案QUORUM，只要超过半数的节点更新成功便返回，读取时返回多数副本的一致的值。而后，对于不一致的副本，能够经过read repair的方式解决。
  read repair：读取某条数据时，查询全部副本中的这条数据，比较数据与大多数副本的最新数据是否一致，若否，则进行一致性修复。其中，W+R>N，故而是强一致性的。

• 又如Redis的master-slave模式，更新成功一个节点即返回，其余节点异步地去备份数据。这种方式只保证了最终一致性。
  最终一致性：相比于数据时刻保持一致的强一致性，最终一致性容许某段时间内数据不一致。可是随着时间的增加，数据最终会到达一致的状态。其中，W+R<N，因此只能保证最终一致性。

此外，N越大，数据可靠性越好。可是因为W或R越大，写或读开销越大，性能越差，因此通常须要综合考虑一致性、可用性和读写性能，设置 W、R 都为 N/2 + 1。

其实，折衷方案和异步更新的方式从本质上来讲是同样的，都是损失必定的C来换取A的提升。并且，会产生‘脑裂’的问题——即网络分区时节点各自处理请求，没法同步数据，当网络恢复时，致使不一致。

通常的，数据库都会提供分区恢复的解决方案：

1. 从源头解决：如设定节点通讯的超时时间，超时后‘少数派’节点不提供服务。这样便不会出现数据不一致的状况，不过可用性下降。

2. 从恢复解决：如在通讯恢复时，对不一样节点的数据进行比较、合并，这样可用性获得了保证。可是在恢复完成以前，数据是不一致的，并且可能出现数据冲突。

光这样还不够，当数据量较大时，因为一台机器的资源有限并不能容纳全部的数据，咱们会想把数据分到好几台机器上存储。

3、分片

相比于单实例，这里多了一个节点去分割数据。

因为全部数据都只有一份，一致性得以保证；节点间不须要通讯，分区容忍性也有。

然而，当任意一个节点挂掉，丢失了一部分的数据，系统可用性得不到保证。

综上，这和单机版的方案同样，都只能保证CP。

那么，有那些好处呢？

1. 某个节点挂掉只会影响部分服务，即服务降级；

2. 因为分片了数据，能够均衡负载；

3. 数据量增大／减少后能够相应地扩容／缩容。

   大多数的数据库服务都提供了分片的功能。如Redis的slots，Cassandra的partitions，MongoDB的shards等。

基于分片解决了数据量大的问题，但是咱们仍是但愿咱们的系统是高可用的，那么，如何牺牲必定的一致性去保证可用性呢？

4、集群

能够看到，上面这种方式综合了前两种方式。同上分析，采用不一样的数据同步策略，系统的CAP保证各有不一样。不过，通常数据库系统都会提供可选的配置，咱们根据不一样的场景选择不一样的策略以实现不一样的特性。

其实，对于大多数的非金融类互联网公司，要求并不是强一致性，而是可用性和最终一致性的保证。这也是NoSQL流行于互联网应用的一大缘由，相比于强一致性系统的ACID原则，它更加倾向于BASE：

• Basically Available: 基本可用，即容许分区失败，出了问题仅服务降级；

• Soft-state: 软状态，即容许异步；

• Eventual Consistency: 最终一致性，容许数据最终一致，而不是时刻一致。

5、总结

基本上，上面讨论的几种方式已经涵盖了大多数的分布式存储系统了。咱们能够看到，这些个方案老是须要经过牺牲一部分去换取另外一部分，总无法达到100%的CAP。

选择哪一种方案，依据就是在特定场景下，究竟哪些特性是更加剧要的了。

---

做者信息
本文系力谱宿云LeapCloud旗下MaxLeap团队_Service&Infra成员：吕舜 【原创】
力谱宿云LeapCloud 首发：https://blog.maxleap.cn/archi...
吕舜，主攻Java，对Python、数据分析也有关注。从业期间，负责过订阅系统、App制做云服务、开源BaaS平台、分布式任务调度系统等产品的设计研发工做。现任MaxLeap基础服务与架构成员，负责云服务系统相关的设计与开发。

相关阅读

微服务实战：从架构到发布（一）
微服务实战：从架构到发布（二）
移动云平台的基础架构之旅（一）：云应用
从应用到平台 – 云服务架构的演进过程

做者往期佳做_曾选登CSDN头版

RabbitMQ在分布式系统的应用

欢迎关注微信公众号：MaxLeap_yidongyanfa

---

活动预告

报名连接：http://t.cn/Rt9ooRw