Brewer’s CAP Theorem(2)

最近一直在学习ACID,CAP,BAse等NoSQL思想。下面这批CAP理论文章很不错,分享给大家。

原文:http://pt.alibaba-inc.com/wp/dev_related_728/brewers-cap-theorem.html

 

定理的重要性

CAP定理在应用系统规模化时最有效。在低压力的情况下,小的延迟(以便数据库达到一致的状态)还不足以对总体的性能或用户体验造成影响。你所承担的负载分布,可能都是出于系统管理的原因。?

但随着活动的增加,吞吐量的上限(pinch-points)将会限制增长并产生错误。必须等待网页的返回是一种情况,另一种情况则是在你输入信用卡信息后遇到 “HTTP 500 java.lang.schrodinger.purchasingerror”,你就想知道你是否付了钱但无法得到东西,还是没付钱,或者这只是交易中一个不重要的错误。谁知道呢?你不太可能继续下去,很有可能到别的地方购物,或更有可能给银行打电话。

不管是那种情况对业务都没有好处。Amazon声称每0.1秒的响应延迟都会导致1%的销售降低。Google他们注意到0.5秒的延迟会使流量减少15%。

之前曾就scalability写过一些东西,不想在这里重复,只想指出2点:第一点是,解决scale问题看起来是一个架构方面的问题,但最初的讨论却不是,而是业务决策。我已经很厌倦听到技术人员说,因为当前的流量,这样或那样的方案不能用。并不是说技术人员错了,通常他们讲的非常正确,是由于从一开始所限定的scale 隐含地做了revenue决策-这一问题应该在业务分析时明确地决定下来。

第二点是,一旦你开始讨论如何scale业务系统,大致会落到2种意识形态阵营中:数据库派和非数据库派。

对于数据库派来说,毫无疑问,钟爱数据库技术,并倾向于谈论optimistic lockingsharding这类的东西来解决scale问题,并将数据库作为系统的核心。

非数据库派会倾向于尽可能多的在数据库环境(避免关系世界)之外管理数据以解决scale问题。

我认为,可以公平地说,前一派人对CAP定理的热情肯定不如后一派(尽管他们在讨论定理)。这是因为,如果你必须在consistency,availability,partition tolerance三者中放弃一个,大多数会选择放弃consistency,而consistency是数据库存在的理由。(选择的)逻辑,无疑,是availability和partition tolerance能够使你赖以赚钱的系统生存下去,而不一致性感觉好像是你可以用好的设计来解决的问题。

和IT中的其他事情一样,这不是非黑即白的问题。Eric Brewer在其PODC演讲的第13页slide中,当比较ACID和其非正式的对应物的BASE时,甚至说“我认为这是一个系列(spectrum)”(注:这里光谱有一个系列的含义,是指ACID和BASE是不对立的)。如果你对这个主题感兴趣(有些超出我在这里讨论的范围了),你可以从一篇叫做,“Design and Evaluation of a Continuous Consistency Model for Replicated Servicepage_white_acrobat ”的论文开始,该文由Haifeng Yu和Amin Vahdat 编写。大家不可以将CAP解读为暗示数据库的消亡。

尽管这样,双方都认同scale的解决之道是分布式的并行计算,而不是曾经认为的超级计算机。90年代中期进行的Network of Workstations项目受到了Eric Brewer的影响,并最终导致了CAP定理的诞生,因为他在一个关于Inktomi and the Internet Bubblepage_white_acrobat 的介绍中说到,答案总是并行处理:

如果不通过并行的方式,你就没有机会,在合适的时间内解决问题。和其他许多事情一样。如果是个很大的项目,会需要很多人来完成它。因此,如果想建造一个桥梁,就需要很多建筑工人。这就是并行处理。因此问题会演变为“如何将并行处理和internet结合在一起”

图片证明

这里有一个简单的图片证明,因为我发现用图片会比较好理解。多数情况下我使用和Gilber 和Lynch相同的术语,以便和他们的论文联系起来。

intro

上图显示了网络中的两个节点N1,N2。他们共享同一数据V(库存中《战争与和平》的数量),其值为V0。N1上有一个算法A,我们可以认为A是安全,无bug,可预测和可靠的。N2上有一个类似的算法B。在这个例子中,A写入V的新值而B读取V的值。

scenario-1

正常情况下(sunny-day scenario),过程如下:(1)A写入新的V值,我们称作v1。(2)N1发送信息给N2,更新V的值。(3)现在B读取的V值将会是V1。

scenario-2

如果网络断开(partions)(意味着从N1无法发送信息到N2)那么在第3步的时候,N2就会包含一个步一致的V值。

希望看上去很明白。即使将其scale到几百个事务(transaction)中,这也会成为一个大问题。如果M是一个异步消息,那么N1无法知道N2是否收到了消息。即使M是保证能发送的(guaranteed delivery),N1也无法知道是否消息由于partition事件的发生而延迟,或N2上的其他故障而延迟。即使将M作为同步(synchronous)信息也不能解决问题,因为那将会使得N1上A的写操作和N1到N2的更新事件成为一个原子操作(atomic operation),而这将导致同样的等待问题,该问题我们已经讨论过(或更糟)。Gilbert 和Lynch已经证明,使用其他的变种方式,即使是部分同步模型(每个节点上使用安排好的时钟)也无法保证原子性(atomicity)。

因此,CAP告诉我们,如果想让A和B是高可用(highly available)的(例如,以最小的延迟(latency)提供服务)并且想让所有的N1到Nn(n的值可以是数百甚至是上千)的节点能够冗余网络的partitions(丢失信息,无法传递信息,硬件无法提供服务,处理失败),那么有时我们就得面临这样的情况:某些节点认为V的值是V0(一本《战争与和平》的库存)而其他节点会认为V的值是V1(《战争与和平》的库存为0)

我们都希望所有的事情是结构化的,一致的且和谐的,就像70年代早期的prog rock乐队,但我们面临的是一些punk风格的混乱。事实上,尽管有可能会吓到我们的祖母,但一旦你了解了它就还OK,因为2者可以非常愉快地在一起工作。

让我们从事务(transactional)的角度快速分析一下。

tx-view

如果我们有个事务(例如:一组围绕着persistent数据项V的工作单元)a,a1是写操作,a2是读操作。在一个local的系统中,可以利用数据库中的简单锁(simple locking)的机制方便地处理,隔离(isolating)a2中的读操作,直到a1的写成功完成。然而,在分布式的模型中,需要考虑到N1和N2节点,中间的消息同步也要完成才行。除非我们可以控制a2何时发生,我们永远无法保证a2可以读到a1写入的数据。所有加入控制的方法(阻塞,隔离,中央化的管理,等等)会要么影响partition tolerance,要么影响a1(A)和a2(B)的可用性。

CAP选择

当处理CAP的问题时,你会有几个选择。最明显的是:

  1. 放弃Partition Tolerance如果你想避免partition问题发生,你就必须要阻止其发生。一种做法是将所有的东西(与事务相关的)都放到一台机器上。或者放在像rack这类的atomically-failling单元上。无法100%地保证,因为还是有可能部分失败,但你不太可能碰到由partition问题带来的负面效果。当然,这个选择会严重影响scale限制。
  2. 放弃Availability相对于放弃partition tolerance来说,其反面就是放弃availability。一旦遇到partition 事件,受影响的服务需要等待数据一致,因此在等待期间就无法对外提供服务。在多个节点上控制这一点会相当复杂,而且恢复的节点需要处理逻辑,以便平滑地返回服务状态。
  3. 放弃Consistency或者如同Werner Vogels所提倡的,接受事情会变得“最终一致(Eventually Consistent)”(2008年12月更新)。Vogels的文章值得一读。他比我在这里讨论了更多的操作方面的细节。许多的不一致性并不比你想的需要更多的工作(意味着持续的consistency或许并不是我们所需要的)。在购书的例子中,如果一本库存的书,接到了2个订单,第二个就会成为备份订单。只要告知客户这种情况(请记住这是一种罕见的情况),也许每个人都会高兴的。
  4. 引入(jump)BASE
    有一种架构的方法(approach)称作BASE(Basically Available, Soft-state,Eventually consistent)支持最终一致概念的接受。BASE(注:化学中的含义是碱),如其名字所示,是ACID(注:化学中的含义是酸)的反面,但如果认为任何架构应该完全基于一种(BASE)或完全基于另一种(ACID),就大错特错了。这一点是需要谨记重点,尤其是这个行业的“一边倒(oooh shiny,注:这个完全意译了)”的习惯性的采用策略。这里,我要遵从Brewer教授自己的观点,他就本文通过email表达了自己的观点(comment):

     

    如您所指出的,术语BASE第一次出现是在1997年的SOSP文章中。那一年,我和我的学生在他们的办公室中,一起造了这个词。我承认这有些人为的因素,但ACID也是一样的--远超人们所能意识到的,所以我们人为还行。Jim Gray和我讨论了这些缩写,他欣然认可ACID也有些扭曲(stretch)– A和D(的概念)有相当多的重复部分,C至多也是含糊不清的。但这对术语暗示了一系列的理念(idea of spectrum),这是PODC演讲中的一个重要观点,你正确地指出了这一点。

    EBay的Dan Pritchett有一篇关于BASE的很棒的介绍 (presentation)。

  5. 围绕其进行设计
    Guy Pardon, atomikos的CTO写了一篇他称作“CAP解决之道(证实Brewer的错误)”的文章,提出了一种架构方法,可以达到Consistency, Availability和Partition-tolerance,当然附带了一些说明(显然你不可能在同一时刻满足全部的3个要求)。值得一读,Guy雄辩地表达了(在该领域)相反的观点。

总结

在Consistency, Availability和Partition-tolerance中,你只能保证2点,这是确实的,并且已经被这个星球上最成功的网站证实了。如果对网站是有效的,我看不出在企业环境中,在日常的工作中,不考虑同样的折衷设计的理由。如果业务方面明确表明不需要上规模(scale)那好,有简单的解决方案,但这是值得讨论的。在任何情况下,这些讨论都是针对特定操作的适合的设计,而不是庐山(注:shebang取意译)全貌。正如Brewer在其邮件中所说的:“唯一的我可以加入的是同一服务的不同部分可以选择这一系列(spectrum)中的不同的点”有时,无论scale的代价如何,你绝对需要一致性,因为缺少它的风险太大了。

这些天,我说得有些过,说Amazon和EBay没有scalability问题,我认为他们的确有这类问题,但他们现在有办法解决该问题。这也是为何他们可以自由讨论这些问题的原因。不论他们现在是何规模(结合他们早就公布的数字)只会越来越大。一旦规模上来,你的问题就会转到(shift)诸如操作维护,监控,发布软件的更新等等 - 当然(这些问题)都很难解决,但值得,尤其当你因此获得现金流(revenue stream)。

参考

  1. HP接纳CAP定理,白皮书的标题为“分布式数据没有免费的午餐 
  2. Sussex大学计算机科学讲义,关于分布式事务网络partitions
  3. Jens Alfke的关于数据库,scaling和Twitter的好文
  4. Pat Helland的关于分布式事务和SOA的Microsoft论文,叫做数据在外和数据在外 ,他随后将其和CAP理论关联了起来
  5. 另一套计算机科学方面课程slides ,这一次是来自Virginia的George Mason大学,是关于分布式软件系统和CAP定理以及ACID和BASE两大阵营的对比。
  6. 在英国1976年6月4号被认为是Punk摇滚诞生的日子。感谢Charlie Dellacona指出在美国Ramones普遍认为是从1974年就开启了这一运动,尽管他们正式的punk唱片是在同时发行的。
  7. 感谢Hiroshi Yuki,提供了本文的日文版译本
  8. 感谢Daniel Cohen,提供了分为 部分的希伯来版译本
  9. 感谢Wang Qi,提供了本文的中文版译本

Java企业场景下的实战入门课(Spring Boot+Redis

04-20
<p> 企业场景下的Java实战课程!  </p> <p> 【超实用课程内容】 本课程主要是从最基础的技术要点一步一个脚印的介绍Spring Boot2.0相关的核心技术栈和缓存中间件Redis常见且典型的数据结构、相关的核心技术栈及典型的应用场景的实战。并附带业务场景实战用户注册和点赞系统中点赞功能模块的设计与实现为各位小伙伴提供企业级项目开发中常见且典型的Java核心技术,可以说是拒绝纸上谈兵、注重实战并学以致用!  </p> <p> <br> </p> <p> 套餐中一共包含2门实战入门课程(共82讲)  </p> <p> 课程1:《Java实战之Spring Boot入门到精通》  </p> <p> 课程2:《Java实战之Redis入门到精通》  </p> <p> <br> </p> <p> 【基础要求】  </p> <p> 1、基本要求:具备一定的JavaSE以及Java Web项目的开发基础、了解spring boot更佳  </p> <p> 2、工具要求:会使用Intellij IDEA、Navicat以及Postman  </p> <p> <br> </p> <p> 【你能收获到什么?】  </p> <p> 1、帮助学员了解并掌握springboot和缓存中间件Redis的方方面面、包括其典型及常用的数据结构及其在实际项目开发中典型的应用场景!  </p> <p> 2、掌握如何基于Spring Boot搭建企业级项目,整合加入中间件Redis相关的依赖配置,并以此为扩展,为后续学习其他中间件做铺垫;可以提升学员Java中间件的实战能力。  </p> <p> 3、帮助学员了解并掌握缓存中间件Redis在实际应用中有哪些常见、典型的应用场景,如对象信息存储、列表存储、队列特性分发消息、试题库随机获取、排行榜等等,这对于学员在平时项目开发、跳槽面试等情况下将有很大的帮助  </p> <p> 4、本课程介绍的基于Redis相关数据结构的特性独立设计并实战项目中典型功能模块,如会员到期自动提醒、点赞功能模块等内容,将有助于学员将所学的技术栈真正应用到实际中、提升自身的数据库设计能力、业务理解能力、代码实战能力以及性能优化方面的能力  </p> <p> <br> </p> <p> 【课程如何观看?】  </p> <p> 1、登录CSDN学院 APP 在我的课程中进行学习;  </p> <p> 2、移动端:CSDN 学院APP(注意不是CSDN APP哦) 本课程为录播课,课程2年有效观看时长 【资料开放】 课件、课程案例代码完全开放给你,你可以根据所学知识,自行修改、优化 下载方式:电脑登录课程观看页面,点击右下方课程资料、代码、课件等打包下载 </p> <p> <img src="https://img-bss.csdn.net/202004200821078434.png" alt=""> </p>
©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值