[数据库理论]分布式CAP原理

高可用的数据

对于许多应用而言,数据是宝贵的,必须的资产。数据是整个应用的历史,是记录也有可能是配置信息,如果丢失了数据,那么对于某些应用来说结果可能就是毁灭性的,整个应用都有可能因此无法运行。
不同于高可用的应用或服务的设计方式,由于数据存储服务器上存储的数据不同,当某台服务器宕机之后,数据访问请求不能任意的切换到集群中其它数据服务器上。

CAP

CAP理论是分布式系统中对数据的管理而形成一套理论知识,CAP是设计分布式系统所必须考虑的架构问题。对于CAP本身可以解释如下:

  • Consistency(一致性): 数据一致更新,所有数据变动都是同步的
  • Availability(可用性): 好的响应性能
  • Partition tolerance(分区耐受性): 可靠性

上面的解释可能显得太过抽象,举例来说在高可用的网站架构中,对于数据基础提出了以下的要求:

  • 分区耐受性
    保证数据可持久存储,在各种情况下都不会出现数据丢失的问题。为了实现数据的持久性,不但需要在写入的时候保证数据能够持久存储,还需要能够将数据备份一个或多个副本,存放在不同的物理设备上,防止某个存储设备发生故障时,数据不会丢失。
  • 数据一致性
    在数据有多份副本的情况下,如果网络、服务器、软件出现了故障,会导致部分副本写入失败。这就造成了多个副本之间的数据不一致,数据内容冲突。
  • 数据可用性
    多个副本分别存储于不同的物理设备的情况下,如果某个设备损坏,就需要从另一个数据存储设备上访问数据。如果这个过程不能很快完成,或者在完成的过程中需要停止终端用户访问数据,那么在切换存储设备的这段时间内,数据就是不可访问的。

CAP原理认为,一个提供数据服务的存储系统无法同时完美的满足一致性(Consistency)、数据可用性(Availability)、分区耐受性(Partition Tolerance)这三个条件。对于三者的关系见图1.


图1 CAP原理关系图

在实际的大型网络应用中,数据的规模会快速扩张,因此数据架构的伸缩性(分区耐受性)必不可少。当规模变大之后,机器的数量也会增大,这时网络和服务器故障会更频繁出现,想要保证应用可用,就必须保证分布式处理系统的高可用性。所以在大型网站中,通常会选择强化分布式存储系统的可用性(A)和伸缩性(P),在某种程度上放弃一致性(C)。一般来说,数据不一致的情况通常出现在高并发写操作或者集群状态不稳(故障恢复,集群扩容...)的情况下,应用系统需要对分布式数据处理系统的数据不一致性有一定的了解并进行某种意义上的补偿工作,以避免应用出现数据不正确。

CAP原理对于可伸缩的分布式系统设计具有重要的意义,在系统设计开发过程中,不恰当的迎合各种需求,企图打造一个完美的产品,可能会使设计进入两难之地,难以为继。
具体来说,数据一致性又可分为以下几点:

  • 数据强一致
    各个副本中的数据总是强一致的。这种设计正确性很高,但是会在一定程度上损耗性能。
  • 数据用户一致
    应用访问数据时通过一定的纠错和校验机制,把多个数据可能不一致的副本的数据综合计算返回一个一致且确定的数据给用户。大型互联网架构一般采用这种设计,性能较好,并且数据不会出现错误。
  • 数据最终一致
    物理存储的数据不一致,用户访问得到的数据也可能不一致,但经过一段时间的自我修正(通常很短时间),数据会达到最终一致。该设计性能最高,但可能有数据错误。

因为很难去同时满足CAP,大型网站通常会综合成本、技术、业务场景等条件,结合应用服务和其它的数据监控与纠错功能,使存储系统达到用户一致,保证用户最终访问数据的正确性。

引用

本文是对class文件的学习笔记,笔记的内容并非是原创,而是大量参考其它资料。在写作本文的过程中引用了以下资料,为为在此深深谢过以下资料的作者。

  1. 《大型网站技术架构·核心原理与案例分析》 李智慧 2013 电子工业出版社

关于

原文链接        https://weiwei02.github.io/2017/08/03/database/theory/CAP%E5%8E%9F%E7%90%86/
我的[github](https://github.com/weiwei02/): https://github.com/weiwei02/  
我相信技术能够改变世界。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 200,302评论 5 470
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,232评论 2 377
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 147,337评论 0 332
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,977评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,920评论 5 360
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,194评论 1 277
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,638评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,319评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,455评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,379评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,426评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,106评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,696评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,786评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,996评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,467评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,043评论 2 341

推荐阅读更多精彩内容

  • 分布式系统面临的第一个问题就是数据分布,即将数据均匀地分布到多个存储节点。另外,为了保证可靠性和可用性,需要将数据...
    olostin阅读 4,537评论 2 26
  • 转自http://witchiman.github.io/2017/05/05/distributed-syste...
    witchiman阅读 4,611评论 0 12
  • 本文由厦门大学计算机系教师林子雨翻译,翻译质量很高,本人只对极少数翻译得不太恰当的地方进行了修改。 【摘要】:Sp...
    Jeffbond阅读 3,913评论 1 42
  • 文/傲娇哇 1. 这不是清晨了,橘黄色的夕阳悄悄的藏了起来,时间在残存的余晖里令人回味。许意不慌不忙的和时光约了会...
    傲娇哇阅读 858评论 20 29
  • 飞 友人各自纷飞 离 此刻悲伤别离 散 恐怕难再相聚 开 车子载我向远方开去 我多么想挽留 延续这段情谊 然而无能...
    九八卢聪阅读 176评论 0 0