The Byzantine Generals Problem

问题描述

参考维基百科：拜占庭将军问题

投票

Situation1

A:1，B:1，C:0

A收到的指令1和0的比例为：2：1

B收到的指令1和0的比例为：2：1

C收到的指令1和0的比例为：2：1

投票结果执行1指令

Situation2

A:0，B:1，C:0

A收到的指令1和0的比例为：1：2

B收到的指令1和0的比例为：1：2

C收到的指令1和0的比例为：1：2

投票结果执行0指令

Situation3

A:0，B:1/0，C:1

A收到的指令1和0的比例为：2：1

B(故障节点)

C收到的指令1和0的比例为：1：2

投票结果A执行1指令，C执行0指令，产生了不一致

解决办法一：口信消息型拜占庭问题之解

TODO

加密签名防篡改版

Situation4

A:1,B:BAD,C:1

A:执行1指令

B:bad节点

C:执行1指令(发现被篡改指令，执行A指令)、

投票结果执行1指令,

Situation4

B:BAD,A,0,C:1

A,C: 发现来自B的信息不一致，被篡改，删除B并重新投票.

CAP

在分布式系统中由于分布式的特性和网络延迟和故障的存在以及在不同业务情况下的不同要求等等。。于是催生了CAP的概念。

CAP?

Consistency: 表示分布式系统中的一致性，在客户端访问分布式系统中的不同节点时要么返回相同的返回值，要么不返回数据。
Availability: 表示可用性，在分布式系统中如果出现不同节点间的数据不一致的情况，为了保证不会出现不返回数据的情况，各个节点返回的数据可能会不一致。但重在每个节点都能返回数据。
Partition Tolerance: 分区容错性旨在保证系统的容错能力，在不同节点间可能会出现各种故障，为了保证不管系统内部出现什么问题，任然保证系统能够继续提供服务。

示意图

CAP 不可能三角

对于一个分布式系统而言，这三个指标是不可兼得的，在CA两者之间必须根据实际的业务特点选择一个。在任何系统中P这个指标是必须选择的，因为无论如何都要保证系统不能挂掉，否则无论什么选择都将毫无意义。

CP组合

如果选择了C意味着如果因为节点间消息丢失，网络延迟导致分区时，部分节点可能无法保证数据最新时，集群中就会出现拒绝写请求。

AP组合，在选择了A的时候，系统将会以响应客户请求为主，如果发生了节点间故障，即使无法返回最新的数据，各个节点也会把当前系统最新值返回给客户端.

CP模型的典型：ZooKeeper, Etcd和Hbase

AP: …

TPC

two phrase commit: 两阶段提交，在分布式环境中为了保证数据一致性C(Consistency),TPC产生了，其将事务的完全提交分为两个阶段：

prepare阶段
commit阶段

过程解析

Client 发送变更请求到TC,Transaction Coordinator 在这里扮演着leader的职责，负责收集各个节点的响应和下达命令到各个节点。
TC 通知各个业务节点进入prepare阶段（两阶段提交中的第一阶段）
业务节点判断是否可以正常执行业务，并返回判断结果给TC.
TC收集各个节点的判断结果，并根据最终结果发出rollback还是commit的指令给各个节点进行确认parepare的准备工作（两阶段提交中的第二阶段）.

prepare阶段要求节点的变更是持久化的，不论在tc和服务节点之中任何节点出现了问题，都要求在被修复后的节点可以通过持久化的记录来使业务数据保证一致的状态。

TC的第二阶段指令也需要持久化，在发生节点发生故障时，修复后可以通过询问tc服务节点获取最终应该执行的指令以保证服务的一致性。

在第四步中如果有任何一个节点的prepare返回的是no,tc都会下发rollback指令，

由于在第一阶段和第二阶段之间还会产生数次通信，存在延时锁定资源的弊端，为了解决这个问题，就出现了TCC

TCC(Try-Confirm-Cancel）

Try、Confirm、Cancel 包含了两个阶段Try和Confirm或者Cancel。

同理tcc也是为了保证节点间的数据具有一致性，举例说明其实现原理：

网上购物场景，假设设计的场景有：订单服务（更新订单状态）、库存服务（减库存）、积分服务（增加积分）

正常工作流程如下：

为了保证以上这些服务能够保持数据的一致性，这些节点要么全部成功，要么全部失败。如果在上述途中发生了库存服务不足的情况，就需要库存服务通知其他服务来回滚刚才操作，这里开始引入TCC

TCC

Try:

在无法确认所有服务都能完成正常操作之前，先将需要使用到的资源进行预留操作，如下所示：

T阶段：

在这一步不会先把所有的操作都落库，只是先对资源进行一次冻结

Confirm:

在上一阶段，如果所有的服务都能成功冻结资源，也就相当于确保了所有的服务都能正常处理这部分业务。获得了冻结成功的信息，可以通知各个服务将冻结资源和实际资源进行merge，完成确认操作。

Cancel:

如果在T阶段有服务无法完成资源的冻结操作，如下所示：

在得知store service无法完成扣将库存操作时，按照tcc机制，要求通知所有服务回滚T操作

在感知各个服务能否正常工作时，需要提供专门的TCC框架，可以自己写（如果有能力），一般会引入现有一些开源框架，例如： yteTCC，TCC-transaction，Himly等等…

分布式概念扫盲（Byzantine generals problem/CAP/TPC/TCC)相关推荐

拜占庭将军问题(The Byzantine Generals Problem)
注: 该博客后续将不再更新, 最新版本请见本人个人主页. 拜占庭将军问题(The Byzantine Generals Problem)提供了对分布式共识问题的一种情景化描述, 由Leslie Lam ...
关于“拜占庭将军算法”byzantine generals problem
一.拜占庭将军算法的背景: 对于系统坏掉的风险,可以这样假设:我们的操作员可能会误操作.可能会被贿赂或背叛,系统本身可能就有木马程序,系统可能会被黑客或病毒占领,我们自己开发的系统可能有漏洞,我们的开 ...
分布式系统–拜占庭将军问题(The Byzantine Generals Problem)
本文档作为分布式系统的学习基础,通过拜占庭问题取尝试先了解分布式系统里面可能存在的基础问题.拜占庭将军问题,主要为了解决在已知有成员不可靠的情况下,其余忠诚的将军需要在不受叛徒或间谍的影响下达成一致的 ...
拜占庭将军问题（Byzantine Generals Problem）
论文:Lamport L, Shostak R, Pease M. The Byzantine generals problem[M]//Concurrency: the works of lesli ...
The Byzantine Generals Problem 全文要点翻译及理解
题目:The Byzantine Generals Problem 年份:1982 来源:ACM Transactions on Programming Languages and Systems 作 ...
分布式概念-分布式系统是什么？
点击上方蓝色字体,选择"设为星标" 优质文章,及时送达故事从一次内部分享开始,我们每周组织组内分享,会分享一些技术,中间件,研发流程规范或者业务系统架构等内容,在进行了一系列中间 ...
SOA、ESB、微服务、分布式概念及专业名词阐述
SOA.ESB.微服务概念 1 SOA 面向服务 SOA全称:Service Oriented Architecture,面向服务框架.它是一种设计理念,其中包含多个服务,服务之间通过相互依赖最终提供 ...
谷歌新发布的分布式数据库服务，是要打破CAP定理了吗？
谷歌新发布的分布式数据库服务,是要打破CAP定理了吗? 本来来自:Original 2017-02-19 作者|登州知府 2月14日,Google 宣布推出 Cloud Spanner 云端数据库服务 ...
无人机高精度定位之——RTK与PPK概念扫盲
无人机高精度定位之--RTK与PPK概念扫盲无人机的兴起,已经让很多行业激动不已,如电力巡检.应急救援.测绘.农业植保等行业.而随着高精度卫星导航技术的加持,让无人机定位更加高效.安全.灵活,保证无 ...

分布式概念扫盲（Byzantine generals problem/CAP/TPC/TCC)