分布式理论:拜占庭将军问题

分布式理论:拜占庭将军问题

介绍

拜占庭将军问题是对分布式共识问题的一种情景化描述,由兰伯特于1082首次发表《The Byzantine Generals Problem》中提及,它是分布式领域最复杂的一个容错模型, 它描述了如何在存在恶意行为的情况下使分布式系统达成一致,了解拜占庭问题对于掌握分布式共识问题具有深刻意义。

拜占庭将军的故事

拜占庭帝国的几只军队此时驻扎在敌人的城墙之外,每个军队都有专门的将军来指挥,但因为各只军队分别驻扎在敌城的不同地方,将军之间只能通过信使来相互联系。再某天观察完敌情之后,将军们决定制定一个共同的作战计划,同时进攻或者撤退,因为敌人非常强大,至少有半数的军队同时发动进攻时才能取得胜利。此时,将军们遇到了难题:如何统一大家的作战计划?

将军的难题

首先,如果将军之间都是忠诚于拜占庭帝国的,那么很容易统一作战方案,只需要所有的将军之间彼此通信交换自己的意见(进攻还是撤退),最后所有的将军根据 少数服从多数 的原则来行动。

这里假设只有三支军队A, B, C, 其中 A, B 认为应该进攻,C认为应该撤退,将军之间的通信如下:
进攻 进攻 撤退 进攻 撤退 进攻 A B C

通过协商,所有的将军最后的行为都是统一的进攻,于是大破敌城!

但是,如果有将军私通敌国,发送误导性的信息这样的共识协商还能保证作战计划统一吗?答案无疑是否定的,假设现在B将领是叛将,故意给A,C发送不一样的信息,情况会发生改变:
进攻 进攻 撤退 撤退 撤退 进攻 A B C

A看到的是,撤退:进攻 = 1 :2

C看到的是,撤退:进攻 = 2 :1

接下来,按照少数服从多数的原则,A会独自发动进攻,当然,最后会因为寡不敌众而被敌军消灭。可以看到,叛将通过发送误导信息,非常轻易的干扰了其他将军的作战计划,导致忠于拜占庭帝国的将军被逐一击败,这就是著名的两忠一叛难题。忠诚的将军该如何统一作战计划呢?

解决方案

兰伯特的论文除了提出拜占庭将军之外,也给出了两种解决拜占庭将军问题的算法

  • 口信消息型解决方案
  • 签名消息型解决方案

接下来,我会分别介绍这两种做法,如果你觉得逻辑有点绕的话,建议找张纸比划比划。

口信消息型拜占庭问题之解

口信型拜占庭之解的核心是选择出一个指挥官和进行多轮信息协商。下面来介绍具体的协商流程:

流程

首先,我们假设现在有A, B, C, D四位将军,并且其中只有D为叛将。在这个解法之中,我们首先要选择出一个将军作为指挥官,其他的将军作为副将,这里我们先让忠诚的将领A作为指挥官,与先前的协商方式不同,在这个算法中,我们需要进行2次作战协商,接下来来看两次协商的流程:
第一轮:由指挥官向所有的副将发送作战信息,每位副官将从指挥官处收到的信息作为自己的作战指令;
进攻 进攻 进攻 A B C D

第二轮:三位副将之间进行作战信息协商,互相告知彼此指挥官发送的信息,其中,因为D是叛将,他会告诉两个将军不同的信息来误导他们
进攻 进攻 进攻 进攻 撤退 进攻 B C D A

可以发现,虽然叛将像先前一样向两个将军发送了不同的信息,但是B,C根据少数服从多数的原则,依旧可以做出和A一样的作战行为,最后大破敌军。

也许你会想,如果指挥官是叛将呢?情况会变回糟糕吗?答案是否定的,即使指挥官是叛将,所有的忠诚的将军依然可以统一作战行为,我们假设叛将D作为指挥官先发送作战信息, 他会发送误导的错误信息,试图让其中一位将领独自发动进攻:
进攻 撤退 撤退 D B C A

在第二轮的作战信息协商中,三位忠诚的副将彼此之间互通指挥官发送的消息:
进攻 进攻 撤退 撤退 撤退 撤退 B C A D

最终,所有的将军收到的作战信息都是"撤退,撤退,进攻",根据少数服从多数的原则,A, B, C将撤退,达成统一的行为,保证了作战计划的一致性。

总结

这个算法虽然可以保证无论叛将如何捣乱,我们都能做出一行的行为,但是这是有前提的。在兰伯特的论文中指出:如果叛将人数为m,将军人数不能少于3m+1,只有这样,口信型拜占庭将军之解才能生效。或者说,这个算法对于能容忍的叛将数m是已知的,而且m决定了要执行多少次作战协商,即 m + 1 轮(现在你知道为什么三忠一叛的场景中为什么我们要进行两次作战协商了)。该结论具体的推导,可以参考论文。

但是我们还是没能解决两忠一叛的问题,因为忠诚的将军数量不够,此时就可以考虑第二种拜占庭问题的解法了。

签名消息型拜占庭问题之解

签名消息型拜占庭问题之解的核心是信息要格外实现以下两个特性

  • 将军的签名信息无法伪造,对其签名信息的内容进行任何的修改都会被发现
  • 任何将军都能能力验证将军签名信息的真伪

这样,两忠一叛难题就能够被解决了,在这种算法下,需要指挥官首先发动作战协商,然后其余的将军彼此交换指挥官带来的消息。我们以A, B 为忠诚将军,C为叛将来推导解释:

首先假设A为首先发送信息的指挥官:
进攻 进攻 A:进攻 A:撤退 A B C

因为将军的签名信息的伪造会被发现,所以B收到C的作战请求的时候,会发现A的作战请求已经被C修改,B会执行A直接发送给他的进攻命令,大破敌军。

如果是叛将C先发送作战信息,结果也不会改变:
进攻 撤退 C:进攻 C:撤退 C B A

A, B在进行协商后会发现C给两人发送的作战信息不一致,此时可以先处理叛将,再重新制定作战计划。

总结

现在让我们回到计算机世界的分布式场景中:

  • 拜占庭的将军,代表着计算机节点,
  • 忠诚的将军指的是正常运行的计算机节点
  • 叛变的将军可以认为是出现故障,并且会发送误导信息的计算机节点

这样你是否理解了拜占庭将军问题代表的计算机分布式场景问题呢?实际上以上提到的两种算法还能解决如下的问题:信使被杀或者信使被间谍替换等。

这里强调一下,拜占庭将军问题强调的几乎是最困难也最复杂的一种分布式故障场景,计算机节点不仅存在故障,甚至还存在恶意行为,对于存在恶意节点的场景中,我们必须使用拜占庭容错算法。

相关推荐
明达技术1 小时前
物联优化汽车齿轮锻造
分布式·物联网
龙哥·三年风水4 小时前
群控系统服务端开发模式-应用开发-前端框架
分布式·vue·群控系统
WX1870211287313 小时前
在分布式光伏电站如何进行电能质量的治理?
分布式
不能再留遗憾了16 小时前
RabbitMQ 高级特性——消息分发
分布式·rabbitmq·ruby
茶馆大橘16 小时前
微服务系列六:分布式事务与seata
分布式·docker·微服务·nacos·seata·springcloud
材料苦逼不会梦到计算机白富美19 小时前
golang分布式缓存项目 Day 1
分布式·缓存·golang
想进大厂的小王19 小时前
项目架构介绍以及Spring cloud、redis、mq 等组件的基本认识
redis·分布式·后端·spring cloud·微服务·架构
Java 第一深情19 小时前
高性能分布式缓存Redis-数据管理与性能提升之道
redis·分布式·缓存
ZHOU西口21 小时前
微服务实战系列之玩转Docker(十八)
分布式·docker·云原生·架构·数据安全·etcd·rbac
zmd-zk21 小时前
kafka+zookeeper的搭建
大数据·分布式·zookeeper·中间件·kafka