Linux下分布式系统以及CAP理论分析

CAP理论被很多人拿来作为分布式系统设计的金律,然而感觉大家对CAP这三个属性的认识却存在不少误区,那么什么是CAP理论呢?CAP原本是一个猜想,2000年PODC大会的时候大牛Brewer提出的,他认为在设计一个大规模可扩放的网络服务时候会遇到三个特性:一致性(consistency)、可用性(Availability)、分区容错(partition-tolerance)都需要的情景,然而这是不可能都实现的。之后在2003年的时候,Mit的Gilbert和Lynch就正式的证明了这三个特征确实是不可以兼得的。

CAP是Consistency、Availablity和Partition-tolerance的缩写。分别是指: 1)一致性(Consistency):每次读操作都能保证返回的是最新数据。也就是说所有的节点数据一致! 2)可用性(Availablity):任何一个没有发生故障的节点,会在合理的时间内返回一个正常的结果。也就是说一个或者多个节点失效,不影响服务请求! 3)分区容忍性(Partition-torlerance):当节点间出现网络分区,照样可以提供服务。也就是说节点间的网络连接失效,仍然可以处理请求!

其实,任何一个分布式系统,需要满足这三个中的两个。CAP理论指出:CAP三者只能取其二,不可兼得。其实这一点很好理解,理由如下: 1-  首先,单机都只能保证CP。 2-  有两个或以上节点时,当网络分区发生时,集群中两个节点不能相互通信(也就是说不能保证可用性A)。此时如果保证数据的一致性C,那么必然会有一个节点被标记为不可用的状态,违反了可用性A的要求,只能保证CP。 3- 反正,如果保证可用性A,即两个节点可以继续各自处理请求,那么由于网络不通不能同步数据,必然又会导致数据的不一致,只能保证AP。

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

实际中,我们需要一套可用性高的系统,即使部分机器挂掉之后仍然可以继续提供服务。

二、多副本

相比于单实例,这里多了一个节点去备份数据。 对于读操作来说,因为可以访问两个节点中的任意一个,所以可用性提升。

对于写操作来说,根据更新策略分为三种情况: 1)同步更新:即写操作需要等待两个节点都更新成功才返回。这样的话如果一旦发生网络分区故障,写操作便不可用,牺牲了A。 2)异步更新:即写操作直接返回,不需要等待节点更新成功,节点异步地去更新数据(FastDFS文件系统的存储节点就是用这种方式,写完一份数据之后立即返回结果,副本数据由同步线程写入其他同group的节点)。这种方式,牺牲了C来保证A,即无法保证数据是否更新成功,还有可能会由于网络故障等原因,导致数据不一致。 3)折衷:更新部分节点成功后便返回。

三、分片

相比于单实例,这里多了一个节点去分割数据。 由于所有数据只有一份,一致性得以保证;节点间不需要通信,分区容忍性也有。 然而,当任意一个节点挂掉,丢失了一部分的数据,系统可用性得不到保证。

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

那么,有哪些好处呢? 1)某个节点挂掉只会影响部分服务,即服务降级; 2)由于分片了数据,可以均衡负载; 3)数据量增大/减小后可以相应的扩容/缩容。

大多数的数据库服务都提供了分片的功能。如Redis的slots,Cassandra的patitions,MongoDB的shards等。 基于分片解决了数据量大的问题,可是我们还是希望我们的系统是高可用的,那么,如何牺牲一定的一致性去保证可用性呢?

四、集群

可以看到,上面这种方式综合了前两种方式。同上分析,采用不同的数据同步策略,系统CAP保证各有不同。不过,一般数据库系统都会提供可选的配置,我们根据不同的场景选择不同的特性。 其实,对于大多数的非金融类互联网公司,要求并非强一致性,而是可用性和最终一致性的保证。这也是NoSQL流行于互联网应用的一大原因,相比于强一致性系统的ACID原则,它更加倾向于BASE: -  Basically Available:基本可用性,即允许分区失败,除了问题仅服务降级; -  Soft-state:软状态,即允许异步; -  Eventual Consistency:最终一致性,允许数据最终一致性,而不是时刻一直。

五、总结 基本上,上面讨论的几种方式已经涵盖了大多数的分布式存储系统了。 其实对于大规模分布式系统来说,CAP是非常稳固的,可以扩展的地方也不多。 它很大程度上限制了大规模计算的能力,通过一些设计方式来绕过CAP管辖的区域或许是下一步大规模系统设计的关键。 可以看到,这些个方案总是需要通过牺牲一部分去换取另一部分,总没法达到100%的CAP。选择哪种方案,依据就是在特定场景下,究竟哪些特性是更加重要的了。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏架构师之路

创业公司快速搭建立体化监控之路(WOT2016)

本文内容:创业型公司如何快速搭建可扩展,可落地的立体化监控平台 一、需求缘起 创业型公司有系统监控么?来看两个case: case 1:CXO大群内贴了一张“用...

2867
来自专栏互联网杂技

什么是微服务

在介绍微服务时,首先得先理解什么是微服务,顾名思义,微服务得从两个方面去理解,什么是"微"、什么是"服务", 微 狭义来讲就是体积小、著名的"2 p...

731
来自专栏云计算认知升级

【腾讯云的1001种玩法】十分钟轻松搞定云架构 之四:替你分心的负载均衡

本文主要讲以下几个方面:负载均衡如何帮我们分心 、自建负载均衡和云端负载均衡的优劣之分 、腾讯云负载均衡的优势、腾讯云负载均衡的使用。

3689
来自专栏JAVA高级架构

从单机至亿级流量大型网站系统架构的演进过程

阶段一、单机构建网站 网站的初期,我们经常会在单机上跑我们所有的程序和软件。此时我们使用一个容器,如tomcat、jetty、jboos,然后直接使用JSP/s...

2805
来自专栏Java架构

阿里P9架构师讲解从单机至亿级流量大型网站系统架构的演进过程

1445
来自专栏服务端技术杂谈

进程内缓存使用技术方案

进程内缓存可以采用带锁的Map或者第三方库,或者自己实现进程内缓存管理,如ConcurrentHashMap,ThreadLocal,guava cache等。

1093
来自专栏架构师小秘圈

电子商务网站是这样诞生的

来自:cnblogs.com/xiaoMzjm 前言 我们以javaweb为例,来搭建一个简单的电商系统,看看这个系统可以如何一步步演变。 该系统具备的功能: ...

3498
来自专栏java思维导图

【经典必读】web网站架构演变过程,电商网站升级打怪

前言 我们以javaweb为例,来搭建一个简单的电商系统,看看这个系统可以如何一步步演变。 该系统具备的功能: 用户模块:用户注册和管理 商品模块:商品展示和管...

2504
来自专栏Linyb极客之路

分布式事务之ACID、BASE和CAP原理

ACID,是指在数据库管理系统(DBMS)中,事务(transaction)所具有的四个特性:原子性(Atomicity)、一致性(Consistency)...

905
来自专栏腾讯云数据库(TencentDB)

【腾讯云 MongoDB】 基于snapshot的从库读优化

我们发现腾讯云上一些腾讯云MongoDB实例在主库写压力比较大的情况下,这时从库上会出现很多慢查询,经过调查发现,从库在回放oplog的时候加了全局锁,阻塞了所...

4980

扫码关注云+社区