企业网站上线,wordpress tag 数据库,上海企业网站设计公司电话,做集团网站拜占庭将军问题 叛将先发送消息 如果是叛将楚先发送作战消息#xff0c;干扰作战计划#xff0c;结果会有所不同吗#xff1f; 在第一轮作战信息协商中#xff0c;楚向苏秦发送作战指令进攻,向齐、燕发送作战指令撤退#xff0c;如图所示(当然还…拜占庭将军问题 叛将先发送消息 如果是叛将楚先发送作战消息干扰作战计划结果会有所不同吗 在第一轮作战信息协商中楚向苏秦发送作战指令进攻,向齐、燕发送作战指令撤退如图所示(当然还有其他情况这里指示选择了其中一种大家也可以尝试推导其他的情况看看结果是不是一样). 然后在第二轮作战信息协商中,苏秦、齐、燕分别作为指挥官将接收到的作战信息附加上自己的签名并转发给另外两位如图所示。为了达到干扰作战计划的目的叛将楚和燕相互勾结了。比如燕拿到了楚的私钥也就是燕可以伪造楚的签名此时燕为了干扰作战计划给苏秦发送作战指令进攻给齐发送作战指令撤退 接着在第三轮作战信息协商中苏秦、齐、燕分别作为指挥官将接收到的作战信息附加上自己的签名并转发给另外以为如图所示 最终苏秦和齐接收到的左闸内心戏都是撤退、进攻按照执行盒子最中间的指令的约定苏秦、齐和燕一起执行作战指令撤退实现了作战计划的一致性。也就是说无论叛将楚和燕如何捣乱苏秦和齐都能执行一致的作战计划保证作战的胜利。需要注意的是签名消息的拜占庭问题之解也是需要进行m1轮(其中m为叛将数即如果只有楚、燕是叛变的,那么就进行3轮)协商。我们也可以从另外一个角度理解:n位将军能容忍(n-2)位叛将(只有一位忠将没有意义因为此时不需要达成共识)。另外签名消息型拜占庭问题之解解决的是忠将们如何就作战计划达成共识的问题也即只要忠将们执行了 一致的作战计划就可以了它不关心这个共识是什么比如在适合进攻的时候忠将们可能执行的作战计划是撤退也就是说这个算法比较理论化。关于这一点这个算法解决的是共识问题没有与实际场景结合是很难在实际场景中落地的。在实际场景中可以考虑改进后的拜占庭容错算法比如PBFT算法 拜占庭容错算法和非拜占庭容错算法,应该如何选择呢 为了帮助大家理解拜占庭将军问题前面讲了苏秦协商作战的故事现在让我们跳回到现实世界回到计算机世界的分布式场景中: 1.故事里的各位将军可以理解为计算机节点2.忠诚的将军可以理解为正常运行的计算机节点3.叛变的将军可以理解为出现故障并会发送误导信息的计算机节点4.信使被杀可以理解为通信故障、信息丢失5.信使被间谍替换可以理解为通信被中间人攻击攻击者在恶意伪造信息和劫持通信 需要注意的是拜占庭将军问题描述的是最困难也是最复杂的一种分布式故障场景该场景除了存在故障行为还存在恶意行为。在存在恶意行为的场景中(比如在数字货币的区块链技术中)我们必须使用拜占庭容错算法还有PBFT算法、POW算法。在计算机分布式系统中最常用的是非拜占庭容错算法即故障容错(Crash Fault Tolerance, CFT)算法。 CFT算法解决的是分布式系统中存在故障但不存在恶意节点的场景下的共识问题。也就是说这个场景可能会丢失消息或者有消息重复但不存在错误消息或者伪造消息的情况常见的CFT算法有Paxos算法、Raft算法、ZAB协议。那么如何在实际场景中选择合适的算法类型呢如果能确定该环境中各节点是可信赖的不存在篡改消息或者伪造消息等恶意行为(例如DevOps环境中的分布式寻址系统)推荐使用非拜占庭容错算法; 反之则推荐使用拜占庭容错算法例如区块链中使用Pow算法