网络优化推广 网站开发建设,重庆seo优化公司,网站模板修改软件,做pc端网站服务正文 大约在五六年前#xff0c;第一次接触到了当时已经是hot topic的NoSql。不过那个时候学的用的都是mysql#xff0c;Nosql对于我而言还是新事物#xff0c;并没有真正使用#xff0c;只是不明觉厉。但是印象深刻的是这么一张图片#xff08;后来google到图片来自这里第一次接触到了当时已经是hot topic的NoSql。不过那个时候学的用的都是mysqlNosql对于我而言还是新事物并没有真正使用只是不明觉厉。但是印象深刻的是这么一张图片后来google到图片来自这里 这张图片是讲数据库包括传统的关系型数据库和NOSQL与CAP理论的关系。由于并NoSql并没有实践经验也没有去深入了解对于CAP理论更是一知半解。因此为什么某一款数据库被划分到哪一个阵营并不清楚。 工作之后对MongoDB使用得比较多有了一定的了解前段时间又看到了这张图于是想搞清楚MongoDB是不是真的属于CP阵营又是为什么怀疑这个问题的初衷是因为MongoDB的经典官方推荐部署架构中都会使用replica set而replica set通过冗余和自动failover提供高可用性Availability那么为什么上图中说MongoDB牺牲了Avalability呢而我在MongoDB的官方文档中搜索“CAP”并没有搜索到任何内容。于是我想自己搞清楚这个疑问给自己一个答案。 本文先阐明什么是CAP理论以及关于CAP理论的一些文章然后讨论MongoDB在一致性与可用性之间的折中与权衡。 CAP理论 对CAP理论我只知道这三个单词的意思其解释也是来自网上的一些文章并不一定准确。所以首先得追根溯源搞清楚这个理论的起源和准确的解释。我觉得最好的开始就是wikipedia从上面可以看到比较准确的介绍更为重要的是可以看到很多有用的链接比如CAP理论的出处发展演变过程。 CAP理论是说对于分布式数据存储最多只能同时满足一致性CConsistency、可用性A Availability、分区容错性PPartition Tolerance中的两者。 一致性是指对于每一次读操作要么都能够读到最新写入的数据要么错误。 可用性是指对于每一次请求都能够得到一个及时的、非错的响应但是不保证请求的结果是基于最新写入的数据。 分区容错性是指由于节点之间的网络问题即使一些消息对包或者延迟整个系统能继续提供服务提供一致性或者可用性。 一致性、可用性都是使用非常宽泛的术语在不同的语义环境下具体所指是不一样的比如在cap-twelve-years-later-how-the-rules-have-changed一文中Brewer就指出“CAP中的一致性与ACID中的一致性并不是同一个问题”因此后文中除非特别说明所提到的一致性、可用性都是指在CAP理论中的定义。只有明确了大家都是在同样的上下文环境讨论才有意义。 对于分布式系统网络分区network partition这种情况是难以避免的节点间的数据复制一定存在延迟如果需要保证一致性对所有读请求都能够读到最新写入的数据那么势必在一定时间内是不可用的不能读取即牺牲了可用性反之亦然。 按照维基百科上的描述CAP之间的相互关系大约起源于1998年Brewer在2000年的PODCSymposium on Principles of Distributed Computing上展示了CAP猜想[3]在2002年由另外两名科学家Seth Gilbert、Nancy Lynch证明了Brewer的猜想从而从猜想变成了定理[4]。 CAP理论起源 在Towards Robust Distributed Systems 中CAP理论的提出者Brewer指出在分布式系统中计算是相对容易的真正困难的是状态的维护。那么对于分布式存储或者说数据共享系统数据的一致性保证也是比较困难的。对于传统的关系型数据库优先考虑的是一致性而不是可用性因此提出了事务的ACID特性。而对于许多分布式存储系统则是更看重可用性而不是一致性一致性通过BASEBasically Available, Soft state, Eventual consistency来保证。下面这张图展示了ACID与BASE的区别 简而言之BASE通过最终一致性来尽量保证服务的可用性。注意图中最后一句话“But I think it‘s a spectrum”就是说ACID BASE只是一个度的问题并不是对立的两个极端。 2002年在Brewers conjecture and the feasibility of consistent, available, partition-tolerant web services中两位作者通过异步网络模型论证了CAP猜想从而将Brewer的猜想升级成了理论theorem。但实话说我也没有把文章读得很明白。 2009年的这篇文章brewers-cap-theorem作者给出了一个比较简单的证明 如上图所示N1N2两个节点存储同一份数据V当前的状态是V0。在节点N1上运行的是安全可靠的写算法A在节点N2运行的是同样可靠的读算法B即N1节点负责写操作N2节点负责读操作。N1节点写入的数据也会自动向N2同步同步的消息称之为M。如果N1N2之间出现分区那么就没法保证消息M在一定的时间内到达N2。 从事务的角度来看这各问题 α这个事务由操作α1 α2组成其中α1是写数据α2是读数据。如果是单点那么很容易保证α2能读到α1写入的数据。如果是分布式的情况的情况除非能控制 α2的发生时间否则无法保证 α2能读到 α1写入的数据但任何的控制比如阻塞数据集中化等要么破坏了分区容错性要么损失了可用性。 另外这边文章指出很多情况下 availability比consistency重要比如对于facebook google这样的网站短暂的不可用就会带来巨大的损失。 2010年的这篇文章brewers-cap-theorem-on-distributed-systems/用了三个例子来阐述CAP分别是example1单点的mysqlexample2两个mysql但不同的mysql存储不同的数据子集类似shardingexample3两个mysql对A的一个insert操作需要在B上执行成功才认为操作完成类似复制集。作者认为在example1和example2上 都能保证强一致性但不能保证可用性在example3这个例子由于分区partition的存在就需要在一致性与可用性之间权衡。 于我看来讨论CAP理论最好是在“分布式存储系统”这个大前提下可用性也不是说整体服务的可用性而是分布式系统中某个子节点的可用性。因此感觉上文的例子并不是很恰当。 CAP理论发展 到了2012年CAP理论的发明人 Brewer就CAP理论再次撰文《CAP Twelve Years Later: How the Rules Have Changed》这篇文章比较长但思路清晰高屋建瓴非常值得一读。网上也有对用的中文译文《CAP理论十二年回顾规则变了》翻译还不错。 文章中最主要的观点是CAP理论并不是说三者不需选择两者。首先虽然只要是分布式系统就可能存在分区但分区出现的概率是很小的否则就需要去优化网络或者硬件CAP在大多数时候允许完美的C和A只有在分区存在的时间段内才需要在C与A之间权衡。其次一致性和可用性都是一个度的问题不是0或者1的问题可用性可以在0%到100%之间连续变化一致性分为很多级别比如在casandra可以设置consistency level。因此当代CAP实践的目标应该是针对具体的应用在合理范围内最大化数据一致性和可用性的效力。 文章中还指出分区是一个相对的概念当超过了预定的通信时限即系统如果不能在时限内达成数据一致性就意味着发生了分区的情况必须就当前操作在C和A之间做出选择。 从收入目标以及合约规定来讲系统可用性是首要目标因而我们常规会使用缓存或者事后校核更新日志来优化系统的可用性。因此当设计师选择可用性的时候因为需要在分区结束后恢复被破坏的不变性约。 　　实践中大部分团体认为位于单一地点的数据中心内部是没有分区的因此在单一数据中心之内可以选择CACAP理论出现之前系统都默认这样的设计思路包括传统数据库在内。 　　分区期间独立且能自我保证一致性的节点子集合可以继续执行操作只是无法保证全局范围的不变性约束不受破坏。数据分片sharding就是这样的例子设计师预先将数据划分到不同的分区节点分区期间单个数据分片多半可以继续操作。相反如果被分区的是内在关系密切的状态或者有某些全局性的不变性约束非保持不可那么最好的情况是只有分区一侧可以进行操作最坏情况是操作完全不能进行。 上面摘录中下选线部分跟MongoDB的sharding情况就很相似MongoDB的sharded cluste模式下shard之间在正常情况下是无需相互通信的。 在13年的文章中《better-explaining-cap-theorem》作者指出“it is really just A vs C”因为 1可用性一般是在不同的机器之间通过数据的复制来实现 2一致性需要在允许读操作之间同时更新几个节点 3temporary partion即几点之间的通信延迟是可能发生了此时就需要在A 和 C之间权衡。但只有在发生分区的时候才需要考虑权衡。 在分布式系统中网络分区一定会发生因此“it is really just A vs C” MongoDB与CAP         在《通过一步步创建sharded cluster来认识MongoDB》一文中对MongoDB的特性做了一些介绍包括高性能、高可用、可扩展水平伸缩其中MongoDB的高可用性依赖于replica set的复制与自动failover。对MongoDB数据库的使用有三种模式standalonereplica set shareded cluster在前文中详细介绍了shared cluster的搭建过程。 standalone就是单个mongod应用程序直接连接到这个Mongod在这种情况下无分区容错性可言也一定是强一致性的。对于sharded cluster每一个shard也都推荐是一个replica set。MongoDB中的shards维护的是独立的数据子集因此shards之间出现了分区影响不大在chunk迁移的过程可能还是有影响因此也主要考虑的是shard内部replica set的分区影响。所以本文中讨论MongoDB的一致性、可用性问题针对的也是MongoDB的replica set。 对于replica set只有一个primary节点接受写请求和读请求其他的secondary节点接受读请求。这是一个单写、多读的情况比多读、多写的情况还是简化了许多。后文为了讨论也是假设replica set由三个基点组成一个primary两个secondary且所有节点都持久化数据data-bearing MongoDB关于一致性、可用性的权衡取决于三者write-concern、read-concern、read-preference。下面主要是MongoDB3.2版本的情况因为read-concern是在MongoDB3.2版本中才引入的。 write-concern write concern表示对于写操作MongoDB在什么情况下给予客户端响应。包括下面三个字段 { w: value, j: boolean, wtimeout: number } w: 表示当写请求在value个MongoDB实例处理之后才向客户端返回。取值范围 1默认值表示数据写入到standalone的MongoDB或者replica set的primary之后返回 0不用写入就直接向客户端返回性能高但可能丢数据。不过可以配合jTrue来增加数据的可持久性durability 1: 只有在replica set环境下才有用如果value大于的replica set中节点的数目那么可能导致阻塞 ‘majority’ 当数据写入到replica set的大多数节点之后向客户端返回对于这种情况一般是配合read-concern使用 After the write operation returns with a w: majority acknowledgement to the client, the client can read the result of that write with a majority readConcern j表示当写请求在写入journal之后才向客户端返回默认为False。两点注意 如果在对于未开启journaling的MongoDB实例使用j:True会报错 在MongoDB3.2及之后对于w1, 需要所有实例都写到journal之后才返回 wtimeout表示写入的超时时间即在指定的时间number如果还不能向客户端返回w大于1的情况那么返回错误 默认为0相当于没有设置该选项 在MongoDB3.4中加入了writeConcernMajorityJournalDefault.这么一个选项使得wj在不同的组合下情况下不同: read-reference: 在前文已经讲解过一个replica set由一个primary和多个secondary组成。primary接受写操作因此数据一定是最新的secondary通过oplog来同步写操作因此数据有一定的延迟。对于时效性不是很敏感的查询业务可以从secondary节点查询以减轻集群的压力。 MongoDB指出在不同的情况下选用不同的read-reference非常灵活。MongoDB driver支持一下几种read-reference primary默认模式一切读操作都路由到replica set的primary节点 primaryPreferred正常情况下都是路由到primary节点只有当primary节点不可用failover的时候才路由到secondary节点。 secondary一切读操作都路由到replica set的secondary节点 secondaryPreferred正常情况下都是路由到secondary节点只有当secondary节点不可用的时候才路由到primary节点。 nearest从延时最小的节点读取数据不管是primary还是secondary。对于分布式应用且MongoDB是多数据中心部署nearest能保证最好的data locality。 如果使用secondary或者secondaryPreferred那么需要意识到 (1) 因为延时读取到的数据可能不是最新的而且不同的secondary返回的数据还可能不一样 (2) 对于默认开启了balancer的sharded collection由于还未结束或者异常终止的chunk迁移secondary返回的可能是有缺失或者多余的数据 (3) 在有多个secondary节点的情况下选择哪一个secondary节点呢简单来说是“closest”即平均延时最小的节点具体参加Server Selection Algorithm  read-concern: read concern是在MongoDB3.2中才加入的新特性表示对于replica set包括sharded cluster中使用复制集的shard返回什么样的数据。不同的存储引擎对read-concern的支持情况也是不一样的 read concern有以下三个level local默认值返回当前节点的最新数据当前节点取决于read reference。 majority返回的是已经被确认写入到多数节点的最新数据。该选项的使用需要以下条件 WiredTiger存储引擎且使用election protocol version 1启动MongoDB实例的时候指定 --enableMajorityReadConcern选项。 linearizable3.4版本中引入这里略过了感兴趣的读者参考文档。 在文章中有这么一句话 Regardless of the read concern level, the most recent data on a node may not reflect the most recent version of the data in the system. 就是说即便使用了read concernmajority 返回的也不一定是最新的数据这个和NWR理论并不是一回事。究其根本原因在于最终返回的数值只来源于一个MongoDB节点该节点的选择取决于read reference。 在这篇文章中对readconcern的引入的意义以及实现有详细介绍在这里只引用核心部分 readConcern 的初衷在于解决『脏读』的问题比如用户从 MongoDB 的 primary 上读取了某一条数据但这条数据并没有同步到大多数节点然后 primary 就故障了重新恢复后 这个primary 节点会将未同步到大多数节点的数据回滚掉导致用户读到了『脏数据』。 当指定 readConcern 级别为 majority 时能保证用户读到的数据『已经写入到大多数节点』而这样的数据肯定不会发生回滚避免了脏读的问题。 一致性 or 可用性 回顾一下CAP理论中对一致性 可用性的问题 　　一致性是指对于每一次读操作要么都能够读到最新写入的数据要么错误。 　　可用性是指对于每一次请求都能够得到一个及时的、非错的响应但是不保证请求的结果是基于最新写入的数据。 　　前面也提到本文对一致性 可用性的讨论是基于replica set的是否是shared cluster并不影响。另外讨论是基于单个客户端的情况如果是多个客户端似乎是隔离性的问题不属于CAP理论范畴。基于对write concern、read concern、read reference的理解我们可以得出以下结论。 默认情况w1、readconcernlocal如果read preference为primary那么是可以读到最新的数据强一致性但如果此时primary故障那么这个时候会返回错误可用性得不到保证默认情况w1、readconcernlocal如果read preference为secondarysecondaryPreferred、primaryPreferred虽然可能读到过时的数据但能够立刻得到数据可用性比较好writeconernmajority保证写入的数据不会被回滚; readconcernmajority保证读到的一定是不会被回滚的数据若w1、readconcernmajority即使是从primary读取也不能保证一定返回最新的数据因此是弱一致性若w: majority、readcocernmajority如果是从primary读取那么一定能读到最新的数据且这个数据一定不会被回滚但此时写可用性就差一些如果是从secondary读取不能保证读到最新的数据弱一致性。 回过来来看MongoDB所说的高可用性是更普世意义上的可用性通过数据的复制和自动failover即使发生物理故障整个集群还是能够在短时间内回复继续工作何况恢复也是自动的。在这个意义上确实是高可用的。