网站首页 > 技术文章 正文
分布式系统的模型
为了更容易理解分布式系统,我们先来构建一个模型。
- 武当派因为人口增长变成 11 个办事处分散在地图各地;
- 办事处之间的通信只能依靠信鸽;
- 一只信鸽可能无法完全覆盖所有办事处,需要有中继村落代为传输消息。
太极拳大会的举办权不仅会为武当派带来巨大收益同时也会为办事处带来很多好处,为了产生合理的举办者,人们约定了几条规则:
- 大会举办权从 A 和 B 两个办事处中产生,他们每一届都是候选;
- 投票时所有办事处仅能投 A 或 B;
- 用投票的方式产生举办者,少数服从多数。
所有办事处会为了举办权都会使出浑身解数,比如延迟发送投票结果、篡改别人的投票结果、假装没有接收到通知等等。
其实这是一个典型的分布式系统,可以看成是我们简化版的区块链网络环境,那么这个分布式系统会遇到什么样的问题呢?
分布式系统面临的问题
分布式系统面临了几个问题:一致性问题,可终止性问题、合法性问题。
可终止性可以理解为系统必须在有限的时间内给出一致性结果,合法性是指提案必须是系统内的节点提出。当然其中面对的最重要也是最基础的问题,就是我们常说的一致性问题。
一致性是指在某个分布式系统中,任意节点的提案能够在约定的协议下被其他所有节点所认可。
需要提醒你区分的一点是:这里的“认可”表示所有节点对外呈现的信息一致,而不是对信息的内容认可。
我们回到上面的例子,我们提到了所有的办事处只能投 A 或 B,其实这个投票的动作可以理解为提案。
在“投票过程被大家所认可”这个语境下,“被大家所认可”表示某个办事处投票的结果已经被记录,用于最后统计结果,而不是认可投给 A 或者投给 B,这也是我在上述强调你要注意区分的一点。
一致性体现在那里呢?
非人为恶意的意外投票过程。 非人为恶意篡改可归类为信鸽半路挂掉、信鸽迷路、信鸽送错目的地、信鸽送信途中下雨导致信件内容模糊、接收信件的人不在家、天气变化信鸽延迟送达等等。这些对应到分布式系统面临的问题就是:消息丢包、网络拥堵、消息延迟、消息内容校验失败、节点宕机等。
人为恶意篡改投票过程。 人为恶意篡改包括“精神分裂式投票”,中继篡改上一个办事处的投票信息。对应到分布式系统面临的问题就是:消息被伪造、系统安全攻击等等。发生的人为恶意篡改的过程就可以称之为系统发生了拜占庭错误(Byzantine Fault),如果系统可以容忍拜占庭错误而不至于崩溃,也就是在发生系统被恶意篡改的情况下仍然可以达成一致,我们将这样系统称作为做拜占庭容错系统。
有关分布式系统的定理
- 第一个是 FLP 不可能性,简单来说是:即使网络通信完全可靠,只要产生了拜占庭错误,就不存在一个确定性的共识算法能够为异步分布式系统提供一致性。换句话来说就是,不存在一个通用的共识算法可以解决所有的拜占庭错误。
- 第二个是 CAP 定理,CAP 定理是分布式系统领域最重要的定理之一,这个我们在“理解区块链的常见误区”一文中稍微讲到过。也就是在设计分布式系统的过程中,“一致性”“可用性”“分区容忍性”三者中,我们只能选择两个作为主要强化的点,另外一个必然会被弱化。
我们由 CAP 定理可以推导出严格一致性和最终一致性。严格一致性是指在约定的时间内,通常是非常短、高精度的时间内,系统达到一致性的状态,这种系统很难实现,即使实现也很难有高的性能。
可用性其实是传统技术后端架构上非常重要的指标,从单点到主备模式、从主备模式到异地多活,再到现在的 Paxos 和 Raft 协议。
分区容忍性在企业内部极少出现,尤其是中心化的服务性应用,所以很少考虑。然而区块链的 P2P 网络环境十分复杂,所以必须要保证很高的分区容忍性。
共识算法与分布式一致性算法
经典的分布式一致性算法
经典分布式一致性算法有 Raft 协议,Raft 协议是一种强 Leader 的一致性算法,它的吞吐量基本就是 Leader 的吞吐量,它无法抵御节点恶意篡改数据的攻击。
稍微复杂一点的就是 Paxos 协议,Paxos 能提供不同场合不同种类的一致性算法,所以 Paxos 有很多变种,经典 Paxos 是 Leaderless 的,有变种是强 Leader 型的,叫做 Fast Paxos。
以上两种都是不提供拜占庭容错的系统,下面介绍一种具有拜占庭容错的一致性算法。
区块链共识算法
区块链的共识算法,我在某些场合直接称作基于经济学的博弈算法,以区别于经典分布式一致性算法思路,它的整体思路就是让攻击者的攻击成本远远大于收益。
区块链中的共识算法目前具有工业成熟度的是 PoW,另外两种比较成熟的是 PoS 和 DPoS,其次还有一些变种和单一币种使用的共识算法。
在使用 PoW 共识算法的情况下,容错阈值是 50%,而 PBFT 及其变种的容错阈值是 33% 左右,这里的百分比是指作弊节点占全网节点的比例。
PoX 类的算法其实都延续了 PoW 的设计理念,相比较经典分布式一致性算法,PoX 类算法通过概率选择记账者降低了潜在的提案者,另外是延长了达成最终一致性的时间。
猜你喜欢
- 2024-10-30 不同编程语言的运行差距有多大? 不同编程语言的特点
- 2024-10-30 纪念纳什 | 如何用“纳什均衡”约约约?
- 2024-10-30 算法练习题——纸牌博弈 博弈论纸牌游戏
- 2024-10-30 [算法学习Day160]除数博弈-博弈论-奇数与偶数性质
- 2024-10-30 笔试题:了解穷举算法吗?如何用代码实现
- 2024-10-30 运营和算法之间的几次博弈 运营是方法还是思维
- 2024-10-30 突破!人工智能在游戏领域再进一步
- 2024-10-30 人工智能在游戏领域再进一步 人工智能游戏用到的主要技术错误的是
- 2024-10-30 清华大学研究成果:如何用博弈论解决自动驾驶路口的会车决策问题?
- 2024-10-30 聊聊博弈论中巴什博奕问题的必胜策略
你 发表评论:
欢迎- 最近发表
-
- 在 Spring Boot 项目中使用 activiti
- 开箱即用-activiti流程引擎(active 流程引擎)
- 在springBoot项目中整合使用activiti
- activiti中的网关是干什么的?(activiti包含网关)
- SpringBoot集成工作流Activiti(完整源码和配套文档)
- Activiti工作流介绍及使用(activiti工作流会签)
- SpringBoot集成工作流Activiti(实际项目演示)
- activiti工作流引擎(activiti工作流引擎怎么用)
- 工作流Activiti初体验及在数据库中生成的表
- Activiti工作流浅析(activiti6.0工作流引擎深度解析)
- 标签列表
-
- oraclesql优化 (66)
- 类的加载机制 (75)
- feignclient (62)
- 一致性hash算法 (71)
- dockfile (66)
- 锁机制 (57)
- javaresponse (60)
- 查看hive版本 (59)
- phpworkerman (57)
- spark算子 (58)
- vue双向绑定的原理 (68)
- springbootget请求 (58)
- docker网络三种模式 (67)
- spring控制反转 (71)
- data:image/jpeg (69)
- base64 (69)
- java分页 (64)
- kibanadocker (60)
- qabstracttablemodel (62)
- java生成pdf文件 (69)
- deletelater (62)
- com.aspose.words (58)
- android.mk (62)
- qopengl (73)
- epoch_millis (61)
本文暂时没有评论,来添加一个吧(●'◡'●)