。

它们的设计在系统中的角色分配、数据管理、协调方式等方面有所不同。

无中心节点架构#xff08;Decentralized/Peer-to-Peer

Architecture#xff09;

在无中心节点的分布式存储架构中#xff0c;所有节点都是…分布式存储架构可以分为无中心节点架构和有中心节点架构。

它们的设计在系统中的角色分配、数据管理、协调方式等方面有所不同。

无中心节点架构Decentralized/Peer-to-Peer

Architecture

在无中心节点的分布式存储架构中所有节点都是平等的没有单一的控制节点或协调器。

这种架构下的系统没有中心化的控制所有节点共同协作完成数据存储、查询和更新等操作。

对等P2P关系每个节点既可以存储数据也可以提供服务通常没有一个负责管理整个系统的中心节点。

高可扩展性由于没有中心节点系统可以通过增加更多节点来扩展存储能力和计算能力。

容错性好单个节点故障对整体系统的影响较小数据可以被复制到多个节点以确保高可用性。

去中心化协调节点通过分布式算法进行协调如DHT分布式哈希表和一致性协议如Raft、Paxos来管理数据。

系统协调复杂需要处理一致性、负载均衡等问题。

由于没有中心协调可能会导致一定的延迟。

代表技术

BitTorrent等P2P协议IPFSInterPlanetary

File

有中心节点架构中通常存在一个或多个中心节点Master/Coordinator来负责协调和管理整个系统的操作。

其他节点则作为从节点Slave负责存储数据或执行具体的任务。

主从结构中心节点负责全局管理比如元数据管理、节点状态监控、任务分发等。

普通节点负责数据存储和处理。

集中控制中心节点承担了更多的协调和决策任务因此系统管理较为集中。

一致性控制中心节点可以方便地控制数据的一致性和分布从而简化一致性协议的设计。

易于管理由于有中心节点数据的管理和调度相对简单。

数据一致性更容易维护中心节点可以集中处理一致性问题降低了节点间的复杂协调。

性能优化中心节点可以调度资源优化性能。

单点故障风险如果中心节点出现故障系统的协调和管理能力会受影响甚至会导致系统不可用。

扩展性受限中心节点需要处理较大的元数据或协调请求可能会成为扩展瓶颈。

代表技术

System使用Master节点管理文件系统元数据Ceph在运行有中心节点的模式下使用Monitor和Manager角色

无中心节点架构去中心化所有节点平等适合大规模扩展和分布式存储但协调更复杂。

有中心节点架构中心化协调管理方便但存在单点故障和扩展性问题。

一致性协议是在分布式系统中确保多个节点之间对共享数据达成一致的机制。

它们在分布式存储、数据库、区块链等系统中尤为重要尤其是在节点可能出现故障或网络分区的情况下。

Paxos协议

协议专注于在多个节点之间达成共识确保即使一些节点出现故障系统依然可以正常运行。

提议者Proposer提出提议希望在系统中就某个值达成一致。

接受者Acceptor接受提议并投票给提议的值。

只有当大多数接受者同意某个提议时该提议才会被确认。

学习者Learner学习最终被接受的值。

Paxos协议的设计相对复杂但它可以处理大多数网络分区和节点故障问题。

强一致性保证在网络或节点失效的情况下最终只有一个值被选定。

容错性强即使少数节点失败系统仍能正常工作。

实现复杂开发和维护成本较高。

在实际大规模生产环境中效率可能不如某些改进版协议高。

Raft协议

Leader领导者负责处理客户端请求并广播到其他节点。

Follower追随者仅接受领导者的命令。

Candidate候选者在选举过程中尝试成为新的领导者。

Raft

协议通过选举机制来选择领导者并通过日志复制的方式保证各个节点状态的一致。

易于理解和实现代码相对简单。

有效解决了分布式系统中的选主问题。

性能和可扩展性相对较好。

Paxos一样由于强一致性要求可能会有较高的延迟。

领导者选举可能导致短暂的系统不可用。

Zab协议

分布式协调服务设计的原子广播协议旨在为分布式系统提供高可靠性、高一致性的操作。

Raft其中也有

两阶段提交是一种较为简单的分布式事务协议用于协调多个节点在分布式事务中达成一致。

准备阶段Prepare

Phase协调者向所有参与节点发送准备请求询问它们是否可以提交。

提交阶段Commit

Phase如果所有节点都同意提交则协调者发送提交请求如果任何一个节点拒绝则发出回滚请求。

阻塞问题如果协调者在提交阶段崩溃系统会陷入阻塞状态直到协调者恢复。

不支持容错如果某个参与者在提交过程中崩溃系统可能无法继续进行事务。

三阶段提交3PCThree-Phase

三阶段提交是对两阶段提交的改进增加了一个“预提交”阶段以进一步减少阻塞问题。

CanCommit阶段协调者询问各节点是否可以执行事务。

PreCommit阶段如果所有节点都同意协调者发送预提交命令。

DoCommit阶段协调者发送最终提交命令。

相较于两阶段提交增加了预提交阶段减少了系统因协调者故障导致的阻塞问题。

仍然存在一定的复杂性且在网络分区的情况下可能无法解决一致性问题。

强一致性协议如

Paxos、Raft适用于对一致性要求极高的系统如分布式数据库、协调服务如

Zookeeper、etcd。

这些协议确保在故障情况下不会出现分歧但代价是性能可能受限。

两阶段提交、三阶段提交适用于分布式事务的场景如分布式数据库的事务提交虽然简单但阻塞问题仍然是其主要挑战。

Paxos

是分布式系统中常见的强一致性协议Raft相对更易理解和实现。

2PC

3PC

你是否想深入了解某个特定的一致性协议或者需要对其应用场景做进一步讨论呢

拜占庭问题Byzantine

Problem是分布式系统中的一个经典问题它描述了在不可靠或恶意节点存在的情况下如何让系统中的各个节点达成一致性。

这一问题引申出了拜占庭容错Byzantine

Fault

BFT的概念用来解决系统在恶意节点存在时仍然能够保证一致性和正确性的挑战。

拜占庭问题最早由计算机科学家

年提出。

问题的核心情景是一群拜占庭将军围攻一座城市他们需要共同决定是进攻还是撤退所有将军必须达成一致。

如果有部分将军选择进攻另一些将军选择撤退那么他们的进攻将失败且可能全军覆没。

然而通信并不可靠某些将军可能会背叛发送虚假的信息企图破坏整体决策。

恶意节点在分布式系统中某些节点可能因为软件故障、网络问题甚至是恶意攻击而表现不正常例如发送错误信息这些节点可能会通过错误或恶意的决策来破坏系统的一致性。

达成一致在这种不可靠的通信环境中如何确保所有忠诚的将军节点能够就同一个行动决定达成一致是拜占庭问题的核心挑战。

拜占庭容错BFT算法

为了解决拜占庭问题设计了一些拜占庭容错算法用于在不超过三分之一的节点表现异常包括恶意节点的情况下确保系统的可靠性和一致性。

以下是几种主要的拜占庭容错算法

PBFTPractical

预准备阶段Pre-prepare主节点Leader向其他副本节点发送请求开始进行共识。

准备阶段Prepare副本节点接收请求后向其他副本节点广播“准备”信息。

提交阶段Commit如果一个节点收到来自足够多2f12f

能够在不超过三分之一节点是恶意节点的情况下提供容错。

相比早期的拜占庭容错算法PBFT

PBFT

在大规模系统中不太高效。

需要信任某个初始的领导节点在某些情况下可能成为单点故障。

Tendermint

是一种基于拜占庭容错的共识算法广泛应用于区块链技术。

它是一种结合了拜占庭容错和

PoSProof

使用投票机制来选择共识中的领导者确保分布式系统在有限的时间内能完成交易验证。

它基于

f(N−1)/3f

是一种专为异步网络环境设计的拜占庭容错算法。

异步环境下消息传递的时间是不确定的无法保证消息在有限时间内送达这在传统拜占庭容错算法中是一个难点。

能够在异步网络中运行不依赖于定时器或网络的同步假设。

采用随机化技术来提高系统的公平性和安全性。

在异步网络环境中保持高安全性和容错能力。

尤其适合不确定性高的环境比如分布式金融系统。

Algorand

是一种创新的拜占庭共识算法特别用于区块链中。

它通过随机选择一小部分节点来进行共识决策从而大大减少了通信开销。

工作原理

通过加密的抽签随机选择一小部分节点负责达成一致决策而不是所有节点都参与投票。

这种方法有效地解决了拜占庭容错系统中的通信瓶颈问题。

极大减少了通信复杂度使其适合大规模区块链网络。

提供了高效的容错机制能够在不依赖于中心节点的情况下达成共识。

拜占庭容错应用场景

区块链拜占庭容错算法是区块链系统中共识算法的基础。

例如PBFT

被应用于Hyperledger

分布式金融系统金融系统对于安全性和一致性要求极高尤其是在异步网络环境下HoneyBadgerBFT

拜占庭问题

解决了分布式系统中存在恶意节点时的一致性挑战。

拜占庭容错BFT算法如

HoneyBadgerBFT在处理节点故障和恶意攻击时能够保证系统的一致性和安全性。

这些协议广泛应用于

区块链、分布式数据库