理解分布式一致性:拜占庭容错与PBFT

简介: 理解分布式一致性:拜占庭容错与PBFT

理解分布式一致性:拜占庭容错与PBFT



之前的几篇文章我们讲了分布式协议里面的Paxos协议和Raft协议。这两个协议主要适用于可信节点的情况,所谓可信节点就是节点只会出现因为系统或者网络问题的宕机情况,不会有恶意节点。


那么如果有恶意节点的情况下,我们怎么去达成共识呢?一个很简单的办法就是少数服从多数,下面我们看一下拜占庭是做的。


拜占庭问题


先看一下我们要解决的问题,也叫做拜占庭将军问题。


话说有一天有n个拜占庭将军相约于魔法师大峡谷中,他们的目标就是推掉对方的塔。塔有点强大,只有不少于m个将军同时去推塔才能成功,如果一个一个的去推塔,就免不了身死道消的结果。那时候他们的微信版本还比较低,不能建群聊天,只能一对一的通信。

将军之间并不是表面上看起来的一条心,假如一个将军想组织大家在下午两点钟去偷塔,那需要怎么样操作才能保证不少于m个将军同时执行”两点钟偷塔“这个命令呢?


这个问题就叫做拜占庭将军问题,是指在不可信任环境下的分布式一致性问题。


这里我想强调一点,分布式一致性是指各个节点之间的数据同步一致,跟数据正确与否没有关系。


拜占庭容错BFT


拜占庭容错是分布式协议的一种属性,如果这种协议可以解决不可信任环境下的分布式一致性问题,那么它就是拜占庭容错。


PBFT(Practical Byzantine Fault Tolerance)


PBFT是拜占庭容错的一种实现。它的性能很高并且低延时,能够解决不信任节点的问题。


其有如下几个特征:


1. 同一时间只有一个Leader向外发送消息,其它节点只是被动接收消息。


2. 所有的节点互相之间通信,并且将其收到的消息转发给其他节点,从而达成多数共识。


3. 节点之间的消息需要保证:A:节点收到的消息确实是某个节点转发的。B:消息在发送过程中不会被篡改。


image.png


如果想让PBFT正常工作,那么恶意节点个数不能大于总节点个数的1/3。


正常来讲,节点个数越多,恶意节点所占有的比率就会越低,系统就会越稳定,但是因为所有的节点之间需要两两通信,节点个数的增多会带来节点之间通信的压力。


下面看下PBFT的工作流程:


  1. 客户端发给服务器说我要执行命令A。
  2. Leader将该命令分发给所有被动节点。
  3. 客户端收到f+1(f 是系统能够承受的最大恶意节点个数,即系统总节点个数为3f+1)个相同的结果,那么客户端即认为共识完成。


这里Leader是随机选择出来的,如果选出来的Leader在给定的时间内并没有发出广播,那么系统会自动挑选新的Leader并进入下一轮。


why 3f+1 ?


很多同学可能不理解为什么对于f个恶意节点来说,至少要3f+1个节点才能正常工作。这里给大家解释一下。


之前在Paxos和Raft协议里面,我们给大家讲过在可信任节点的环境里面,达成共识的条件是收到的消息需要>n/2 ,即要收到大多数节点的反馈才能表示共识完成。


那么在有不可信节点f的情况下,我们的可信任节点个数是n-f个,我们收到的可信任节点个数的反馈必须>(n-f)/2才表示绝大多数可信任节点已经收到消息了。同时我们也可能收到f个不信任节点发来的消息,那么当(n-f)/2 > f 的时候,根据多数原则,我们可以区分出哪些是信任消息,哪些是不可信任消息,因此得出 n> 3f .


PBFT 的优点


  1. 一致性结果一旦产出,不会更改。在区块链世界,像是比特币,以太坊,经常会听到区块确认的概念,这个就是结果不确定的问题,他们用的POW算法是以链的长度来决定最终的区块,当有更长的链产生的时候,之前的交易会被完全推翻。而PBFT不会存在这个问题


  1. 相对于POW,PBFT对能源的消耗会少很多很多,再也不用浪费资源去挖坑了。


PBFT 的缺点


说完优点说缺点。其实前面我们也提到了,PBFT需要节点之间两两通信,当节点个数太多的话,节点之间通信的消耗会大大增加。所以PBFT只适合用在联盟内部少数节点的情况。像是Hyperledger这样的联盟链。


同时,PBFT也可能会受到女巫攻击(Sybil attack),这个后面我们有时间再单独讲。


相关文章
|
11月前
|
数据采集 监控 NoSQL
优化分布式采集的数据同步:一致性、去重与冲突解决的那些坑与招
本文讲述了作者在房地产数据采集项目中遇到的分布式数据同步问题,通过实施一致性、去重和冲突解决的“三板斧”策略,成功解决了数据重复和同步延迟问题,提高了系统稳定性。核心在于时间戳哈希保证一致性,URL归一化和布隆过滤器确保去重,分布式锁解决写入冲突。
556 2
 优化分布式采集的数据同步:一致性、去重与冲突解决的那些坑与招
|
11月前
|
消息中间件 运维 监控
《聊聊分布式》BASE理论 分布式系统可用性与一致性的工程平衡艺术
BASE理论是对CAP定理中可用性与分区容错性的实践延伸,通过“基本可用、软状态、最终一致性”三大核心,解决分布式系统中ACID模型的性能瓶颈。它以业务为导向,在保证系统高可用的同时,合理放宽强一致性要求,并借助补偿机制、消息队列等技术实现数据最终一致,广泛应用于电商、社交、外卖等大规模互联网场景。
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
689 61
|
存储 调度
分布式锁设计问题之云存储的最佳实践中保障分布式锁的容错能力如何解决
分布式锁设计问题之云存储的最佳实践中保障分布式锁的容错能力如何解决
322 0
|
设计模式 监控 Java
分布式系统架构4:容错设计模式
这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。
602 12
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
870 12
|
存储 缓存 负载均衡
一致性哈希:解决分布式难题的神奇密钥
一致哈希是一种特殊的哈希算法,用于分布式系统中实现数据的高效、均衡分布。它通过将节点和数据映射到一个虚拟环上,确保在节点增减时只需重定位少量数据,从而提供良好的负载均衡、高扩展性和容错性。相比传统取模方法,一致性哈希能显著减少数据迁移成本,广泛应用于分布式缓存、存储、数据库及微服务架构中,有效提升系统的稳定性和性能。
920 1
|
消息中间件 缓存 算法
分布式系列第一弹:分布式一致性!
分布式系列第一弹:分布式一致性!
597 0
|
算法 Java 关系型数据库
漫谈分布式数据复制和一致性!
漫谈分布式数据复制和一致性!
341 0
|
Oracle 关系型数据库
分布式锁设计问题之Oracle RAC保证多个节点写入内存Page的一致性如何解决
分布式锁设计问题之Oracle RAC保证多个节点写入内存Page的一致性如何解决
509 0

热门文章

最新文章