第4章 分布式同步服务中间件

分布式同步服务就是提供分布式同步服务的组件，它对外提供的功能就如同一个单机的锁服务一样，当其内部是由多个结点组成的，而且节点之间通过某种分布式一致性协议（Paxos、Raft）来协调彼此的状态。如果其中一个节点崩溃了，其他节点就自动接管其功能，继续对外提供服务，好像什么都没有发生过一样。

4.1 分布式一致性协议

• 基于状态机的复制协议，又称主动复制协议（如Paxos、Raft）
  • 集群中的每个节点，即数据副本（replica [ˈreplɪkə] ）都可以响应客户的请求，如果某个节点A响应了客户的请求，就由A将该请求发送给集群中的每个节点
  • 集群中的每个节点都维护一个状态机，当有新请求到达时，节点的状态机就迁移到新状态。为了保证数据的一致性，无论这些请求以什么样的顺序到达，每个节点都安装同样的顺序执行一系列的用户请求
  • 因为协议里已经包含了领导选举过程，所以不需要单独的领导选举协议
• 基于主副本的复制协议，又称为被动复制协议（如ZAB）
  • 只有主副本处理客户请求
  • 每隔一段时间，主副本就给其他节点发送一个变化更新
  • 为了处理主副本宕机的情况，还需要一个额外的领导选举协议

4.2 分布式同步服务中间件简介

在大型分布式系统中，分布式同步服务提供的功能类似于单机操作系统提供的进程（或线程）同步功能，如信号量（semaphore [ˈseməfɔːr] ）、互斥量（mutex /mjuteks/）、事件（event）等

4.3 分布式同步服务中间件的实现原理

Chubby是谷歌公司实现的以Paxos协议为基础的分布式同步服务。另外，还可以在Chubby上面存放少量的共享信息，因此也可以用Chubby实现Registry服务
一个Chubby部署实例称为一个单元（cell）。一个单元由多个副本组成，当前提供服务的副本称为主副本（master replica），其他副本称为非主副本（non-master-replica）

4.3.1 架构

客户端通过一个Chubby客户端与chubby单元通信。每个客户端都保存了单元中所有副本所在的节点列表。
客户端先给副本节点列表中的机器发送一个主副本位置查询请求，如果非主副本收到该消息，就返回主副本的标识；如果主副本收到该消息，就返回自己的标识。知道主副本标识后，客户端就直接与主副本通信。

4.3.2 如何消除单点故障

在同一时刻，一个单元中只有一个主副本对外提供服务。
单元启动后，会通过Paxos协议选举一个主副本。选举出的主副本有一个几秒的租约期。其他副本承诺在该租约期不会选举新的主副本。租约到期后，主副本可以续约，前提是它能够获得多数副本的同意。如果主副本宕机了，在当前主副本租约到期后，其他副本会通过Paxos协议选举出一个新的主副本。

4.3.4 数据库

Chubby的目录和文件信息都存放在数据库中。Chubby使用的数据库是带有复制功能的Berkeley（[ˈbɜrkli]） DB。但考虑到Berkeley DB的复制功能是新增加的，Chubby的后续版本就实现了一个与Berkeley DB类似的分布式数据库，以替代Berkeley DB

4.4 其他分布式同步服务中间件

4.4.1 Linux心跳机制

Linux心跳（heartbeat）机制并不能算作是分布式同步服务，但因其引用广泛，在此也做一简单介绍

Linux heartbeat利用Gratuitous ARP原理将多个Linux服务器绑定在一个虚拟IP上，这些服务器中，只有一个处于活动状态，其他的都处于待机状态。待机服务器和活动服务器之间有周期性心跳。如果活动服务器宕机了，待机服务器就可以发现这一点，然后发送一个Gratuitous ARP，通知其他的机器该IP对应的MAC地址变成其MAC地址了。

4.4.2 Zookeeper

ZooKeeper（ [ˈzuːkiːpə®] ）是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

4.4.3 iNexus

iNexus ([ˈneksəs]简称ins) 是一个基于 Raft 协议实现的高可用的分布式 Key-Value 数据库，支持数据变更通知（Watch）和分布式锁，可用于大型分布式系统的协调工作。