区块链|CAP原理[通俗易懂]

区块链|CAP原理[通俗易懂]分布式系统(distributedsystem)正变得越来越重要,大型网站几乎都是分布式的。分布式系统的最大难点,就是各个节点的状态如何同步。CAP定理是这方面的基本定理,也是理解分布式系统的起点。一、分布式系统的三个指标ConsistencyAvailabilityPartitiontolerance它们的第一个字母分别是C、A、P。EricBrewer说,这三个指标不可能同时做到。这个结论就叫做CAP定理。二、Partitiontolerance先看Parti

大家好,又见面了,我是你们的朋友全栈君。

区块链本质上是一个去中心化的点对点的分布式数据库,同时作为比特币的底层技术。

首先介绍分布式系统中的CAP原理。
分布式系统(distributed system)正变得越来越重要,大型网站几乎都是分布式的。
分布式系统的最大难点,就是各个节点的状态如何同步。CAP 定理是这方面的基本定理,也是理解分布式系统的起点。
在这里插入图片描述
一、分布式系统的三个指标

  • Consistency
  • Availability
  • Partition tolerance

它们的第一个字母分别是 C、A、P。
Eric Brewer 说,这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

二、Partition tolerance
先看 Partition tolerance,中文叫做”分区容错”。
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区(partition)。分区容错的意思是,区间通信可能失败。比如,一台服务器放在中国,另一台服务器放在美国,这就是两个区,它们之间可能无法通信。
图中,G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息,G2 可能无法收到。系统设计的时候,必须考虑到这种情况。
在这里插入图片描述
一般来说,分区容错无法避免,因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们,剩下的 C 和 A 无法同时做到。

三、Consistency
Consistency 中文叫做”一致性”。意思是,写操作之后的读操作,必须返回该值。举例来说,某条记录是 v0,用户向 G1 发起一个写操作,将其改为 v1。
在这里插入图片描述
接下来,用户的读操作就会得到 v1。这就叫一致性。

在这里插入图片描述

问题是,用户有可能向 G2 发起读操作,由于 G2 的值没有发生变化,因此返回的是 v0。G1 和 G2 读操作的结果不一致,这就不满足一致性了。
在这里插入图片描述

为了让 G2 也能变为 v1,就要在 G1 写操作的时候,让 G1 向 G2 发送一条消息,要求 G2 也改成 v1。
在这里插入图片描述
这样的话,用户向 G2 发起读操作,也能得到 v1。
在这里插入图片描述
四、Availability
Availability 中文叫做”可用性”,意思是只要收到用户的请求,服务器就必须给出回应。
用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器,只要收到请求,就必须告诉用户,到底是 v0 还是 v1,否则就不满足可用性。

五、Consistency 和 Availability 的矛盾
一致性和可用性,为什么不可能同时成立?答案很简单,因为可能通信失败(即出现分区容错)。
如果保证 G2 的一致性,那么 G1 必须在写操作时,锁定 G2 的读操作和写操作。只有数据同步后,才能重新开放读写。锁定期间,G2 不能读写,没有可用性不。
如果保证 G2 的可用性,那么势必不能锁定 G2,所以一致性不成立。
综上所述,G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性,那么无法保证所有节点的可用性;如果追求所有节点的可用性,那就没法做到一致性。

对于CAP原理比较直观的理解是,分布式存储系统中,最多能实现上面的两点。介于目前网络通讯情况来看,延迟丢包,网络中断,甚至是一些不可抗力导致网络失效等问题的存在,分区容忍性在没有特殊要求的前提下是我们一定要实现的。因此,我们只能在一致性和可用性之间进行权衡,选择一方,而舍弃或者部分舍弃另一方。

了解了CAP原理后,我们来看区块链系统。从区块链大规模应用的开始到今天,CAP原理同样适用于区块链技术,不过稍微有些区别。

目前已知的区块链项目中,没有能同时满足“完全去中心化”、“高效率低耗能”、“安全性”。在区块链应用的领域,通常人们首先考虑的就是“安全性”,对此也会提出较高的要求,因而设计一个区块链系统时需要在“完全去中心化”和“高效率低能耗”二者之间做出选择。

下面用实际案例来分析一下这两种情况:
1
选择“完全去中心化”,舍弃“高效率低能耗”:比特币的系统就是一种极致的“完全去中心化”和“安全性”的设计。
从数据结构上看,通过“区块+链”的结构,辅以时间戳,满足可溯源、防篡改的安全性要求,同时也易于其他节点同步数据。但是在对信息查询、验证的情境下,就需要对链进行遍历操作,虽然有数字摘要技术,我们不必“阅读”整条链上所有的信息,但是遍历仍是较为低效率的查询方式。
从数据存储上看,每一个节点都下载和存储所有数据包,使得整个系统会具有强容错、强纠错能力,网络得以民主自治,与此同时产生的是巨大的校验成本和存储空间消耗。比特币系统并不能像一般分布式系统随着节点的增加来提高存储能力,当交易量在一段时间内变得越来越多时,单个节点的存储空间将成为问题。
从并发处理上看,系统最终只允许一个 “矿工”获得记账权来打包一个交易区块,有效保证了网络运行的民主、安全和稳健,但其实质上对拥有所有数据的整个“链条”在进行串行的“写”操作。 与关系型数据库将数据分为若干表,仅仅操作数据相关的若干表或表中的记录、其他表仍能并发处理相比,比特币区块链技术的串行操作效率远低于普通数据库。

2
选择“高效率低能耗”、舍弃“完全去中心化”:在比特币的工作量证明(POW)共识之后,对“完全去中心化”做出一定的妥协,就有了权益证明(POS)、股份权益证明(DPOS)等共识机制。
无论是基于数字资产权益代表的权益证明,还是利用多名受委托人通过投票实现的股份授权证明
都会形成部分中心化,但是由于参与打包、验证区块的节点变少了甚至在信任的前提下可控,系统整体的效率会有质的提升,从而满足大部分应用场景。在完全舍弃“去中心化”后,就是私有链的组织方式了,效率和安全会得到极大的保证。
从市场反馈来看,DPOS是比较出色共识模式了,它让区块链系统的扩展性有了长足的提升。


总结一下

“完全去中心化”、“高效率低耗能”、“安全性”三者皆得的区块链技术目前还无法实现,CAP原理的存在,让基于分布式结构的区块链系统有了天然的残缺性。服务至上的时代背景下,在实际的应用场景中,我们设计一个区块链系统要考虑的是舍弃多少的“一致性”来获得达到我们需求的“可用性”。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/144467.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)
blank

相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号