Paxos的实际应用

上一篇说明了paxos算法是如何实现数据一致性的，这一节我们来说明常见paxos的具体实际应用，这样可以更好的理解paxos的具体实现。

1、Paxos应用一Chubby

原理介绍

Chubby是google提出的分布式锁服务，GFS和Big table等大型系统都可以用它来解决分布式写作、元数据存储和master选举等一些列功能。Chubby强大的锁功能，底层则是通过paxos分布式锁来实现的。

Chubby提供粗粒度锁服务。一个Chubby服务单元大约能为1万台4核CPU机器提供资源的协同管理服务。其主要功能为实现集群之间的同步，以及对整个系统的环境和资源达成一致认知。

Chubby是一种锁服务，分布式集群中的机器通过竞争数据的锁来成为leader，获得锁的服务器将自己的信息写入数据，让其他竞争者可见。其提供的粗粒度服务是指锁的持有时间比较长,Chubby会允许抢到锁的服务器，几小时甚至数天内都充当leader角色。Chubby强调系统的可靠性以及高可用性等，而不追求处理高吞吐量以及在协调系统内存储大量数据。其理论基础是Paxos，通过相互通信并投票，对某个决定达成一致性的认识。

系统结构

Chubby的整个系统结构主要由服务端和客户端两部分组成，客户端通过RPC调用与服务端进行通信，如下图所示。

一个典型的Chubby集群，或称为Chubby cell，通常由5台服务器组成。这些副本服务器采用Paxos协议，通过投票的方式来选举产生一个获得过半投票的服务器作为Master。。一旦某台服务器成为了Master，Chubby就会保证在一段时间内不会再有其他服务器称为Master——这段时间被称为Master租期（Master Lease）.

集群中的每个服务器都维护着一份服务端数据库的副本，但在实际运行过程中，只有Master服务器才能对数据库进行写操作，而其他服务器都是使用Paxos协议从Master服务器上同步数据库数据的更新。

现在我们来看一下Chubby如何来处理客户端的请求：

• Chubby客户端定位到Master服务器：Chubby客户端通过向记录有Chubby服务器列表的DNS来请求获取Chubby服务器列表。然后逐个发起请求询问该服务器是否是Master节点，在这个询问过程中，那些非Master服务器，则会将当前Master所在服务器标识反馈给客户端节点。
• Client执行客户端请求：客户端定位到Master服务器之后，只要该Master正常运行，那么客户端就会将所有的请求都发送到该Master服务器上。针对写请求，Chubby Master会采用一致性协议将其广播给集群中所有的副本服务器，并且在过半的服务器接受了该写请求之后，再响应给客户端正确的应答。而对于读请求，则不需要在集群内部进行广播处理，直接由Master服务器单独处理即可。
• Chubby Master 选举：
  在Chubby运行过程中，服务器难免会发生故障。如果当前的Master服务器崩溃了，那么集群中的其他服务器会在Master租期到期后，重新开启新一轮的Master选举。通常，进行一次Master选举大概需要花费几秒钟的时间。而如果是集群中任意一台非Master服务器崩溃，那么整个集群是不会停止工作的，这个崩溃的服务器会在恢复之后自动加入到Chubby集群中去。新加入的服务器首先需要同步Chubby最新的数据库数据，完成数据同步之后**，新的服务器就可以加入到正常的Paxos运行流程中与其他服务器副本一起协同工作**。

这里客户端对chubby服务器进行读写，实际可以看做是一种申请锁的服务。

Chubby中的事件通知

Chubby的客户端可以向服务端注册时间通知，当触发这些事件的时候，服务端就会向客户端发送对应的事件通知。Chubby常见的事件通知如下：

• 文件内容变更
• 节点删除
• 子节点新增、删除
• Master服务器转移

注意这里的事件通知可以保证客户端和服务端是异步通信的，当服务器发生了上述的事件时，再去通知客户端，类似回调函数执行。

Chubby中paxos的实现

前面已经提到了chubby实现了分布式锁的服务，那么chubby是如何实现的呢？其实我们仔细思考，所谓的分布式锁服务，就是只多个客户可以通过该服务器获取到锁，也就是说chubby本身需要保证锁的一致性，不能多个客户同时获得一个锁，同时保证锁本身记录的日志在多个副本是一致的。

也就是，所有锁记录的日志在不同副本上必须保证一致，如何保证一致？
——基于paxos算法实现。

Chubby服务端的基本架构大致分为三层：

• 最底层是容错日志系统（Fault-Tolerant Log），通过Paxos算法能够保证集群中所有机器上的日志完全一致，同时具备较好的容错性。
• 日志层之上是Key-Value类型的容错数据库（Fault-Tolerant DB），其通过下层的日志来保证一致性和容错性。
• 存储层之上就是Chubby对外提供的分布式锁服务和小文件存储服务。

Paxos算法的作用就在于保证集群内各个副本节点的日志能够保持一致。Chubby事务日志中的每一个Value对应Paxos算法中的一个Instance，由于Chubby需要对外提供不间断的服务，因此事务日志会无限增长，于是在整个Chubby运行过程中，会存在多个Paxos Instance。同时，Chubby会为每一个Paxos Instance都按序分配一个全局唯一的Instance 编号，并将其顺序写入到事务日志中去。

在多Paxos Instance的模式下，为了提升算法执行的性能，就必须选举出一个副本节点作为Paxos算法的主节点（以下简称Master或Coordinator），以避免因为每一个Paxos INstance 都提出提案而陷入多个Paxos Round并存的情况。同时，Paxos会保证在Master重启或出现故障而进行切换的时候，允许出现短暂的多个Master共存却不影响副本之间的一致性。

在Paxos中，每一个PaxosInstance都需要进行一轮或多轮“Prepare→Promise→Propose→Accept”这样完整的二阶段请求过程来完成对一个提案值的选定，而多个Instance之间是完全独立的，每个Instance可以自己决定每一个Round的序号，尽尽只需要保证在Instance 内部不会出现序号重复即可。为了在保证正确性的前提下尽可能的提高算法运行性能，可以让多个Instance共用一套序号分配机制，并将“Prepare→Promise”合并为一个阶段，具体做法如下。

• 当某个副本节点通过选举成为Master后，就会使用新分配的编号N来广播一个Prepare消息，该Prepare消息会被所有未达成一致的Instance和目前还未开始的Instance共用。
• 当Acceptor接收到Prepare消息后，必须对多个Instance同时做出回应，这通常可以通过将反馈信息封装在一个数据包中来实现。假设最多允许K个Instance同时进行提案值的选定，那么：
• 当前至多存在K个未达成一致的Instance，将这些未决的Instance各自最后接受的提案值（若该提案尚未接受任何值，则使用null来代替）封装进一个数据包，并作为Promise消息返回。
  同时，判断N是否大于当前Acceptor的highestPromisedNum值（当前已经接受的最大提案编号值），如果大于该值的话，那么就标记这些未决Instance和所有未来的Instance的highestPromisedNum值为N——这样，这些未决Instance和所有未来Instance都不能再接受任何编号小于N的提案。
• 然后Master就可以对所有未决Instance和所有未来Instance分别执行“Propose→Accept”阶段的处理。值得注意的是，如果当前Master能够一致稳定运行的话，那么在接下来的算法运行过程中，就不再需要进行“Prepare→Promise”的处理了。但是一旦Master发现Acceptor返回了一个Reject消息，说明集群汇总存在另一个Master，并且试图使用更大的提案编号（比如M，其M>N）发送了Prepare消息。碰到这种情况，当前Master就需要重新分配新的提案编号（必须比M更大）并再次进行“Prepare→Promise”阶段的逻辑处理。

在每个Instance的运行过程中，一旦接收到多数派的Accept反馈后，就可以将对应的提案值写入本地事务日志并广播Commit消息给集群中的其他副本节点，其他副本节点在接收到这个COMMIT消息之后也会将提案值写入到事务日志中去。

通过以上的paxos算法来保证所有集群上节点写入持久化的日志消息是一致的。

2、Paxos应用—Hypertable

原理介绍

Hypertable是一个使用C++ 语言开发的开源、高性能、可伸缩的数据库，其以Google的BigTable相关论文为基础指导，采用与HBase非常相似的分布式模型，其目的是要构建一个针对分布式海量数据的高并发数据库。

目前Hypertable只支持最基本的增、删、改、查功能，对于事务处理和关联查询等关系型数据库的高级特性都尚未支持。同时，就少量数据记录的查询性能和吞吐量而言，Hypertable可能也不如传统的关系型数据库。和传统关系型数据库相比，Hypertable最大的优势在于以下几点。

• 支持对大量并发请求的处理。
• 支持对海量数据的管理。
• 扩展性良好，在保证可用性的前提下，能够通过随意添加集群中的机器来实现水平扩容。
• 可用性极高，具有非常好的容错性，任何节点的失败，既不会造成系统瘫痪也不会影响系统完整性。

系统结构

Hypertable的整体架构如下图所示。

Hypertable的核心组件包括Hyperspace、RangeServer、Master和DFS Broker四部分。其中Hyperspace是Hypertable中最重要的组件之一，其提供了对分布式锁服务的支持以及对元数据的管理，是保证Hypertable数据一致性的核心。Hyperspace类似于Google BigTable 系统中的 Chubby，在这里我们可以认为他是一个文件存储系统，主要用来存储一些元数据信息，同时提供分布式锁服务，另外还负责提供高效、可靠的主机选举服务。

RangeServer 是实际对外提供服务的组件单元，负责数据的读取和写入。在Hypertable的设计中，对每一张表都按照主键进行切分，形成多个Range（类似于关系型数据库中的分表）负责管理。在Hypetable中，通常会部署多个RangeServer，每个RangeServer都负责管理部分数据，由Master来负责进行RangeServer的集群管理。

Master是元数据管理中心，管理包括创建表、删除表或是其他表空间变更在内的所有元数据操作，同时负责检测RangeServer的工作状态，一旦某一个RangeServer宕机或是重启，能够自动进行Range的重新分配，从而实现对RangeServer集群的管理和负载均衡。

DFS Broker则是底层分布式文件系统的抽象层，用于衔接上层Hypertable和底层文件存储。所有对文件系统的读写操作，都是通过DFS Broker来完成的。目前已经可以接入Hypertable中分布系统包括HDFS、MapR、Ceph和KFS等，针对任何其他新的文件系统，只需要实现一个对应的DFS Broker，就可以将其快速接入到整个Hypetable系统中。

算法实现

从上面讲解中我们了解到，Hyperspace是整个Hypertable中最为核心的部分之一。基于对底层BDB的封装，通过对Paxos算法的实现，Hyperspace能够很好的保证Hypertable中元数据的分布式一致性。接下来我们就看看Hyperspace是如何实现分布式数据一致性的。

Active Server
Hyperspace通常以一个服务器集群的形式部署，一般由5~11台服务器组成，在运行过程中，会从集群中选举产生一个服务器作为Active Server，其余的服务器则是Standby Server，同时，Active Server 和 Standby Server 之间会进行数据和状态的实时同步。

在Hypertable启动初始化阶段，Master模块会连接上Hyperspace集群中的任意一台服务器，如果这台Hyperspace服务器恰好处于Active状态，那么便完成了初始化连接；如果连接上的Hyperspace服务器恰好处于Active状态，那么便完成了初始化连接；如果连接上的Hyperspace服务器处于Standby状态，那么该Hyperspace服务器会在此次连接创建后，将当前处于Active状态的Hyperspace服务器地址发送给Master模块，Master模块会重新与该Active Hyperspace服务器建立连接，并且之后对Hyperspace的所有操作请求都会发送给这个Hyperspace服务器。换句话说，只有Active Hyperspace才能真正的对外提供服务。

事务请求处理
在Hyperspace集群中，还有一个非常重要的组件，就是BDB。BDB服务也是采用集群部署的，也存在Master的角色，是Hyperspace底层实现分布式数据一致性的精华所在。在Hyperspace对外提供服务时，任何对于元数据的操作，Master模块都会将其对应的事务请求发送给Hyperspace服务器。在接收到该事务请求后，Hyperspace服务器就会向BDB集群中的Master服务器发起事务操作。BDB服务器在接收到该事务请求后，会在集群内部发起一轮事务请求投票流程，一旦BDB集群内部过半的服务器成功应用了该事务操作，就会反馈Hyperspace服务器更新已经成功，再由Hyperspace响应上层的Master模块。

举个例子来说，假设有一个由5台服务器组成的Hyperspace集群，其Active Hyperspace在处理一个建表请求时，需要获得至少3台BDB服务器的同意才能够完成写入。虽然这样的事务更新策略显然会严重影响其对写操作的响应速度，但由于其存入的元数据更新并不特别频繁，因此对写性能的影响还在可接受的范围内——毕竟数据的可靠一致才是最重要的。

Active Hyperspace 选举
当某台处于Active状态的Hyperspace服务器出现故障时，集群中剩余的服务器会自动重新选举出新的Active Hyperspace，这一过程称为Hyperspace集群的Active选举。Active 选举过程的核心逻辑就是根据所有服务器上事务日志的更新时间来确定哪个服务器的数据最新——事务日志更新时间越新，那么这台服务器被选举为Active Hyperspace的可能性就越大，因为只有这样，才能避免集群中数据不一致情况的发生。完成Active Hyperspace选举之后，余下所有的服务器就需要和Active Hyperspace服务器进行数据同步，即所有Hyperspace服务器对应的BDB数据库的数据都需要和Master BDB 保持一致。

从上面的讲解中我们可以看出，在整个Hyperspace的设计中，为了使整个集群能够正常的对外提供服务，那么就必须要求Hyperspace集群中至少需要有超过一般的机器能够正常运行。另外，在Hyperspace集群正常对外提供服务的过程中，只有Active Hyperspace才能接受来自外部的请求，并且交由底层的BDB事务来保证一致性——这样就能够保证在存在大量并发操作的情况下，依然能够保证数据的一致性和系统的可靠性。

参考博客：
https://blog.csdn.net/qq_21125183/article/details/86479700
https://www.cnblogs.com/52mm/p/p7.html
https://www.jianshu.com/p/ea27f4c95803
https://blog.csdn.net/en_joker/article/details/78656030