区块基础-容错Paxos
Posted 磨链mochain社区
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了区块基础-容错Paxos相关的知识，希望对你有一定的参考价值。
分布式容错
区块链，有一种理解为分布式统一账本，那么分布式的架构肯定会存在一个容错的问题。这里简单概述下容错相关内容。
分布式容错约定概念：
节点：在一个网络中，每一台终端计算机称为一个节点，传统架构中服务器客户端的模式，那么服务器也看作一个节点。
消息：网络中节点单独工作，协作在一块，需要一种机制，称为消息，也作为消息传递。
消息丢失：网络中不能保证所有消息都是能正常被传递和确认，这个原因是由于网络中的带宽、物理设备故障、恶意节点等原因，故无法保证所有的消息都是能正常传递和确认，那么必然存在消息丢失。
消息确认：在消息传递的过程中，接收消息的节点接收到消息后返回一个确认信息给发送节点。
消息传递序号：在消息发送过程中，为了防止重复发送的统一消息，在消息传递中加一个序列号。
状态复制：在分布式系统中，串形复制命令序列。
加锁：串行状态复制的时候，通过加锁的方式保证单一执行修改。
票：弱化形式的锁。检查服务节点状态，不对其进行加锁。
上述大致说明了一些分布式容错的约定概念。接下来简单介绍下一些协议。
分布式系统中的共识
分布式系统采用消息传递、反馈确认，那么假设一场对话（网络环境下点对点环境）：
网络传输
B：收到，明天下午2点一块打球，确认请回复
网络传输
A：收到，确认明天下午2点一块打球，收到请回复
网络传输
B：收到，确认回复
网络传输
。。。
其实这种需要确认的协议是无法终止的，因为存在下一阶段的确认回复，最后一次不能保证没有丢失。但是理论和工程是不一样的，设计一种考虑忽略最后一次确认消息，那么一种可容忍的协议。
这种协议这里称为“共识”，结合在分布式系统中，共识假设系统中有n个节点，允许最多有f个节点崩溃，那么正常工作节点就是n-f，认为系统中至少要有n-f个节点是正常的。
某一个节点发起请求x，那么在这样的环境中系统还是能达到最终一致。这个系统一致还要求三个条件：
一致性：所有正常节点输入确定值一致。
可终止：所有正常节点在规定时间内结束一轮抉择。
有效性：输入的确定值是由系统中某个节点发起。
理想化的两阶段协议
1.step-1
2.客户端发起请求至所有分布式的服务器
3.step-2
4.if
5.发起请求的客户端获得了所有的服务器的锁
6.then
7.客户端一次发送消息，结束后解锁
8.
9.else
10.客户端未获得所有服务器的锁
11.重新进入step-1
12.end
这是一个理想化的模式。类似数据库系统，第一阶段就是事务的准备阶段，第二年阶段就是提交或者回滚。
问题：
那么通过两阶段，出现节点故障的状态，那么请求无法完全，理想化的两阶段协议必须要求节点都正常，如果只是一部分服务器处于锁的状态，将无法正常完成整个过程。且客户端将无法判断服务器节点锁的状态，导致系统出现故障，问题：如何有效解决这种这种模式？
PAXOS
在票上加一个序列号，服务节点在收到票的时候记录票的序号，保证票不重复和本地记录的一致。通过超过半数的票来作为容错机制。
票协议：
step-1
客户端向所有节点发送带序号的票
step-2
if
客户端收到半数服务节点收到票的回复
then
客户端再次发起票，且加上命令消息一起发送给所有服务器
服务器节点收到消息，判断票有效性后，存储命令消息
服务器返回客户端信息
else
客户端等待，返回step-1
end if
step-3
if
客户端收到半数服务器的返回客户端消息
客户端通知所有服务器执行之前的命令
else
客户端等待，返回step-1
end if
这种票协议还是会出现服务节点存储本地票号，但是客户端在发起请求的时候票号会不一致，且命令存储会出现不一致。故再对这种模式进行改进。
PAXOS大致流程：
引入本地记录票号的计数、半数确认容错。
| 服务端 | 客户端 |
|---|---|
| 初始化 | 初始化 |
| 票号t=0、命令c | 票号Tmax=0、命令C、存储命令的票Tc |
| step-1 | step-1 |
| 发起请求、t=t+1，请求票号为t | |
| 服务节点判断：t>Tmax、那么Tmax=t，回复确认（Tc、C） | |
| step-2 | step-2 |
| 客户端如果收到半数服务节点回复确认、选择（Tc、C）验证Tc>0、那么c=C、发送消息p(t、c ) | |
| 服务节点收到p、判断t=Tmax、那么C=c、Tc=t、回复成功 | |
| step-3 | step-3 |
| 接收到半数以上服务节点回复成功，向每个服务节点发送执行c操作 |
说明：
PAXOS中有三阶段，三角色（提案者、接收者、学习者）
上述流程中一个p（t、c）称为一个提案，那么提案根据算法存储在半数以上的服务器，那么后续再出现新的p（t、c）则因为t的顺序判断，故会顺序执行。
可以通过反证法，同时出现两个p（t、c）出现在服务节点，且都超过半数，那么两个p提案在服务器之间肯定会有一个不为空的交集。根据两个p中t的顺序号，那么肯定有一个p提案被存储在服务器节点中，成为有效提案。
在step-2中t为判断为与最高票编号比较，于是执行之前已经存储的p提案中的c命令。
场景分析：
如果成功p提案的客户端没有故障，那么直接告诉所有服务器执行命令c
如果客户端在没有告诉服务器执行命令的已经出现故障，那么服务器等待下一个客户端获得提案再执行命令。后续客户端发送请求的时候，服务器即可告诉客户端之前有一个提案待执行，避免再次发送提案。
如果一般服务器出现故障，没有达到半数，客户端无法正常获得回复工作。
如果出现执行多命令情景，那么引入实例、增加实例编号，c命令选中执行，客户端通过新的实例编号来启动新的实例。且服务器通过询问附近服务器确认一致的决议。
算法中p2p网络环境下，每一个节点可以是单一角色、也可以是多个角色。
Leslie Lamport 1989年提出了Paxos这个词汇，但是论文在1998年发表，论文太过于艰涩，很多人都无法明白。
1998年分布式系统问题已经开始受到重试，2006年谷歌大数据相关论文中，在大数据管理核心技术-容错方面采用了Paxos相关机制，故Paxos开始受到的普遍的关注和重视。
Paxos的应用：
数据库相关：Chubby、ZooKeeper、Nutanix等
域名服务器：Name Server
配置管理：config管理。
5.17号，祝福“云茯苓”生日快乐，感谢对磨链社区的支持。
磨链社区-区块链导航平台 。基本框架上线：https://hao.mochain.info/ 欢迎一块来补充内容，建立一个区块链技术社区有内容有价值的平台。
————/磨链热文HOT /————
- END -
群内工作
磨链（mochain）社区输出计划
招募条件：
1.需要一定的区块链基础。
2.对上述任何一方面有较为深入理解。
3.每周能保证一定的空余时间来折腾。
4.了解github相关
5.人员进行筛选，时间周期比较长。
有意向联系我。磨链在线课程
对自己擅长方面有一定的沉淀，愿意开设在线课程，会考虑和一些专业培训机构合作，要求有一定的一线经验，实实在在分享课程。有兴趣的联系，有偿工作。
磨链（mochain）社区内容输出计划
磨链社区内容输出计划，社区内划分6个模块，针对各模块细化分解，社区成员领取任务进行写作内容输出。审核通过后发布，整个过程中即是自己的一个学习提高，同时也有交流分享。
| 序号 | 项目 | 内容输出计划 |
| 1 | 区块链基础 | 包括密码学、共识机制、分布式、P2P网络等 |
| 2 | 以太坊 | 入门到精通，循序渐进学习以太坊 |
| 3 | 比特币 | 入门到精通，比特币相关内容深入琢磨 |
| 4 | 超级账本 | 架构、运行原理、共识机制、环境搭建配置开发相关 |
| 5 | EOS | 概念介绍，由浅入深，持续学习 |
| 6 | DAG | DAG的概念、原理机制、项目技术解读 |
PS：想加入磨链的，或者具体参与到磨链社区内容输出计划的，请加磨链组织者微信(jackyjin09)。欢迎每一位区块链技术爱好者加入磨链，一块琢磨区块链技术。
关于磨链和相关合作
磨链”---取磨炼之意，旨在普及区块链技术，磨炼技术，更好投身区块链行业。有兴趣一块琢磨区块链技术，联系笔者微信(jackyjin09)。
磨链社区是一个纯粹的技术社区，欢迎相关技术合作，在不违反原则的前提下，积极参与合作。
你也可以在这里找到我们：
2. Github : https://github.com/mochain
3. Gitter 聊天: https://gitter.im/mochain
4. 知识星球: https://t.zsxq.com/M3BMVZN
5. 知乎：https://www.zhihu.com/people/mochain
(持续更新中)
以上是关于区块基础-容错Paxos的主要内容，如果未能解决你的问题，请参考以下文章