虾说区块链-45-分布式系统

一直在说区块链是一系列技术结合后的新的技术架构，那么这里分别介绍下这些相关技术，也涉及到一些扩展开去的相关内容。

区块链-分布式系统：

分布式系统目前应用广泛，区块链技术中只是结合了这一项技术，这里再对分布式系统的一些概念和原理作个简介。

分布式系统出现是一种必然，特别是互联网的发展，互联网业务面对高并发、海量数据等问题，目前大多采用分布式架构来搭建应用系统提供服务。

和传统的中心化系统对比：

传统中心化系统的性能瓶颈，不论中心化节点服务器的性能多么强劲，面对日益复杂的业务和海量数据的处理，单独中心化服务器会遇到处理能力瓶颈。分布式系统提供性能的横向扩展，通过多节点来应对复杂业务和海量数据处理。良好的扩展性是目前系统设计前期着重考虑的一个现实性问题。

中心化系统根据其业务的重要性，大多会对其进行业务本地高可用、异地应用级灾备建设，保证业务连续性，不论对高可用还是异地灾备的建设，在系统的健壮性和业务的连续性来讲，始终也会出现一个极限状态，分布式系统多节点服务，多个副本、提供了良好的高可用性。

传统中心化系统，面对网络异常、设备故障（服务器、硬盘、存储）、恶意攻击，中心节点会发生故障，导致无法正常对外提供服务，分布式系统多节点，理论上良好的避免了中心化节点失控的情况。（和上述其实是一个道理）

在讲区块链共识机制中，一般都会讲到拜占庭容错问题，拜占庭容错机制这里解释一个目的，很多人认为拜占庭容错的问题是为了找出问题节点，其实相反，拜占庭容错为了保证系统的可用性，它不目的不是为了去发现了故障节点，而是为了保证整个系统能正常对外提供服务。

分布式系统中关键指标：

和上一篇文章一样，笔者认为一致性在分布式系统中尤为重要，数据更新、日志的插入一致性的要求，保证整个系统的一致性，对外提供服务才能保证系统的可靠。

分布式系统中的性能指标，分布式系统的出现很大一部分的原因是为了解决传统中心化系统的性能瓶颈问题，故系统的性能指标，如：吞吐量、系统延时、并发量、每秒的处理能力等这些性能指标也极为重要。分布式系统中这些性能的因素和传统中心化系统相比，不在依赖单一的服务器节点硬件性能指标，更多依赖各个节点之间的互相通讯，也简单认为各个节点之间相互制约。

横向扩展，考验系统的一个扩展性，考虑成本和整体架构，一般分布式系统采用低配的X86服务器进行大量的堆叠，实现更强劲的整体性能，来对外提供服务。要求良好的横向扩展能力，根据业务的高峰和低谷，实时上下线节点。

业务连续性，不可避免在分布式系统中肯定会出现节点的故障和服务的异常，那么保证业务正常的对外提供，及时对失效节点进行下线，实时增加节点保证性能。在出现节点故障时候扔正常提供服务，保证实时业务的多个9保证。

副本数量，很多的分布式存储系统都会在上线时候考虑副本分散和副本份数的问题，权衡业务，保证多个节点多个副本，数据分散后在出现故障后能及时重构，保证数据的完整性。

分布式系统时间，分布式系统中传统的物理时间由于节点的分散，往往无法满足一致性，全时间同步，往往也会造成细微时间差，极限状态下，一台X86服务器两颗CPU之间通讯也会因为CPU之间电路的距离会差生细微差距（有点钻牛角尖），那么分布式系统中一般采用逻辑时钟、顺序时钟来进行排序。

分布式系统协议：

分布式系统的建设都会考虑CAP原理，理论结合工程实际，三者取舍，实现一个系统的可靠运行。针对系统建设出现了一些协议，所谓协议就是分布式系统整体的一个一致性共识，理想化状态完全达成共识再返回或对外响应，那么系统的可用性和效率不可避免会受到一定程度的影响。举例区块链技术中的各种共识：pow、pos、raft等扩展后的共识机制，都在对整个系统进行一个效率和完整性的取舍。

举例PAXOS：

PAXOS算法，leslie lamport（图灵奖、还有一个分布式中著名lamport时钟）1990年提出的一种一致性算法。

PAXOS的应用是一种强一致性去中心化副本的控制协议，通过选举投票的方式来说明：

一个分布式系统理解为一个议会。

PAXOS（这个算法是基于一个小岛上议会的场景提出）算法中引入三个角色和一些流程号：

Proposer：提案者（提出某个议案）

Acceptor：接受者（接受提出者的议案）

Learners：学习者（学习实施议案）

引入节点议案本地编号：PID

议案值：value

三种绝对对于节点来说可以是复用，前提每个节点执行议案过程中可能出现问题，但是船体的议案值value不会被更改。下面用通俗的说话来这个算法：

1.分布式节点存在于一个网络环境中，大家网络互通。

2.每个节点对自己本地的议案有一个数据编号，初始化每个节点PID=0。

3.节点A提出议案value，作为提案者，接受者接受value。这里有两种情况，接受者只有一个的话，那么只要接受者接受了value很快就个议案就成立了，那么要是这个接受者出现网络故障或者本身宕机了，那么就马上执行不下去了。那么接受者有多个呢，提案者有多个呢，那么接受者应该怎么接受提案，或者多个接受者接受了不同了提案者的value值怎么处理。算法中设定，接受者必须接受第一个提案。

4.结合PID和value，两个值组合一个数据。

5.节点A已提出议案value，加上PID，PID一直增加，网络中接受者超过半数接受到节点A的提案，这个节点生效，如果稍后时刻节点B提出议案PID值大于目前PID值，那么通过接受者数量超过半数，该议案生效，如果一开始检测PID小于之前PID就被退回，并告诉节点B。

6.学习者去收集接受者接收后的提案，且遵循超过半数的原则形成最终的提案，更新value。

ZooKeeper、Chubby，就是该协议的应用。

本文由币乎社区（bihu.com）内容支持计划赞助。

之前写了点东西，随着对区块链的理解，发现有些理解的并不透彻，重新整理。如有理解不正确的地方，请及时指正，同时有兴趣一块交流的可以加笔者微信：