精华内容
下载资源
问答
  • ZooKeeper和CAP理论及一致性原则

    万次阅读 2020-03-19 16:44:38
    ZooKeeper和CAP理论及一致性原则 一、CAP理论概述 CAP理论告诉我们,一个分布式系统不可能同时满足以下三种 一致性(C:Consistency) 可用性(A:Available) 分区容错性(P:Partition Tolerance) 这三个...

    ZooKeeper和CAP理论及一致性原则

    一、CAP理论概述

    CAP理论告诉我们,一个分布式系统不可能同时满足以下三种

    • 一致性(C:Consistency)
    • 可用性(A:Available)
    • 分区容错性(P:Partition Tolerance)

    这三个基本需求,最多只能同时满足其中的两项,因为P是必须的,因此往往选择就在CP或者AP中

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NS5yD5JX-1584607472252)(http://www.ymq.io/images/2018/ZooKeeper/1.png)]

    一致性(C:Consistency)

    在分布式环境中,一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下,当一个系统在数据一致的状态下执行更新操作后,应该保证系统的数据仍然处于一致的状态。例如一个将数据副本分布在不同分布式节点上的系统来说,如果对第一个节点的数据进行了更新操作并且更新成功后,其他节点上的数据也应该得到更新,并且所有用户都可以读取到其最新的值,那么这样的系统就被认为具有强一致性(或严格的一致性,最终一致性)。

    可用性(A:Available)

    可用性是指系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果。“有效的时间内”是指,对于用户的一个操作请求,系统必须能够在指定的时间(即响应时间)内返回对应的处理结果,如果超过了这个时间范围,那么系统就被认为是不可用的

    “返回结果”是可用性的另一个非常重要的指标,它要求系统在完成对用户请求的处理后,返回一个正常的响应结果。正常的响应结果通常能够明确的反映出对请求的处理结果,即成功或失败,而不是一个让用户感到困惑的返回结果。

    分区容错性(P:Partition Tolerance)

    分区容错性约束了一个分布式系统需要具有如下特性:分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障

    网络分区是指在分布式系统中,不同的节点分布在不同的子网络(机房或异地网络等)中,由于一些特殊的原因导致这些子网络之间出现网络不连通的状况,但各个子网络的内部网络是正常的,从而导致整个系统的网络环境被切分成了若干个孤立的区域。需要注意的是,组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。

    由于一个分布式系统无法同时满足上面的三个需求,而只能满足其中的两项,因此在进行对CAP定理的应用的时候,需要根据业务的要求抛弃其中的一项,下表所示是抛弃CAP定理中任意一项特性的场景说明。

    因此,将精力浪费在思考如何设计能满足三者的完美系统上是愚钝的,应该根据应用场景进行适当取舍。

    二、一致性的分类

    一致性是指从系统外部读取系统内部的数据时,在一定约束条件下相同,即数据变动在系统内部各节点应该是同步的。根据一致性的强弱程度不同,可以将一致性的分类为如下几种:

    强一致性:(strong consistency)。任何时刻,任何用户都能读取到最近一次成功更新的数据。

    单调一致性:(monotonic consistency)。任何时刻,任何用户一旦读到某个数据在某次更新后的值,那么就不会再读到比这个值更旧的值。也就是说,可获取的数据顺序必是单调递增的。

    会话一致性:(session consistency)。任何用户在某次会话中,一旦读到某个数据在某次更新后的值,那么在本次会话中就不会再读到比这值更旧的值,会话一致性是在单调一致性的基础上进一步放松约束,只保证单个用户单个会话内的单调性,在不同用户或同一用户不同会话间则没有保障。

    最终一致性:(eventual consistency)。用户只能读到某次更新后的值,但系统保证数据将最终达到完全一致的状态,只是所需时间不能保障。

    弱一致性:(weak consistency)。用户无法在确定时间内读到最新更新的值。

    三、ZooKeeper提供的一致性服务

    ZooKeeper从以下几点保证了数据的一致性

    顺序一致性来自任意特定客户端的更新都会按其发送顺序被提交保持一致。也就是说,如果一个客户端将Znode z的值更新为a,在之后的操作中,它又将z的值更新为b,则没有客户端能够在看到z的值是b之后再看到值a(如果没有其他对z的更新)。

    原子性每个更新要么成功,要么失败。这意味着如果一个更新失败,则不会有客户端会看到这个更新的结果。

    单一系统映像一个客户端无论连接到哪一台服务器,它看到的都是同样的系统视图。这意味着,如果一个客户端在同一个会话中连接到一台新的服务器,它所看到的系统状态不会比 在之前服务器上所看到的更老。当一台服务器出现故障,导致它的一个客户端需要尝试连接集合体中其他的服务器时,所有滞后于故障服务器的服务器都不会接受该 连接请求,除非这些服务器赶上故障服务器。

    持久性一个更新一旦成功,其结果就会持久存在并且不会被撤销。这表明更新不会受到服务器故障的影响。

    实时性:在特定的一段时间内,客户端看到的系统需要被保证是实时的(在十几秒的时间里)。在此时间段内,任何系统的改变将被客户端看到,或者被客户端侦测到。

    四、用CAP理论来分析ZooKeeper

    CAP理论告诉我们,一个分布式系统不可能同时满足以下三种

    • 一致性(C:Consistency)
    • 可用性(A:Available)
    • 分区容错性(P:Partition Tolerance)

    这三个基本需求,最多只能同时满足其中的两项,因为P是必须的,因此往往选择就在CP或者AP中

    在此ZooKeeper保证的是CP

    分析:可用性(A:Available)

    不能保证每次服务请求的可用性。任何时刻对ZooKeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注:也就是在极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果)。所以说,ZooKeeper不能保证服务可用性。

    进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说,ZooKeeper不能保证服务可用性。

    参考:https://www.cnblogs.com/xrq730/p/4944768.html

    参考:https://blog.csdn.net/xiangxizhishi/article/details/78469027

    Contact

    • 作者:鹏磊
    • 出处:http://www.ymq.io/2018/05/18/zookeeper
    • 版权归作者所有,转载请注明出处
    • Wechat:关注公众号,搜云库,专注于开发技术的研究与知识分享

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4K7uXhVU-1584607472253)(http://www.ymq.io/images/souyunku.png “搜云库”)]

    展开全文
  • 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)的工作量。 

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

    控制算法的复杂性在常数范围之内。 
    展开全文
  • PCB绘图的基本要求和布线原则

    万次阅读 多人点赞 2019-05-23 19:30:35
    PCB绘图的基本要求和布线原则 首先讲一下为什么对于布线有着这么多的要求。 1、布局/布线,对电气性能的影响 数字地线与模拟地线要分开。这在实际操作上一定的难度。要布出更好的板,首先您得对您所使用的IC...

    PCB绘图的基本要求和布线原则

    首先讲一下为什么对于布线有着这么多的要求。

    1、布局/布线,对电气性能的影响

    数字地线与模拟地线要分开。这在实际操作上有一定的难度。要布出更好的板,首先您得对您所使用的IC电气方面的了解,有哪些引脚会产生高次谐波(数字信号或开关量方波信号的上升/下降沿),哪些引脚易感应电磁于扰,IC内部的信号方框图(信号处理单元方块图)有助我们的了解。

    整机布局是决定电气性能的首要条件,而板间的布局更多的考虑是IC间的信号/数据的走向或流程,大原则是易产生电磁幅射的尽可能靠近电源部分;弱信号处理部分多由设备的整体结构决定(即前期设备的整体规划),尽可能靠近信号的输入端或检测头(探头),这样可以更好的提高信噪比,为后续的信号处理及数据识别提供更纯净的信号/准确的数据。

    PCB绘图的基本步骤和方法

    2、PCB铜铂的处理

    由于现在的IC工作时钟(数字IC)越来越高,其信号对于线路的宽度提出了一定的要求,走线宽了(铜铂)对于低频强电流是好的,但对于高频信号及数据线信号来说,却并非如此,数据信号讲求更多的是同步,高频信号多受集肤效应所影响,所以高频信号走线宜细不宜宽,宜短不宜长,这又涉及布局问题(器件间信号的耦合),这样可以减小感应电磁干扰。

    而数据信号,却是以脉冲形式出现在电路上的,其高次谐波份量是保证信号的正确性起到决定因素;同样的宽铜铂会对高速率的数据信号产生集肤效应(分布电容/电感变大),这样会导致信号变坏,数据识别不正确,而且数据总线通道要是其中的线路宽度不一致更会影响数据的同步问题(导致不一致的延迟),为了更好的控制数据信号的同步问题,所以在数据总线走线中就出现了蛇形线,这是为了让数据通道内的信号在延迟上更趋于一致。

    大面积的铺铜是针对于屏蔽干扰及感应干扰而言的,双面板可以让地作为铺铜层;而多层板就不存在铺铜的问题,因为其间的电源层就是很好的起到屏蔽及隔离作用。

    3、多层板的层间布局

    以四层板为例作个说明,应将电源正/负层放在中间,信号层在外面两层走线,注意正负电源层间不应出现信号层,这样做法的好处,就是尽最大的可能让电源层发挥滤波/屏蔽/隔离的作用,同时方便PCB生产厂家的生产,以提高良品率。

    4、过孔

    工程设计应尽量减少过孔的设计,因为过孔会产生电容的同时,也易出现毛刺而产生电磁幅射。过孔的孔径宜小不宜大(这是对于电气性能而言;但过小的孔径会增加PCB 生产难度,一般常用0.5mm/0.8mm,0.3mm尽可能小用),小孔径在沉铜工艺后出现毛刺的概率要比大孔径出现毛刺概率小,这是由于钻孔工艺所致。

    5、软件应用

    每个软件都有它的易用性,只是您对该软件的熟习程度,PADS(POWER PCB)/PROTEL我都有用过,在作简单的线路时(自己熟习的线路),我会用PADS直接Layout;而作复杂及新器件线路时,还是先行画好原理图,用网络表的形式来做,要正确与方便些。

    Layout PCB时,有些非圆形孔,软件上是没有相应的功能来描述的,我通常的做法是:开一个专门用于表述开孔的图层,然后在这层上画出想要的开孔形状,当然应填充满画出的线框,这样做是为了更好的让PCB生产厂家识别出自己的表述,并在做样的说明文档上加以说明

     

    布局原则

    1、遵照“先大后小,先难后易”的布置原则,即重要的单元电路、核心元器件应当优先布局。

    这里写图片描述 
    先大后小,先难后易 
    这里写图片描述 
    上图中1是因为机械结构决定电源与接线柱在这里。

    2、布局中应参考原理框图,根据单板的主信号流向规律安排主要元器件。布局应尽量满足以下要求:总的连线尽可能短,关键信号线最短;去耦电容的布局要尽量靠近IC的电源管脚,并使之与电源和地之间形成的回路最短 ;减少信号跑的冤枉路,防止在路上出意外。

    例如下图, C8到C11都是在VCC与GND之间的去耦电容,在原理图中并没有办法体现出它们的位置要求。但是PCB中们应当布局在芯片电源的输入引脚附件,例如31与32脚附近应有电容,18与19脚附近也应有电容。 
    这里写图片描述 
    错误示例,并排放置 
    这里写图片描述 
    正确示例,靠近芯片电源输入脚 
    这里写图片描述

    3、元器件的排列要便于调试和维修,亦即小元件周围不能放置大元件、需调试的元器件周围要有足够的空间,弄得太挤局面往往会变得很尴尬。如下图R7与C7,如果先焊接周围的器件的话,R7与C7就很难焊接了。(这里也说明了焊接的顺序很重要)

    这里写图片描述

    4、 相同结构电路部分,尽可能采用“对称式”标准布局;按照均匀分布、重心平衡、版面美观的标准优化布局。

    这里写图片描述 
    均匀分布、重心平衡,布局要整齐 
    这里写图片描述

    5、同类型插装元器件在X或Y方向上应朝一个方向放置。同一种类型的有极性分立元件也要力争在X或Y方向上保持一致,便于生产和检验。 (如需要人工确认器件极性,可能要生产成本会上升)

    这里写图片描述

    6、发热元件要一般应均匀分布,以利于单板和整机的散热,除温度检测元件以外的温度敏感器件应远离发热量大的元器件。除了温度传感器,三极管也属于对热敏感的器件。

    这里写图片描述

    7、高电压、大电流信号与小电流,低电压的弱信号完全分开;模拟信号与数字信号分开;高频信号与低频信号分开;高频元器件的间隔要充分。元件布局时,应适当考虑使用同一种电源的器件尽量放在一起,以便于将来的电源分隔。

    这里写图片描述

    PCB布局示例 
    这里写图片描述

    2 布线原则

    以上即是关于“怎么摆”即布局的主要注意事项。而关于“怎么连”则相对要更复杂一些,大体来说就是:

    • 关键信号线优先:摸拟小信号、高速信号、时钟信号和同步信号等关键信号优先布线 ; 
    • 密度优先原则:从单板上连接关系最复杂的器件着手布线。从单板上连线 最密集的区域开始布线 。

    而布线的自助指南可以简单的总结为: 
    1、尽量为时钟信号、高频信号、敏感信号等关键信号提供专门的布线层,并保证其最小的回路面积。必要时应采取手工优先布线、屏蔽和加大安全间距等方法,保证信号质量。 
    2、电源层和地层之间的EMC环境较差,应避免布置对干扰敏感的信号。 
    3、有阻抗控制要求的网络应尽量按线长线宽要求布线。

    3 根据原理图布局的示例

    如果布局不合适,板子使用起来可能很不方便,布线难度很大。 
    布局时配合完成某一个功能的器件尽量挨得近一些,有操作技巧,接下来举例说明。 
    可以在原理图中先找到运放模块的器件,按住ctrl选中。 
    这里写图片描述 
    则PCB中,这些器件也已经被选中 
    这里写图片描述 
    然后观察原理图中的连接关系,比如C4接R3,R5,Q1。在PCB中找到这几个器件,放在一起。 
    观察预拉线的情况,已知每一个器件都有一个公共的网络叫做VB,可以按住ctrl选中网络属性为VB的一个焊盘,则VB高亮,例如 
    这里写图片描述 
    调整后编程如下布局 
    这里写图片描述 
    观察原理图中,Q1接R6,然后把R6也拖拽过来 
    这里写图片描述 
    其它器件以此类推 
    这里写图片描述 
    然后布线就可以比较顺利 
    这里写图片描述

    4 低频双面板布线示例

    这里写图片描述 
    器件导入PCB以后,先按要求完成布局。 
    然后有信号线,不论是串口、485还是CAN,信号线都要尽可能短,少打过孔,有时还要匹配长度,如差分。另外有时钟线,如晶振,也要短,少打过孔。

    1 先走信号、时钟线。

    2 走电源线,两种电源,VCC与VCC3.3。可以专门为电源线设置一个宽度规则。电源类的线也应当少走过孔,若确实需要,可以多个过孔并联

    这里写图片描述 
    这里写图片描述 
    这里写图片描述

    3 地线,可以根据情况决定。如大面积敷铜,可以考虑不走地线。如需要走地线,线宽应满足以下关系

    地线>电源线>信号线

    4 其它线,布线之前要观察尽可能在某个区域内,水平线与竖直线在不同的层。

    这里写图片描述 
    水平线与竖直线走在不同的层 
    这里写图片描述 
    可适当调整器件的方向来方便走线。 
    目的地相近的线要整齐。可以采用交互式多根线连接工具 
    这里写图片描述 
    如果线不可避免地要交叉,可以考虑绕大圈(当然要考虑线的属性) 
    如图飞线交叉了。可以绕圈。 
    这里写图片描述 
    这里写图片描述

     

    展开全文
  • 分布式数据库的数据一致性管理是其最重要的内核技术之一,也是保证分布式数据库满足数据库最基本的ACID特性中的 “一致性”(Consistency)的保障。在分布式技术发展下,数据一致性的解决方法和技术也在不断的演进,...

    前言

    分布式数据库的数据一致性管理是其最重要的内核技术之一,也是保证分布式数据库满足数据库最基本的ACID特性中的 “一致性”(Consistency)的保障。在分布式技术发展下,数据一致性的解决方法和技术也在不断的演进,本文就以分布式数据库作为案例,介绍分布式数据库数据一致性的原理以及实际实现。

    1、数据一致性

    1.1 数据一致性是什么

    大部份使用传统关系型数据库的DBA在看到“数据一致性”时,第一反应可能都是数据在跨表事务中的数据一致性场景。但是本文介绍的“数据一致性”,指的是**“数据在多份副本中存储时,如何保障数据的一致性”**场景。

    由于在大数据领域,数据的安全不再由硬件来保证,而是通过软件手段,通过同时将数据写入到多个副本中,来确保数据的安全。数据库在同时向多个副本写入记录时,如何确保每个副本数据一致,称为“数据一致性”。

    1.2 关系型数据库如何保障数据一致性

    传统的关系型数据库对于运行环境–硬件要求都比较高,例如Oracle会建议用户使用小型机+共享存储作为数据库的运行环境,DB2 DPF也同样建议用户采用更好的服务器+高端存储来搭建数据库的运行环境。所以在数据存储安全的技术要求下,传统关系型数据库更多是依赖硬件的技术来保障数据的安全性。

    在这里插入图片描述
    因为关系型数据库的数据安全是基于硬件来保障,并且数据也不会通过同时存储多份来保障数据的安全,所以关系型数据库的用户默认认为数据存储是一致的。

    1.3 分布式存储如何保障数据一致性

    本文在讨论分布式存储时,主要指的是大数据产品中的分布式文件系统和分布式数据库,例如:SequoiaDB和HDFS。

    用户在搞明白分布式存储的数据一致性原理时,必须要先明白为什么他们就需要数据一致性,和分布式存储的数据存储与关系型数据库的数据存储又有什么区别。

    大数据技术的诞生,确确实实让系统的性能有新的突破,并且支持硬件以水平扩展的方式来获得线性增长的性能和存储。这些都是过去传统关系型数据库所无法提供的。另外,大数据技术也抛弃了运行环境必须足够好的硬性要求,而是允许用户通过批量廉价X86服务器+本地磁盘的方式搭建规模集群,从而获得比过去依赖硬件垂直扩展所提供的更强的计算能力和更多的存储空间。

    大数据技术的核心思想就是分布式,将一个大的工作任务分解成多个小任务,然后通过分布式并发操作的方式将其完成,从而提高整个系统的计算效率或者是存储能力。而在分布式环境下,由于硬件的要求降低,必然需要大数据产品提供另外一个重要的功能–数据安全

    在这里插入图片描述
    大数据产品在解决数据安全的方式上,都比较接近,简单来说,就是让一份数据通过异步或者同步的方式保存在多台机器上,从而保障数据的安全。

    分布式存储在解决数据安全的技术难点后,又引入了一个新的技术问题,就是如何保障多个副本中的数据一致性。目前SequoiaDB是使用Raft算法来保证数据在多个副本中一致性。

    2、Raft算法

    2.1 Raft算法背景

    在分布式环境下,最著名的一致性算法应该是Paxos算法,但是由于它实在过于晦涩难懂,并且实现起来极度困难,所以在2013年,Diego Ongaro、John Ousterhout两个人以易懂(Understandability)为目标设计了一套一致性算法Raft。Raft算法最大的特点在于简单易懂,并且实现起来简单

    2.2 Raft算法概述

    与Paxos不同,Raft强调的是易懂,Raft和Paxos一样只要保证n/2+1节点正常就能够提供服务。

    众所周知当问题较为复杂时可以把问题分解为几个小问题来处理,Raft也使用了分而治之的思想。Raft算法重点解决三个子问题:选举(Leader election)、日志复制(Log replication)、安全性(Safety)。

    Raft算法强化了Leader节点的功能,Follower节点的数据只能够从Leader中获取,所以Follower节点的实现就变得简单,只要负责和Leader保持通信,并且接受Leader推送的数据即可。

    2.3 Raft算法原理

    2.3.1 节点角色

    Raft算法中,对节点的状态分为3种角色,分别是Leader(领导者)、Follower(追随者)和Candidate(候选者)。

    Leader,负责处理来自客户端的请求,负责将日志同步到Follower中,并且保证与Follower之间的heartBeat联系;

    Follower,当集群刚刚启动时,所有节点均为Follower状态,它的工作主要为响应Leader的日志同步请求,响应Candidate的请求,以及把请求到Follower的事务请求转发给Leader;

    Candidate,选举Leader时负责投票,选举出来Leader后,节点将从Candidate状态变为Leader状态。

    在这里插入图片描述

    2.3.2 Terms

    在分布式环境下,“时间同步”一直都是老大难的技术难题。Raft为了解决这个问题,将时间划分为一个一个的Term(可以理解为“逻辑时间”)来处理在不同时间段里的数据一致性。

    Terms有以下原则

    • 每个Term中,至多存在一个Leader
    • 某些Term中,有可能存在由于选举失败,没有Leader的情况
    • 每个节点自己维护本地的currentTerm
    • 每个Term都是一个连续递增的编号
    • 如果Follower的Term编号比别的Follower Term编号小时,该Follower Term编号将更新Term编号,以保持与其他Follower Term编号一致

    2.3.3 选举

    Raft的选举由定时器触发,每个节点的触发时间都不相同。

    所有的节点在开始时状态都为Follower,当定时器触发选举后Term编号递增,该节点的状态由Follower转为Candidate,并且向其他节点发起RequestVote RPC请求,这时选举有3种情况可能发生:

    发起RequestVote的节点收到n/2+1(过半数)个节点的投票,该节点将从Candidate状态变为Leader状态,开始向其他节点发送HeartBeat以保持Leader的正常状态

    如果收到投票请求后,该节点发现发起投票的节点Term大于自己,则该节点状态从Candidate转为Follower,否则保持Candidate状态,并且拒绝该投票请求

    选举期间发生了超时,则Term编号递增,重新发起选举
    在这里插入图片描述

    2.3.4 日志复制

    日志复制主要的作用就是用来保证节点的数据一致性与高可用性。

    当Leader被选举出来后,所有的事务操作都必须要经过Leader处理。这些事务操作成功后,将会被按顺序写入到LOG中,每个LOG都包含一个index编号。

    Leader在LOG发生变化后,通过HeartBeat将新的LOG同步到Follower上,Follower在接收到LOG后,再向Leader发送ACK信息,当Leader接到大多数(2/n+1)Follower的ACK信息后,将该LOG设置为已提交,并且Leader将LOG追加到本地磁盘中。

    同时Leader将在下一个HeartBeat中,通知所有的Follower将该LOG存储在各自的本地磁盘中。

    2.3.5 安全性

    安全性是用于确保每个节点都是按照相同的日志序列进行执行的安全机制。

    如果当某个Follower在同步Leader的日志时失败,但是未来该Follower又可能被选举为Leader时,就有可能导致前一个Leader已经commit的日志发生覆盖,这样就导致了节点执行不同序列的日志。

    Raft的安全性就是用于保证选举出来的Leader一定包含先前已经commit LOG 的机制,主要遵循的原则如下:

    每个Term 只能选举一个Leader;

    Leader的日志完整性,则当Candidate重新选举Leader时,新的Leader必须要包含先前已经commit的LOG;

    Candidate在选举新的Leader时,使用Term来保证LOG的完整性;

    3、分布式数据库数据一致性技术实现

    以国产原厂的分布式数据库SequoiaDB为例,SequoiaDB在多副本的部署中,采用Raft算法保证数据在多副本环境中保持一致。

    SequoiaDB集群中,总共包含3中角色节点,分别是协调节点、编目节点和数据节点。由于协调节点本身不存任何数据,所以只有编目节点和数据节点存在事务操作,换言之,编目分区组和数据分区组的副本同步采用Raft算法保证数据一致性。

    在这里插入图片描述

    3.1 编目节点和数据节点的事务日志介绍

    编目节点和数据节点由于都是需要存储数据的,并且在集群部署中该,为了确保数据的安全,都是建议采用分布式的方式进行部署,所以在数据同步中,需要采用Raft算法的基本原理进行数据同步。

    编目节点和数据节点在存储数据时,共包含两大部分,一个真实的数据文件,另一个是事务日志文件。
    在这里插入图片描述
    SequoiaDB的节点事务日志,默认情况下由20个64MB(总大小为1.25GB)的文件构成。节点的事务日志主要包含一个index编号和数据操作内容,index编号保持永远递增状态。

    另外,SequoiaDB节点的事务日志不会永久保存,而是当所有的事务日志写满后,再重新从第一个文件开始进行覆盖写入。

    3.2 编目分区组的数据一致性

    由于编目分区组是保存SequoiaDB集群的元信息,数据同步要求高,所以编目分区组的数据一致性要求为强一致性,即每次向编目分区组执行事务操作时,必须要确保所有的编目节点操作成功,才计算该操作执行成功,否则该事务操作将在整个编目分区组中回退事务日志,以保证分区组内的数据一致性。

    另外,编目分区组还有一个比较重要的特性,即编目分区组必须要存在主节点才能够正常工作,如果老的主节点宕机了,编目分区组暂时没有主节点,则该编目分区组不能够对外提供任何事务操作和数据查询操作。

    3.3 数据分区组的数据一致性

    数据分区组的数据一致性默认情况下为最终一致性性,即只要求主节点执行事务操作成功即视为操作成功,主节点将在未来异步同步ReplicaLOG到从节点上。

    3.4 主从节点的事务日志同步

    SequoiaDB的主从节点是通过事务日志同步来保证数据一致性的,并且主从节点的事务日志同步是单线程完成。

    如果当主节点和从节点的LSN差距为一条记录,则主节点会主动将最新的事务日志推送给从节点。

    如果主节点和从节点的LSN差距超过一条记录,则从节点会主动向主节点请求同步事务日志,主节点收到同步请求后,会将从节点的LSN号到主节点最新的LSN号对应的事务日志打包一次性发送给从节点。

    3.5 从节点日志重放

    当从节点获取到主节点推送过来的事务日志后,就会自动解析事务日志和重放。从节点在重放事务日志时,默认情况下会以10并发来重放事务日志。

    从节点在执行并发重放日志时有条件限制,即在集合的唯一索引个数<=1的情况下,INSERT、DELETE、UPDATE、LOB WRITE、LOBUPDATE、LOB REMOVE操作可以支持并发重放事务日志。从节点在做并发重放时,是通过记录的OID进行打散并发执行,这样就可以保证对相同记录的操作不会由于并发重放导致数据不一致。

    但是用户需要注意,从节点在重放事务日志时, DROP CL操作不能够支持并发重放。

    4、SequoiaDB数据一致性应用

    目前SequoiaDB数据分区组的数据一致性是基于集合级别进行配置的。用户在使用SequoiaDB过程中,可以随时调整数据一致性的强度。

    4.1 创建集合时指定

    在一个多副本的SequoiaDB集群中,集合默认的数据一致性行级别为“最终一致性”。用户可以在创建集合时显式指定该集合的“数据一致性强度”,例如可以在SequoiaDB Shell中执行以下命令

    db.CSNAME.createCL(“CLNAME”,{ReplSize:3})

    ReplSize参数填写范围
    在这里插入图片描述

    4.2 修改已经存在的集合

    如果集合在创建时没有设置“数据一致性”ReplSize参数,用户也可以对已经存在的集合进行修改,在SequoiaDB Shell修改命令如下

    db.CSNAME.CLNAME.alter({ReplSize:3})

    ReplSize的取值范围和创建集合时一致。

    4.3 如何查看集合的ReplSize参数

    如果用户希望检查当前集合的RepliSize参数值,可以通过数据库快照进行查看,在SequoiaDB Shell查看命令如下

    db.snapshot(SDB_SNAP_CATALOG,{}, {“Name”:null, “IsMainCL”:null,“MainCLName”:null, “ReplSize”:null})
    打印信息如下

    {

    “MainCLName”:“test.main2”,

    “Name”: “foo.bar2”,

    “IsMainCL”: null,

    “ReplSize”: null

    }

    {

    “IsMainCL”: true,

    “Name”: “test.main2”,

    “MainCLName”: null,

    “ReplSize”: null

    }

    {

    “Name”: “foo.tt”,

    “ReplSize”: 3,

    “IsMainCL”: null,

    “MainCLName”: null

    }

    5、总结

    分布式的数据库,通过Raft算法来确保在分布式情况上数据的一致性,并且编目分区组和数据分区组对数据一致性要求又有所不同,编目分区组始终要求的是数据在多副本请情况下数据强一致性,而数据分区组则可以由用户在创建集合时来执行数据一致性的强度,强度越高,数据安全性越好,但是执行的效率就会相对较差,反之依然。

    目前SequoiaDB在数据一致性场景上,用户的调整空间较大,可以根据不同的业务要求来调整数据一致性的强度,以满足业务或追求性能最优,或者数据最安全的技术要求。

    展开全文
  • 一致性hash算法

    千次阅读 2019-04-27 22:47:14
    一致性hash算法Hash算法的作用Hash算法的冲突一致性hash算法一致性hash算法的原理容错性虚拟节点 Hash 算法也叫做散列算法,他可以让任意长度的数据M映射成为长度固定的值H。 Hash算法的作用 Hash算法的第一个作用...
  • 分布式系统的一致性问题(汇总)

    万次阅读 多人点赞 2019-09-02 15:32:19
    保证分布式系统数据一致性的6种方案 问题的起源 在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性? 具体业务场景如下,比如一个业务操作,如果同时调用服务 A、B、C,需要...
  • Raft 一致性算法论文

    万次阅读 2019-05-17 09:52:13
    本篇博客为著名的 RAFT 一致性算法论文的中文翻译,论文名为《In search of an Understandable Consensus Algorithm (Extended Version)》(寻找一种易于理解的一致性算法)。 Raft 是一种用来管理日志复制的一致性...
  • 【算法】Hash一致性算法详解

    千次阅读 2015-10-21 15:25:16
    一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希(DHT)实现算法,设计目标是为了解决因特网中的热点(Hot spot)问题,初衷和CARP十分类似。一致性哈希修正了CARP使用的简 单哈希算法带来的问题,使得...
  • 一致性Hash算法

    千次阅读 2016-05-03 22:22:06
    一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希(DHT)实现算法,设计目标是为了解决因特网中的热点(Hot spot)问题,初衷和CARP十分类似。一致性哈希修正了CARP使用的简 单哈希算法带来的问题,使得...
  • 分布式一致性协议Raft & Paxos 简单 v.s. 完美
  • 而在互联网时代,一致性的含义远远超出了它原有的含义,在我们讨论互联网时代的一致性之前,我们先了解一下互联网时代的特点,互联网时代信息量巨大、需要计算能力巨大,不但对用户响应速度要求快,而且吞吐量指标也...
  • 而在互联网时代,一致性的含义远远超出了它原有的含义,在我们讨论互联网时代的一致性之前,我们先了解一下互联网时代的特点,互联网时代信息量巨大、需要计算能力巨大,不但对用户响应速度要求快,而且吞吐量指标也...
  • 最终一致性

    万次阅读 2012-05-14 22:11:45
    在全球范围构建可靠的分布式系统,需要在一致性和可用性之间进行权衡。   最终一致性 Eventually Consistent   作者: Werner Vogels Werner Vogels is vice president and chieftechnology officer at ...
  • 数据库中原子性,隔离性,一致性如何实现
  • 从本文开始,笔者将花三到四篇文章的篇幅,介绍Paxos算法。包括它的理论基础、基本实现、变种实现,其它保证最终一致性的算法,等等。
  • 一致性算法分析

    万次阅读 2018-01-18 14:25:47
    目的 :一致性算法的出现是为了解决一致性问题,一致性问题是指对于一组服务器(集群),给定一组操作,需要使用一种协议使得它们的结果最终达成一致,看起来好像是一台服务器一样。 作用 :一致性算法在构建可信赖...
  • 从本文开始,笔者将花三到四篇文章的篇幅,介绍Paxos算法。包括它的理论基础、基本实现、变种实现,其它保证最终一致性的算法,等等。
  • 从本文开始,笔者将花三到四篇文章的篇幅,介绍Paxos算法。包括它的理论基础、基本实现、变种实现,其它保证最终一致性的算法,等等。
  • 分布式系统一致性研究

    千次阅读 2014-09-22 19:50:23
    本文希望对分布式系统的一致性问题做一个综合性介绍,奈何笔轻心重,语无伦次。感谢eric的敦促,感谢shuai的感召,我尝试总结一下。这个草稿堆积了一段时间了,大家提点意见,我再更新。谢谢!
  • 数据一致性设计理念

    千次阅读 2018-07-17 13:20:11
    为了解决数据一致性的问题,业界常用的CAP、ACID、BASE等理论模型。 CAP原则 CAP是对强一致性(Consistency)、可用性(Availability)、分区容忍性(Partition Tolerance) 的一种简称。 强一致性:即在...
  • 如何保证分布式系统数据一致性

    万次阅读 2018-12-24 10:26:05
    面试的时候,面试官问到:选取你比较熟悉的项目,谈谈如何在做容灾负载的时候数据一致性问题,具体点比如你里面的派单,如何保证一个司机不在同一时间内接到两个订单,然后保证实时性?  一般的解决方案是在派单...
  • 区块链首先是一个分布式系统,中央式结构改成分布式系统,碰到的第一个问题就是一致性的保障。很显然,如果一个分布式集群无法保证处理结果一致的话,那任何建立于其上的业务系统都无法正常工作。 一致性问题 在...
  • 移动端UI一致性解决方案

    万次阅读 多人点赞 2020-11-26 20:00:21
    总第424篇2020年 第48篇外卖UI一致性项目是外卖UI设计团队与研发团队共建的项目,目的是改善用户端体验的一致性,提升多技术方案间组件的通用性和复用率,降低整体视觉改版带来的研发成...
  • 而在互联网时代,一致性的含义远远超出了它原有的含义,在我们讨论互联网时代的一致性之前,我们先了解一下互联网时代的特点,互联网时代信息量巨大、需要计算能力巨大,不但对用户响应速度要求快,而且吞吐量指标也...
  • 分布式下的数据一致性问题

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

    万次阅读 2018-10-06 14:29:54
    PCB布局基本原则 1、满足结构要求,包括PCB板的安装、PCB板的尺寸形状要求、PCB板对应的外围接口的位置等; 2、禁止在PCB板的禁布区布局和走线。 包括板缘、安装过孔或安装座孔等。通常为小于1mm。取0.5mm为宜。 ...
  • 分布式事务一致性

    千次阅读 2018-05-25 17:18:45
    人的地方,就江湖江湖的地方,就纷争问题的起源在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性? 具体业务场景如下,比如一个业务操作,如果同时调用服务 A、B、C,...
  • 摘要:本篇文章是【区块链之技术进阶】的第七篇文章,在之前的文章中咱们多多少少提及了共识算法等相关知识,但是却没有具体地更加深入地了解,本文就为大家掰一掰区块链共识机制与分布式一致性算法,两者究竟什么...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 208,543
精华内容 83,417
关键字:

一致性原则有哪些基本要求