精华内容
下载资源
问答
  • 2019-08-24 16:44:05

    今天对分布式相关的一些概念与理论进行学习。

    1.集群与分布式

    集群:相同的应用部署在多台服务器。

    分布式:不同的应用部署在多台服务器。

    1.数据一致性

    在分布式环境中,为了提高系统整体性能,数据以多副本冗余机制存储,副本之间通过数据复制进行同步。

    数据副本与数据复制必然引入新的问题:如何处理副本数据的一致性?

    总的来说,无法找到一种能够满足所有分布式环境的一致性解决方案,很多时候要在系统性能与数据一致性之间权衡。

    由此,分布式一致性常见以下三种一致性:

    1.1.强一致性

    强一致性:数据写以后,任意时刻,所有数据副本中的数据都是一致的。

    强一致性,也可以称为:原子一致性、线性一致性。

    强一致性,是非分布式环境中主要被采用的一致性原则。

    在非分布式环境中,数据可以集中存储,例如整个系统就一个数据库,这种情况下容易保证数据的强一致性。

    在分布式环境中,数据存在多个副本,分布在不同的服务器上,数据副本之间的同步会经过网络通讯,这种情况下,很难保证强一致性。

    1.2.顺序一致性

    顺序一致性:任何一次读都能读取到数据的最近一次写的数据,系统的所有进程的顺序一致,而且是合理的。

    顺序一致性,其实本人接触也不多,而且实际中暂时未涉及,这里就不再赘述。

    1.2.弱一致性

    弱一致性:数据写以后,不保证所有的数据副本何时能够达到一致,但是会尽可能的保证到某个时刻达到一致。

    1.3.最终一致性

    最终一致性:数据写以后,经过一段时间,所有数据副本中的数据最终是一致的。

    一段时间的长短是由业务场景决定的。

    最终一致性是弱一致性的特例,是分布式环境中广泛被采用的一致性原则。

    2.CAP定理

    2.1.概念

    CAP:一个分布式系统不可能同时满足一致性(Consistentcy)、可用性(Availability)和分区容错性(Partition tolerance),最多只能满足其中的两项。

    下面对C、A、P进行描述:

    • Consistency(一致性):所有数据副本的数据都是一致的。
    • Availability(可用性):所有请求都能获取正确的响应。
    • Partition Tolerance(分区容错性):即使发生了网络分区,服务也能对外提供满足一致性和可用性的服务。

    网络分区:分布式系统由网络连通的多个节点构成,有时由于一些特殊原因(网络波动、异常)导致部分节点之间出现网络不连通的情况。这种情况下,就会形成多个孤立的子网络或孤立节点,这些子网络和孤立节点称之为网络分区。

    其实在分布式系统中,首先需要保证的就是分区容错性,否则分布式的意义就不存在了。

    所以,一般情况下,我们需要权衡的是一致性和可用性之间的平衡。

    2.2.举例验证

    下面以外卖下单为例,通过下图进行简单验证:

    正常情况下

    1. 用户外卖下单,数据库A插入外卖记录。
    2. 数据库A的外卖记录通过网络同步给数据库B,数据库B中存有外卖记录。
    3. 用户查看评论情况,评论服务获取数据库B的数据,显示:外卖评论详情。

    网络分区情况:第二步数据库A的外卖记录通过网络同步给数据库B时失败。

    此时,是否能够同时保证Consistency和Availability呢?答案是否定的。

    先保证一致性的情况

    1. 用户外卖下单,数据库A插入外卖记录。
    2. 数据库A的外卖记录通过网络同步给数据库B时失败。
    3. 因为要保证一致性,所以需要用户一直等待,直至网络恢复正常,数据库A将最新数据同步给数据库B。
    4. 这种情况下,相当于牺牲了可用性

    先保证可用性的情况

    1. 用户外卖下单,数据库A插入外卖记录。
    2. 数据库A的外卖记录通过网络同步给数据库B时失败。
    3. 因为要保证可用性,所以直接查询数据库B的旧数据,返回给用户:无此外卖订单。
    4. 这种情况下,相当于牺牲了一致性

    通过上述简单举例,验证了在分布式环境下,保证分区可用性的前提下,无法同时保证一致性和可用性。

    同时,也可以看出上面两种处理方式都不太理想,那么更加理想的处理方式是什么呢?

    3.BASE理论

    3.1.概念

    BASE:基本可用(Basic Availability)、软状态(Soft State)和最终一致性(Eventually Consistency)。

    BASE理论是在CAP定理上,依据行业实践经验,逐渐演化出来的一种分布式方案。

    下面对BA、S、E进行描述:

    • 基本可用:分布式系统故障时,允许损失部分可用性,提供基本可用的服务。
      • 允许在响应时间上的可用性损失:正常情况下,外卖下单需要0.5s;异常情况下,外卖下单需要3s。
      • 允许在功能上的可用性损失:正常情况下,订单、评价服务都正常;异常情况下,只保证订单服务正常。
    • 软状态:分布式系统中,允许存在的一种中间状态,也叫弱状态或柔性状态。
      • 举例:在下单支付时,让页面显示支付中,直到支付数据同步完成。
    • 最终一致性:在出现软状态的情况下,经过一段时间后,各项数据最终到底一致。
      • 举例:在支付中这个软状态时,数据并未一致,软状态结束后,最终支付数据达到一致。

    3.2举例说明

    还是以章节2.2的外卖下单示例图为例,对BASE理论进行说明:

    采取软状态和最终一致性的示例

    1. 用户外卖下单,数据库A插入外卖记录。
    2. 数据库A的外卖记录通过网络同步给数据库B时失败。
    3. 此时采取最终一致性方案,并设置软状态下单中。
    4. 前端页面展示给用户下单中,然后直到网络恢复正常,数据库A将最新数据同步给数据库B,数据最终达到一致
    5. 用户查看评论情况,评论服务获取数据库B的数据,显示:外卖评论详情。

    采取基本可用的实例

    1. 用户外卖下单,数据库A插入外卖记录。
    2. 数据库A的外卖记录通过网络同步给数据库B时失败。
    3. 此时采取基本可用方案,有两种方案。
    4. 方案一:损失响应时间。用户查看评论情况时,由原来的0.5秒增长到10s,其实后端在进行数据同步。
    5. 方案二:损失功能。评论服务不是关键服务,可以直接降级,展示给用户一个降级页面。

    4.分布式事务

    在传统数据库中,事务是一项非常重要的特性,其理论基于ACID

    在分布式环境下,由于数据副本的存在,原有事务机制难以生效,此时大多会采取基于BASE理论的分布式事务。

    下面简单介绍几类分布式事务算法,更加深入的知识请自行了解。

    4.1.二阶段提交算法

    二阶段提交,2-Phase Commit,简称2PC。

    2PC算法有2个参与者:

    • 事务参与者,即分布式事务中的多个数据节点。
    • 事务协调者,整体组织和协调参与者,以保证事务最终提交或者回滚的角色。

    2PC算法如下:

    第一阶段:准备提交

    1. 阻塞协调者和所有参与者。
    2. 协调者询问所有参与者准备提交是否完成
    3. 参与者开始事务提交前的准备工作。
    4. 如果参与者准备工作完成,则回复协调者准备完成,否则回复准备失败

    第二阶段:正式提交

    1. 若任意参与者回复准备失败
      • 则协调者向所有参与者发布命令回滚
      • 所有参与者回滚事务,释放资源,并回复回滚完成
      • 协调者收到全部回滚完成之后回滚事务。
    2. 若全部参与者都回复准备完成
      • 则协调者向所有参与者发布命令开始提交
      • 所有参与者提交事务,释放资源,并回复提交完成
      • 协调者收到全部提交完成之后提交事务。

    2PC是一种老式的分布式事务算法,主要问题在于:

    • 从第一阶段开始阻塞所有参与者,极大影响性能。
    • 在第二阶段,如果协调者挂掉,则参与者进入不知所措状态。
    • 面对网络超时,难以适从。

    4.2.三阶段提交算法

    二阶段提交,3-Phase Commit,简称3PC。3PC算法如下:

    第一阶段:可否提交

    1. 协调者询问所有参与者是否可以准备提交
    2. 参与者开始确认自身资源是否可以准备提交。
    3. 如果参与者可以准备提交,则回复协调者可以准备,否则回复无法准备

    第二阶段:准备提交

    1. 若任意参与者回复无法准备
      • 则协调者向所有参与者发布命令终止
      • 所有参与者终止操作。
    2. 若全部参与者都回复可以准备
      • 与2PC第一阶段类似,而且更加优化,更加复杂。

    第三阶段:正式提交

    • 与2PC第二阶段类似,而且更加优化,更加复杂。

    3PC比2PC多了一个阶段:第一阶段会先询问参与者能否准备提交,此阶段不阻塞资源。

    3PC基于一个理论:如果第一阶段所有参与者返回成功,那么成功提交的概率很大。

    3PC优于2PC的几个方面:

    • 在询问阶段不阻塞资源,能够一定程度上提高性能。
    • 在第三阶段,如果协调者挂掉,则能保证事务最终提交。

    3PC同样也存在一个问题:面对网络超时,难以适从。

    4.3.Paxos算法

    Paxos 算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致,保证不论发生以上任何异常,都不会破坏决议的一致性。

    一个典型的场景是,在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点都执行相同的操作序列,那么他们最后能得到一个一致的状态。

    为保证每个节点执行相同的命令序列,需要在每一条指令上执行一个「一致性算法」以保证每个节点看到的指令一致。

    Paxos算法基本上来说是个民主选举的算法——大多数的决定会成个整个集群的统一决定。

    任何一个点都可以提出要修改某个数据的提案,是否通过这个提案取决于这个集群中是否有超过半数的结点同意(所以Paxos算法需要集群中的结点是单数)。

    其实,2PC/3PC都是分布式一致性算法的残次版本,Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品。

    Paxos算法保证在任何阶段被打断,都能保证最终的正确性。

    由于本人水平有限,并未深入学习Paxos算法,所以只是给出了基本介绍,有需要的同学请自行了解。

    5.分布式锁

    在单机应用中,当多个线程访问共享资源时,我们通常通过synchronized关键字、Lock锁、线程安全对象等措施保证资源的安全使用。

    在分布式环境下,上述措施不再能满足需求,这事,我们需要一种应用于分布式换件的加锁机制,即:分布式锁。

    分布式锁的实现方式有多重,如:数据库、Redis、ZooKeeper等等。

    关于分布式锁,可以参考本人的另一篇文章:Redis: 分布式锁的官方算法RedLock以及Java版本实现库Redisson


    参考

    更多相关内容
  • UI设计中的一致性原则

    千次阅读 2020-09-08 15:40:58
    为什么一致性在UI设计中很重要,我们平常挂嘴边的一致性原则到底是什么?一致性原则如何影响用户行为?价值在哪里?  今天我就带大家探讨我们在处理界面的时候,如何遵循一致性原则,该如何去做?  一致性原则的优势...

      为什么一致性在UI设计中很重要,我们平常挂嘴边的一致性原则到底是什么?一致性原则如何影响用户行为?价值在哪里?

      今天我就带大家探讨我们在处理界面的时候,如何遵循一致性原则,该如何去做?

      一致性原则的优势

      我们遵循一致性的原则目的是为了减少用户认知负荷,用户能够轻易上手使用产品,熟悉的导航路径,熟悉的设计模式。

      我们知道,我们的用户是忙碌的,没有耐心,他们不愿意花更多时间来学习使用你的产品。所以我们在做设计时候,就尽量多遵循常用的UI Patterns,它是什么?是一种常用可用性问题的一种通用解决方案。

      但是如果一味遵循常有的Design Patterns,会导致我们界面看起来无创新,那么该什么时候突破这种界限,下面我会简单举例说明。

      影响它的关键要素

      颜色、间距、字体大小、图标一致性、规则一致性、交互操作等,我们在做界面设计时,如何科学把控这些?

      这里就要告诉大家一个常用的设计法则“重复”“节奏”“韵律”,学过平面设计的同学应该知道,这几个点吧,在平面设计中运用比较多的种设计方法。

      举一个例子,重复如何运用在UI设计中?

      重复间距

    UI设计中的一致性原则

     

    UI设计中的一致性原则

     

     

      上两图中,我们看可以看出里面设计采用的间距都是基于8的倍数,并重复运用。有节奏、有韵律的重复使用这些间距,可以产生节奏美。

      重复控件

    UI设计中的一致性原则

     

     

      上图facebook截图,UI设计中的一致性原则https://www.aaa-cg.com.cn/ui/2651.html按钮表象层圆角基因一致。如果有大小差异,它们使用参数化原则去定义圆角,大一点的控件圆角大一些,反之亦然。

      布局规则

    UI设计中的一致性原则

     

     

      上图是腾讯视频界面截图,我们可以看到他们在布局上制定了一些规则。

      一致性原则影响着用户行为

      如导航模式;一级导航,二级导航,如果采用常用设计模式,用户基本可以很轻松的找到自己想要的内容。

      再来说下颜色如何影响用户行为:比如系统里面定义蓝色是可点击的颜色,那么我们在做设计是时候就要注意,哪些可点击,颜色使用是否合理,同类颜色,表达相同的含义,就不能用在其他意义的元素上。

      大原则:相同含义的元素在不同的地方执行相同的操作时候,反馈机制需要一致。

    UI设计中的一致性原则

     

     

      上图左边是ios的开关,右边是materials design 材质设计系统的开关,这两种开关大同小异,它符合用户心理表真,我们日常生活中家里灯开关不就和这个类似吗?所以在我们设计这些就可以尽量遵循用户的心里表真,保持内部外部一致性。

      再比如在ios系统里面在对应列表上左滑动是可以对该列表操作的,那么在安卓里面的列表设计就需要慎用左滑操作。

      总结

      一致性设计大方向为产品有更杰出的体验,在保证用户体验良好的同时,我们需要与同类产品做出差异化竞争设计,这就需要我们平时多观察互联网设计趋势,国外设计趋势,集合自己品牌去打造一套好用的产品。

      在产品设计中我们时刻留意着关键元素的一致性的运用,确保产品整体体验一致。

      1.颜色:在使用颜色上需要严格去定义,比如绿色用于正确颜色,红色用语错误颜色,蓝色是可以点击颜色,这些都是常用的设计模式。

      2.布局/排版:布局遵循最小化设计原则,导航路径清晰可见,一级导航和二级导航一定要区分清楚,二者不可混用,排版布局上尽量遵循格式塔心理学原理。

      3.字体:一个app使用一种字体贯穿整个产品设计,字体大小运用重复原则,重复可以使其保持一致性。

      4.交互:这里我简单说下,操作模式,反馈机制要符合用户心理表真,常用功能操作流程要和外部环境保持一致性,比如我点击界面上蓝色文字这时候就要有正确反馈机制,而不是出一个弹窗。

      5.图标:图标一致性我相信大家都懂吧,以前写了一篇关于图标规范的,有兴趣的可以去看下,5招轻松打造系统图标规范。

    展开全文
  • CAP, BASE, 最终一致性和五分钟原则

    万次阅读 2017-02-16 16:30:34
    CAP,BASE和最终一致性是NoSQL数据库存在的三大基石。而五分钟法则是内存数据存储的理论依据。这个是一切的源头。 CAP     C: Consistency 一致性A: Availability 可用性(指的是快速获取数据)...
    CAP,BASE和最终一致性是NoSQL数据库存在的三大基石。而五分钟法则是内存数据存储的理论依据。这个是一切的源头。

    CAP

     


     

    • C: Consistency 一致性
    • A: Availability 可用性(指的是快速获取数据)
    • P: Tolerance of network Partition 分区容忍性(分布式)

     

    10年前,Eric Brewer教授指出了著名的CAP理论,后来Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性。CAP理论告诉我们,一个分布式系统不可能满足一致性,可用性和分区容错性这三个需求,最多只能同时满足两个。
    而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。如果你关注的是一致性,那么您就需要处理因为系统不可用而导致的操作失败的情况,而如果您关注的是可用性,那么您应该知道系统的read操作可能不能精确的读取到write操作写入的最新值。因此系统的关注点不同,相应的采用的策略也是不一样的,只有真正的理解了系统的需求,才有可能利用好CAP理论。

    作为架构师,一般有两个方向来利用CAP理论
    key-value存储,如Amaze Dynamo等,可根据CAP三原则灵活选择不同倾向的数据库产品。
    领域模型 + 分布式缓存 + 存储 (Qi4j和NoSql运动),可根据CAP三原则结合自己项目定制灵活的分布式方案,难度高。
    我准备提供第三种方案:实现可以配置CAP的数据库,动态调配CAP。

    • CA:传统关系数据库
    • AP:key-value数据库
    而对大型网站,可用性与分区容忍性优先级要高于数据一致性,一般会尽量朝着 A、P 的方向设计,然后通过其它手段保证对于一致性的商务需求。架构设计师不要精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。
    不同数据对于一致性的要求是不同的。举例来讲,用户评论对不一致是不敏感的,可以容忍相对较长时间的不一致,这种不一致并不会影响交易和用户体验。而产品价格数据则是非常敏感的,通常不能容忍超过10秒的价格不一致。 

    CAP理论的证明: Brewer's CAP Theorem

    最终一致性

    一言以蔽之:过程松,结果紧,最终结果必须保持一致性

     

    为了更好的描述客户端一致性,我们通过以下的场景来进行,这个场景中包括三个组成部分:
    • 存储系统
    存储系统可以理解为一个黑盒子,它为我们提供了可用性和持久性的保证。
    • Process A
    ProcessA主要实现从存储系统write和read操作
    • Process B 和ProcessC 
    ProcessB和C是独立于A,并且B和C也相互独立的,它们同时也实现对存储系统的write和read操作。


    下面以上面的场景来描述下不同程度的一致性:

    • 强一致性
    强一致性(即时一致性) 假如A先写入了一个值到存储系统,存储系统保证后续A,B,C的读取操作都将返回最新值
    • 弱一致性
    假如A先写入了一个值到存储系统,存储系统不能保证后续A,B,C的读取操作能读取到最新值。此种情况下有一个“不一致性窗口”的概念,它特指从A写入值,到后续操作A,B,C读取到最新值这一段时间。
    • 最终一致性
    最终一致性是弱一致性的一种特例。假如A首先write了一个值到存储系统,存储系统保证如果在A,B,C后续读取之前没有其它写操作更新同样的值的话,最终所有的读取操作都会读取到最A写入的最新值。此种情况下,如果没有失败发生的话,“不一致性窗口”的大小依赖于以下的几个因素:交互延迟,系统的负载,以及复制技术中replica的个数(这个可以理解为master/salve模式中,salve的个数),最终一致性方面最出名的系统可以说是DNS系统,当更新一个域名的IP以后,根据配置策略以及缓存控制策略的不同,最终所有的客户都会看到最新的值。

    变体

    • Causal consistency(因果一致性)
    如果Process A通知Process B它已经更新了数据,那么Process B的后续读取操作则读取A写入的最新值,而与A没有因果关系的C则可以最终一致性。
    • Read-your-writes consistency (读己所写一致性)
    如果Process A写入了最新的值,那么Process A的后续操作都会读取到最新值。但是其它用户可能要过一会才可以看到。
    • Session consistency (会话一致性)
    此种一致性要求客户端和存储系统交互的整个会话阶段保证Read-your-writes consistency.Hibernate的session提供的一致性保证就属于此种一致性。
    • Monotonic read consistency (单调读一致性
    此种一致性要求如果Process A已经读取了对象的某个值,那么后续操作将不会读取到更早的值。
    • Monotonic write consistency (单调写一致性
    此种一致性保证系统会序列化执行一个Process中的所有写操作。

    BASE

    说起来很有趣,BASE的英文意义是碱,而ACID是酸。真的是水火不容啊。

    • Basically Available--基本可用
    • Soft-state --软状态/柔性 事务
    "Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的
    • Eventual Consistency --最终一致性
    最终一致性, 也是是 ACID 的最终目的。

    BASE模型反ACID模型,完全不同ACID模型,牺牲高一致性,获得可用性或可靠性: Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库) Soft state软状态 状态可以有一段时间不同步,异步。 Eventually consistent最终一致,最终数据是一致的就可以了,而不是时时一致。 

    BASE思想的主要实现有 
    1.按功能划分数据库 
    2.sharding碎片  

    BASE思想主要强调基本的可用性,如果你需要高可用性,也就是纯粹的高性能,那么就要以一致性或容错性为牺牲,BASE思想的方案在性能上还是有潜力可挖的。 

    其他


    I/O的五分钟法则

    在 1987 年, Jim Gray 与 Gianfranco Putzolu 发表了这个"五分钟法则"的观点,简而言之,如果一条记录频繁被访问,就应该放到内存里,否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。 看上去像一条经验性的法则,实际上五分钟的评估标准是根据投入成本判断的,根据当时的硬件发展水准,在内存中保持 1KB 的数据成本相当于硬盘中存取 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾,证实了五分钟法则依然有效(硬盘、内存实际上没有质的飞跃),而这次的回顾则是针对 SSD 这个"新的旧硬件"可能带来的影响。 
     






    不要删除数据


    Oren Eini(又名Ayende Rahien)建议开发者尽量避免数据库的软删除操作,读者可能因此认为硬删除是合理的选择。作为对Ayende文章的回应,Udi Dahan强烈建议完全避免数据删除。

    所谓软删除主张在表中增加一个IsDeleted列以保持数据完整。如果某一行设置了IsDeleted标志列,那么这一行就被认为是已删除的。Ayende觉得这种方法“简单、容易理解、容易实现、容易沟通”,但“往往是错的”。问题在于:

    删除一行或一个实体几乎总不是简单的事件。它不仅影响模型中的数据,还会影响模型的外观。所以我们才要有外键去确保不会出现“订单行”没有对应的父“订单”的情况。而这个例子只能算是最简单的情况。……

    当采用软删除的时候,不管我们是否情愿,都很容易出现数据受损,比如谁都不在意的一个小调整,就可能使“客户”的“最新订单”指向一条已经软删除的订单。

    如果开发者接到的要求就是从数据库中删除数据,要是不建议用软删除,那就只能硬删除了。为了保证数据一致性,开发者除了删除直接有关的数据行,还应该级联地删除相关数据。可Udi Dahan提醒读者注意,真实的世界并不是级联的:

    假设市场部决定从商品目录中删除一样商品,那是不是说所有包含了该商品的旧订单都要一并消失?再级联下去,这些订单对应的所有发票是不是也该删除?这么一步步删下去,我们公司的损益报表是不是应该重做了?

    没天理了。

    问题似乎出在对“删除”这词的解读上。Dahan给出了这样的例子:

    我说的“删除”其实是指这产品“停售”了。我们以后不再卖这种产品,清掉库存以后不再进货。以后顾客搜索商品或者翻阅目录的时候不会再看见这种商品,但管仓库的人暂时还得继续管理它们。“删除”是个贪方便的说法。

    他接着举了一些站在用户角度的正确解读:


    订单不是被删除的,是被“取消”的。订单取消得太晚,还会产生花费。

    员工不是被删除的,是被“解雇”的(也可能是退休了)。还有相应的补偿金要处理。

    职位不是被删除的,是被“填补”的(或者招聘申请被撤回)。

    在上面这些例子中,我们的着眼点应该放在用户希望完成的任务上,而非发生在某个
    实体身上的技术动作。几乎在所有的情况下,需要考虑的实体总不止一个。

    为了代替IsDeleted标志,Dahan建议用一个代表相关数据状态的字段:有效、停用、取消、弃置等等。用户可以借助这样一个状态字段回顾过去的数据,作为决策的依据。

    删除数据除了破坏数据一致性,还有其它负面的后果。Dahan建议把所有数据都留在数据库里:“别删除。就是别
    删除。”

    RAM是硬盘,硬盘是磁带


    Jim Gray在过去40年中对技术发展有过巨大的贡献,“内存是新的硬盘,硬盘是新的磁带”是他的名言。“实时”Web应用不断涌现,达到海量规模的系统越来越多,这种后浪推前浪的发展模式对软硬件又有何影响? 

    Tim Bray早在网格计算成为热门话题之前,就 讨论过以RAM和网络为中心的硬件结构的优势,可以用这种硬件建立比磁盘集群速度更快的RAM集群。
    对于数据的随机访问,内存的速度比硬盘高几个数量级(即使是最高端的磁盘存储系统也只是勉强达到1,000次寻道/秒)。其次, 随着数据中心的网络速度提高,访问内存的成本更进一步降低。通过网络访问另一台机器的内存比访问磁盘成本更低。就在我写下这段话的时候,Sun的 Infiniband产品线中有一款具备9个全互联非阻塞端口 交换机,每个端口的速度可以达到30Gbit/sec!Voltaire产品的端口甚至更多;简直不敢想象。(如果你想了解这类超高性能网络的最新进展,请关注Andreas Bechtolsheim在Standford开设的课程。)
    各种操作的时间,以2001年夏季,典型配置的 1GHz 个人计算机为标准:
    执行单一指令1 纳秒从L1 高速缓存取一个字2 纳秒从内存取一个字10 纳秒从磁盘取连续存放的一个字200 纳秒磁盘寻址并取字8 毫秒以太网2GB/s



    Tim还指出Jim Gray的 
    名言中后半句所阐述的真理:“对于随机访问,硬盘慢得不可忍受;但如果你把硬盘当成磁带来用,它吞吐连续数据的速率令人震惊;它天生适合用来给以RAM为主的应用做日志(logging and journaling)。”  

    时间闪到几年之后的今天,我们发现硬件的发展趋势在RAM和网络领域势头不减,而在硬盘领域则止步不前。Bill McColl提到用于并行计算的 海量内存系统已经出现
    内存是新的硬盘!硬盘速度提高缓慢,内存芯片容量指数上升,in-memory软件架构有望给各类数据密集的应用带来数量级的性能提升。小型机架服务器(1U、2U)很快就会具备T字节、甚至更大量的内存,这将会改变服务器架构中内存和硬盘之间的平衡。硬盘将成为新的磁带,像磁带一样作为顺序存储介质使用(硬盘的顺序访问相当快速),而不再是随机存储介质(非常慢)。这里面有着大量的机会,新产品的性能有望提高10倍、100倍。
    Dare Obsanjo指出 如果不把这句真言当回事,会带来什么样的恶劣后果—— 也就是Twitter正面临的麻烦。论及Twitter的内容管理,Obsanjo说,“如果一个设计只是简单地反映了问题描述,你去实现它就会落入磁盘 I/O的地狱。不管你用Ruby on Rails、Cobol on Cogs、C++还是手写汇编都一样,读写负载照样会害死你。”换言之,应该把随机操作推给RAM,只给硬盘留下顺序操作。  

    Tom White是 Hadoop Core项目的提交者,也是Hadoop项目管理委员会的成员。他对Gray的真言中“硬盘是新的磁带”部分作了更深入地探讨。White在讨论MapReduce编程模型的时候指出,为何对于Hadloop这类工具来说, 硬盘仍然是可行的应用程序数据存储介质:
    本质上,在MapReduce的工作方式中,数据流式地读出和写入硬盘,MapReduce是以硬盘的传输速率不断地对这些数据进行排序和合并。 与之相比,访问关系数据库中的数据,其速率则是硬盘的寻道速率(寻道指移动磁头到盘面上的指定位置读取或写入数据的过程)。为什么要强调这一点?请看看寻道时间和磁盘传输率的发展曲线。寻道时间每年大约提高5%,而数据传输率每年大约提高20%。寻道时间的进步比数据传输率慢——因此采用由数据传输率决定性能的模型是有利的。MapReduce正是如此。
    虽然固态硬盘(SSD)能否改变寻道时间/传输率的对比还有待观察, White文章的跟贴中,很多人都认为 SSD会成为RAM/硬盘之争中的平衡因素。  

    Nati Shalom对 内存和硬盘在数据库部署和使用中的角色作了一番有理有据的评述。 Shalom着重指出用数据库集群和分区来解决性能和可伸缩性的局限。他说,“数据库复制和数据库分区都存在相同的基本问题,它们都依赖于文件系统/硬盘 的性能,建立数据库集群也非常复杂”。他提议的方案是转向In-Memory Data Grid(IMDG),用Hibernate二级缓存或者GigaSpaces Spring DAO之类的技术作支撑,将持久化作为服务(Persistence as a Service)提供给应用程序。Shalom解释说,IMDG
    提供在内存中的基于对象的数据库能力,支持核心的数据库功能,诸如高级索引和查询、事务语义和锁。IMDG还从应用程序的代码中抽象出了数据的拓扑。通过这样的方式,数据库不会完全消失,只是挪到了“正确的”位置。
    IMDG相比直接RDBMS访问的优势列举如下:
    • 位于内存中,速度和并发能力都比文件系统优越得多
    • 数据可通过引用访问
    • 直接对内存中的对象执行数据操作
    • 减少数据的争用
    • 并行的聚合查询
    • 进程内(In-process)的局部缓存
    • 免除了对象-关系映射(ORM)
    你是否需要改变对应用和硬件的思维方式,最终取决于你要用它们完成的工作。但似乎公论认为,开发者解决性能和可伸缩性的思路已经到了该变一变的时候。

    Amdahl定律和Gustafson定律

    这里,我们都以S(n)表示n核系统对具体程序的加速比,K表示串行部分计算时间比例。 

    Amdahl 定律的加速比:S(n) = 使用1个处理器的串行计算时间 / 使用n个处理器的并行计算时间S(n) = 1/(K+(1-K)/n) = n/(1+(n-1)K)Gustafson定律的加速比:S(n) = 使用n个处理器的并行计算量 / 使用1个处理器的串行计算量S(n) = K+(1-K)n 
    有点冷是不是? 

    通俗的讲,Amdahl 定律将工作量看作1,有n核也只能分担1-K的工作量;而Gustafson定律则将单核工作量看作1,有n核,就可以增加n(1-K)的工作量。 

    这里没有考虑引进分布式带来的开销,比如网络和加锁。成本还是要仔细核算的,不是越分布越好。 

    控制算法的复杂性在常数范围之内。 
    展开全文
  • 一致性Hash介绍及使用场景

    千次阅读 2016-12-19 16:45:25
    上面的简单的一致性hash的方案在某些情况下但依旧存在问题:一个节点宕机之后,数据需要落到距离他最近的节点上,会导致下个节点的压力突然增大,可能导致雪崩,整个服务挂掉。 如下图所示, 当节点...

    个人博客:www.dutycode.com

    公众号:攀爬蜗牛    或者 dutycode_com 欢迎关注


    场景


    单个节点的缓存容量达到上限,无法继续单点增加内存,如何解决?

    单个节点支撑的QPS达到上限,如何解决? 

    初步方案

    增加N个缓存节点,为了保证缓存数据的均匀,一般情况会采用对key值hash,然后取模的方式,然后根据结果,确认数据落到哪台节点上:如下:

    hash(key)%N 

    很好,这个的确解决了上面的问题,实现了初步的分布式缓存,数据均匀分散到了各个节点上,流量请求也均匀的分散到了各个节点。

    但是如果出现以下情况,会带来什么问题?

    1、某台服务器突然宕机。缓存服务器从N变为N-1台。

    2、缓存容量达到上限或者请求处理达到上限,需要增加缓存服务器,假定增加1台,则缓存服务器从N变为N+1

    上面的情况带来的问题:

    增加或者删除缓存服务器的时候,意味着大部分的缓存都会失效。这个是比较致命的一点,缓存失效,如果业务为缓存不命中,查询DB的话,会导致一瞬间DB的压力陡增。可能会导致整个服务不可用。 

    换种描述方式,我们需要解决怎么样的问题?或者需求是怎样的?

         增删机器时,希望大部分key依旧在原有的缓存服务器上保持不变。举例来说:key1,key2,key3原先再Cache1机器上,现在增加一台缓存服务器,希望key1,key2,key3依旧在Cache1机器上,而不是在Cache2机器上。 


    改进方案(一致性Hash)

    一致性哈希算法的简单背景介绍 (此段内容来自网络)

    一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希(DHT)实现算法,设计目标是为了解决因特网中的热点(Hot spot)问题,初衷和CARP十分类似。一致性哈希修正了CARP使用的简单哈希算法带来的问题,使得分布式哈希(DHT)可以在P2P环境中真正得到应用。 

    一致性hash算法提出了在动态变化的Cache环境中,判定哈希算法好坏的四个定义:(来自百度百科

    1. 平衡性(Balance):平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去,这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。

    2. 单调性(Monotonicity):单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中,又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去,而不会被映射到旧的缓冲集合中的其他缓冲区。 

    3. 分散性(Spread):在分布式环境中,终端有可能看不到所有的缓冲,而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时,由于不同终端所见的缓冲范围有可能不同,从而导致哈希的结果不一致,最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的,因为它导致相同内容被存储到不同缓冲中去,降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生,也就是尽量降低分散性。 

    4. 负载(Load):负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中,那么对于一个特定的缓冲区而言,也可能被不同的用户映射为不同 的内容。与分散性一样,这种情况也是应当避免的,因此好的哈希算法应能够尽量降低缓冲的负荷。

    所以通过上面的定义可以看到,简单的hash(key)%N的方式,违背了 单调性 的这个原则。原因如上面提到的,增删机器的时候,原有的缓存大部分会失效,也就违背了单调性的原则。


    介绍:

        大部分文章都提到环形的hash空间,但是没有讲为什么是环形的。后面我会聊下我的想法。 

        使用常见的hash算法可以把一个key值哈希到一个具有2^32个桶的空间中。也可以理解成,将key值哈希到 [0, 2^32) 的一个数字空间中。 我们假设这个是个首尾连接的环形空间。如下图:

    blob.png

      假设我们现在有key1,key2,key3,key4 4个key值,我们通过一定的hash算法,将其对应到上面的环形hash空间中。

       k1=hash(key1);

       k2=hash(key2);

       k3=hash(key3);

       k4=hash(key4);

    blob.png

    同样的,假设我们有3台cache服务器,把缓存服务器通过hash算法,加入到上述的环中。一般情况下是根据机器的IP地址或者唯一的计算机别名进行哈希。

    c1=hash(cache1);

    c2=hash(cache2);

    c3=hash(cache3);

    blob.png

    接下来就是数据如何存储到cache服务器上了,key值哈希之后的结果顺时针找上述环形hash空间中,距离自己最近的机器节点,然后将数据存储到上面, 如上图所示,k1 存储到 c3 服务器上, k4,k3存储到c1服务器上, k2存储在c2服务器上。用图表示如下:

    blob.png

    增删机器的情况

    假设cache3服务器宕机,这时候需要从集群中将其摘除。那么,之前存储再c3上的k1,将会顺时针寻找距离它最近的一个节点,也就是c1节点,这样,k1就会存储到c1上了,看一看下下面的图,比较清晰。

    blob.png

    摘除c3节点之后,只影响到了原先存储再c3上的k1,而k3、k4、k2都没有受到影响,也就意味着解决了最开始的解决方案(hash(key)%N)中可能带来的雪崩问题。

    增加节点原理和删除时差不多~

    blob.png

    新增C4节点之后,原先存储到C1的k4,迁移到了C4,分担了C1上的存储压力和流量压力。

    几个问题:

    1、为什么需要想象成环形?

        为了保证节点宕机摘除之后,原先存储在当前节点的key能找到可存储的位置。举个极端的例子,在不是环状hash空间下,刚好缓存的服务器处于0这个位置,那么0之后是没有任何节点信息的,那么当缓存服务器摘除的时候,以前存储在这台机器上的key便找不到顺时针距离它最近的一个节点了。但如果是环形空间,0之后的最近的一个节点信息有可能是2^32-1这个位置,他可以找到0之后的节点。如下图描述可能清晰一点。

    blob.png

     

    2、为什么是2^32个桶空间?

      没有搞清楚,个人理解是为了保证足够的灵活性,减少hash带来的key值冲突。也方便后续增删节点。 

    继续改进

    上面的简单的一致性hash的方案在某些情况下但依旧存在问题:一个节点宕机之后,数据需要落到距离他最近的节点上,会导致下个节点的压力突然增大,可能导致雪崩,整个服务挂掉。

    如下图所示,

    blob.png

    当节点C3摘除之后,之前再C3上的k1就要迁移到C1上,这时候带来了两部分的压力:

         1)、之前请求到C3上的流量转嫁到了C1上,会导致C1的流量增加,如果之前C3上存在热点数据,则可能导致C1扛不住压力挂掉。

         2)、之前存储到C3上的key值转义到了C1,会导致C1的内容占用量增加,可能存在瓶颈。

    当上面两个压力发生的时候,可能导致C1节点也宕机了。那么压力便会传递到C2上,又出现了类似滚雪球的情况,服务压力出现了雪崩,导致整个服务不可用。

    如果解决上面的问题?

    虚拟节点。歪果人的脑子真好使,想出这么一个牛逼的方式,虚拟节点。

    如上描述,一个节点宕机之后可能会引起下个节点的存储及流量压力变大,这一点违背了最开始提到的四个原则中的 平衡性, 节点宕机之后,流量及内存的分配方式打破了原有的平衡。

    虚拟节点,从名字可以看出来,这个节点是个虚拟的,每个实际节点对应多个虚拟节点。比较专业的说法如下:

    “虚拟节点”( virtual node )是实际节点(机器)在 hash 空间的复制品( replica ),一实际个节点(机器)对应了若干个“虚拟节点”,这个对应个数也成为“复制个数”,“虚拟节点”在 hash 空间中以hash值排列。

    依旧用图片来解释,假设存在以下的真实节点和虚拟节点的对应关系。

    Visual100—> Real1

    Visual101—> Real1

    Visual200—> Real2

    Visual201—> Real2

    Visual300—> Real3

    Visual301—> Real3

    同样的,hash之后的结果如下:

    hash(Visual100)—> V100  —> Real1

    hash(Visual101)—> V101  —> Real1

    hash(Visual200)—> V200  —> Real2

    hash(Visual201)—> V201  —> Real2

    hash(Visual300)—> V300  —> Real3

    hash(Visual301)—> V301  —> Real3

    key值的hash结果如上,这里暂时不写了。

    如图解释:

    blob.png

    和之前介绍的不添加虚拟节点的类似,主要聊下如果宕机之后的情况。 

    假设Real1机器宕机,则会发生一下情况。

    1、原先存储在虚拟节点V100上的k1数据将迁移到V301上,也就意味着迁移到了Real3机器上。 

    2、原先存储再虚拟节点V101上的k4数据将迁移到V200上,也就意味着迁移到了Real2机器上。

    结果如下图:

    12160867-2438-46F8-B74E-0B8E21F32187.png

    这个就解决之前的问题了,某个节点宕机之后,存储及流量压力并没有全部转移到某台机器上,而是分散到了多台节点上。解决了节点宕机可能存在的雪崩问题。

    当物理节点多的时候,虚拟节点多,这个的雪崩可能就越小。

    PS:只有2个节点的时候,加入虚拟节点没有用。你懂的。 

    公众号:扫一扫关注~~



    展开全文
  • 随着技术的进步和发展,CPU进入多核...存储器模型又称为存储一致性模型。用于定义系统中对存储器访问需要遵守的原则,只要软件和硬件都遵循该原则,就能保证多核程序能运行得到确切的结果。该模型同样适用于单核多线
  • 分布式下的数据一致性问题

    万次阅读 多人点赞 2020-07-31 14:03:53
    在分布式系统要满足CAP原则,一个提供数据服务的存储系统无法同时满足:数据一致性、数据可用性、分区耐受性。 C数据一致性:所有应用程序都能访问到相同的数据。 A数据可用性:任何时候,任何应用程序都可以读写...
  • 细说分布式下的数据一致性

    万次阅读 2018-08-29 11:21:47
    细说分布式下的数据一致性 名词解释 强一致性 最终一致性 XA事物 JDBC事物、JTA事物 TCC 产生场景 单一数据库、单一系统无法支撑业务和数据的增长而出现拆分化的演进,数据存储于不同的事物管理单元但又要...
  • 本文主要讲述分布式系统中的弱一致性模型,本文中的全部内容全部来自于清华大学分布式课程网站,网站地址http://thu-cmu.cs.tsinghua.edu.cn/curriculum/dscourse/index.html我们在之前的分布式系统一致性模型中介绍...
  • 数据库事务ACID原则学习分享

    千次阅读 2019-05-12 16:12:40
    上文提到的张三给李四转账的事务示例,也体现了一致性原则,但侧重点不一样,一致性就是强调数据库经过事务操作后由一个状态转变到另一个状态,数据依然要保持一致,举例解释一下,转账事务执行前张三和李四的账户...
  • 1,一致性协议 两阶段提交协议与Raft协议、Paxos协议 ①两阶段提交协议 在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了...
  • Flink学习之容错机制和状态一致性

    千次阅读 2022-03-08 08:45:05
    ☀️在前天的学习中,我们学习了flink中的几个重要概念:时间、水位线和状态,今天我们继续学习flink中的两个重要机制:容错机制和状态一致性保证。对往期内容感兴趣的同学可以参考: 链接: Flink学习中之time、...
  • 分布式一致性协议Raft & Paxos 简单 v.s. 完美
  • L1,L2,L3 cache 多核cpu怎么保证数据一致性(三)MESI缓存一致性协议 多核cpu怎么保证数据一致性(四)volatile关键字、happens-before原则、内存屏障 文章目录 系列文章目录 前言 一、什么是指令重排序 1、示例1-1...
  • 类型一致性和闭合行为   1 类class和类型type  从抽象的角度来理解,最好将类视为类型的实现。也就是说类型包括了类的目标以及类的状态空间和行为。实际上,一个类型可以有多个类,每个类都包括自己独立的内部...
  • 前言之前在学习MongoDB复制集时发现网上的很多相关的分享都是针对r3.2.0以前的版本,新版本对选举机制做了较大的更改,但是在网上大多都是一笔带过。于是写过一篇《MongoDB选举...最近了解了一些分布式一致性算法之后
  • 举例:张三和李四好久不见,老友约起聚餐,饭店老板要求先买单,才能出票。这时张三和李四分别抱怨近况不如 意,囊中羞涩,都不愿意请客,这时只能AA。只有张三和李四都付款,老板才能出票安排就餐。但由于张三和...
  • Visibility of status 可见原则 保证界面的内容可见,状态可见,变化可见 让用户知道自己在什么页面,可以做什么,怎么做,必要的反馈信息。...Consistency and standards 一致性 用户需要在同一个产品..
  • 体验设计五原则

    2019-11-05 15:30:25
    脑图: 一、一致性 一致性的益处:对用户来说,一致性可以降低学习成本,对开发团队来说,可以减少错误,降低产品的维护成本,提高代码和设计的复用率。...一致性的弊端:很多设计师容易被这一原则而禁锢,...
  • 用户可控原则产品名称体验点截图+标注+解释说明3.1 用户可自由导航、退出体验原则4:一致性
  • CAP原则又称CAP定理,指的是在一个分布式系统中,Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。 分布式系统(distributed system)正变得越来越重要,大型...
  • 影响力:承诺与一致原理

    千次阅读 2014-05-20 16:55:40
    通过赌马比赛这个例子引出承诺和一致的重要。当我们做出了某种决定的时候,往往会倾向的采取与我们所做的决定保持一致的行动。保持一致的愿望是我们行动的一个强大驱动力,为什么呢?在大多数的情况下,保持一致...
  • 微服务设计的四个原则

    千次阅读 2019-02-14 23:32:55
    通过加机器就可以解决容量和可用问题。(如果一台不行那就两台)。 (世界上没有什么事是一顿烧烤不能解决的。如果有,那就两顿。)   这一理念在“云计算”概念疯狂流行的今天,得到了广泛的认可!对于一个规模...
  • 很久没有更新,今天说些和分布式系统中的一些概念、理论相关的东西,切入点是CAP。 CAP ...1、Consistency(一致性):一致性是说数据的原子性,这种原子性在经典的数据库中是通过事务来保证
  • 一、核心原则 1、尽量不在数据库做运算 俗话说:别让脚趾头想事情,那是脑瓜子的职责。作为数据库开发人员,我们应该让数据库多做她所擅长的事情。尽量不在数据库做运算,复杂运算移到程序端CPU,尽可能简单应用...
  • 大约10多天前,Amazon发布了自己今年最新版的“领导力原则”,这里我翻译一下,以飨读者。虽然这个文档中没有说谁是领导,但看下来就知道:领导指的是各层级的干部,只要你手下有团队,你就是领...
  • SMART原则助你设定有效目标

    万次阅读 2015-11-17 06:37:55
    目标就可以让人工作和生活充满动力,SMART原则指导我们如何设定有效目标……
  • 设计模式的六大原则

    万次阅读 多人点赞 2019-05-16 17:50:03
    一、单一职责原则(Single Responsibility Principle) 二.开闭原则(Open-Closed Principle, OCP) 三、里氏代换原则(Liskov Substitution Principle, LSP) 四、依赖倒置原则(Dependence Inversion Principle,...
  • 文章目录系统设计的核心点 系统设计的核心点 直接切入正题 如何更好地去设计一个高并发的系统? 我们首先应该从整体出发...另外,为了系统的稳定,通常我们也需要对系统做一些保护,针对意料之外的情况设计兜底方案
  • web交互设计原则

    千次阅读 2017-03-05 10:14:20
    别让我思考这是最重要的原则,如果你只能记住一条可用性原则,那么就记住这条。它意味着,设计者应该尽量做到,当我看一个页面时,它应该是不言而喻,一目了然,自我解释的。 网页上的每项内容都有可能迫使我们停...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 45,766
精华内容 18,306
关键字:

一致性原则举例