zookeeper集群部署和单机部署的区别和优缺点

Apache Zookeeper是我最近遇到的最酷的技术，我是在研究Solr Cloud功能的时候发现的。Solr的分布式计算让我印象深刻。你只要开启一个新的实例就能自动在Solr Cloud中找到。它会将自己分派到某个分片中，并确定出自己是一个Leader（源）还是一个副本。不一会儿，你就可以在你的那些服务器上查询到了。即便某些服务器宕机了也可以继续工作。非常动态、聪明、酷。

将运行多个应用程序作为一个逻辑程序并不是什么新玩意。事实上，我在几年前就已写过类似的软件。这种架构比较让人迷惑，使用起来也费劲。为此Apache Zookeeper提供了一套工具用于管理这种软件。

为什么叫Zoo？“因为要协调的分布式系统是一个动物园”。

在本篇文章中，我将说明如何使用PHP安装和集成Apache ZooKeeper。我们将通过service来协调各个独立的PHP脚本，并让它们同意某个成为Leader（所以称作Leader选举）。当Leader退出（或崩溃）时，worker可检测到并再选出新的leader。

ZooKeeper是一个中性化的Service，用于管理配置信息、命名、提供分布式同步，还能组合Service。所有这些种类的Service都会在分布式应用程序中使用到。每次编写这些Service都会涉及大量的修bug和竞争情况。正因为这种编写这些Service有一定难度，所以通常都会忽视它们，这就使得在应用程序有变化时变得难以管理应用程序。即使处理得当，实现这些服务的不同方法也会使得部署应用程序变得难以管理。

虽然ZooKeeper是一个Java应用程序，但C也可以使用。这里就有个PHP的扩展，由Andrei Zmievski在2009创建并维护。你可以从PECL中下载，或从GitHub中直接获取PHP-ZooKeeper。

要使用该扩展你首先要安装ZooKeeper。可以从官方网站下载。

$ tar zxfv zookeeper-345targz

$ cd zookeeper-345/src/c

$ /configure --prefix=/usr/

$ make

$ sudo make install

这样就会安装ZooKeeper的库和头文件。现在准备编译PHP扩展。

$ cd$ git clone https://githubcom/andreiz/php-zookeepergit

$ cd php-zookeeper

$ phpize

$ /configure

$ make

$ sudo make install

将“zookeeperso”添加到PHP配置中。

$ vim /etc/php5/cli/confd/20-zookeeperini

因为我不需要运行在web服务环境下，所以这里我只编辑了CLI的配置。将下面的行复制到ini文件中。

extension=zookeeperso

使用如下命令来确定扩展是否已起作用。

$ php -m | grep zookeeper

zookeeper

现在是时候运行ZooKeeper了。目前唯一还没有做的是配置。创建一个用于存放所有service数据的目录。

$ mkdir /home/you-account/zoo

$ cd$ cd zookeeper-345/

$ cp conf/zoo_samplecfg conf/zoocfg

$ vim conf/zoocfg

找到名为“dataDir”的属性，将其指向“/home/you-account/zoo”目录。

$ bin/zkServersh start

$ bin/zkClish -server 127001:2181[zk: 127001:2181(CONNECTED) 14] create /test 1

Created /test[zk: 127001:2181(CONNECTED) 19] ls /[test, zookeeper]

此时，你已成功连到了ZooKeeper，并创建了一个名为“/test”的znode（稍后我们会用到）。ZooKeeper以树形结构保存数据。这很类似于文件系统，但“文件夹”（译者注：这里指非最底层的节点）又和文件很像。znode是ZooKeeper保存的实体。Node（节点）的说法很容易被混淆，所以为了避免混淆这里使用了znode。

因为我们稍后还会使用，所以这里我们让客户端保持连接状态。开启一个新窗口，并创建一个zookeeperdemo1php文件。

<php

class ZookeeperDemo extends Zookeeper {

public function watcher( $i, $type, $key ) {

echo "Insider Watcher\n";

// Watcher gets consumed so we need to set a new one

$this->get( '/test', array($this, 'watcher' ) );

}

}

$zoo = new ZookeeperDemo('127001:2181');$zoo->get( '/test', array($zoo, 'watcher' ) );

while( true ) {

echo '';

sleep(2);}

现在运行该脚本。

$ php zookeeperdemo1php

此处应该会每隔2秒产生一个点。现在切换到ZooKeeper客户端，并更新“/test”值。

[zk: 127001:2181(CONNECTED) 20] set /test foo

这样就会静默触发PHP脚本中的“Insider Watcher”消息。怎么会这样的？

ZooKeeper提供了可以绑定在znode的监视器。如果监视器发现znode发生变化，该service会立即通知所有相关的客户端。这就是PHP脚本如何知道变化的。Zookeeper::get方法的第二个参数是回调函数。当触发事件时，监视器会被消费掉，所以我们需要在回调函数中再次设置监视器。

现在你可以准备创建分布式应用程序了。其中的挑战是让这些独立的程序决定哪个（是leader）协调它们的工作，以及哪些（是worker）需要执行。这个处理过程叫做leader选举，在ZooKeeper Recipes and Solutions你能看到相关的实现方法。

这里简单来说就是，每个处理（或服务器）紧盯着相邻的那个处理（或服务器）。如果一个已被监视的处理（也即Leader）退出或者崩溃了，监视程序就会查找其相邻（此时最老）的那个处理作为Leader。

在真实的应用程序中，leader会给worker分配任务、监控进程和保存结果。这里为了简化，我跳过了这些部分。

创建一个新的PHP文件，命名为workerphp。

<php

class Worker extends Zookeeper {

const CONTAINER = '/cluster';

protected $acl = array(

array(

'perms' => Zookeeper::PERM_ALL,

'scheme' => 'world',

'id' => 'anyone' ) );

private $isLeader = false;

private $znode;

public function __construct( $host = '', $watcher_cb = null, $recv_timeout = 10000 ) {

parent::__construct( $host, $watcher_cb, $recv_timeout );

}

public function register() {

if( ! $this->exists( self::CONTAINER ) ) {

$this->create( self::CONTAINER, null, $this->acl );

}

$this->znode = $this->create( self::CONTAINER '/w-',

null,

$this->acl,

Zookeeper::EPHEMERAL | Zookeeper::SEQUENCE );

$this->znode = str_replace( self::CONTAINER '/', '', $this->znode );

printf( "I'm registred as: %s\n", $this->znode );

$watching = $this->watchPrevious();

if( $watching == $this->znode ) {

printf( "Nobody here, I'm the leader\n" );

$this->setLeader( true ); }

else {

printf( "I'm watching %s\n", $watching );

}

}

public function watchPrevious() {

$workers = $this->getChildren( self::CONTAINER );

sort( $workers );

$size = sizeof( $workers );

for( $i = 0 ; $i < $size ; $i++ ) {

if( $this->znode == $workers[ $i ] ) {

if( $i > 0 ) {

$this->get( self::CONTAINER '/' $workers[ $i - 1 ], array( $this, 'watchNode' ) );

return $workers[ $i - 1 ];

}

return $workers[ $i ];

}

}

throw new Exception( sprintf( "Something went very wrong! I can't find myself: %s/%s",

self::CONTAINER,

$this->znode ) );

}

public function watchNode( $i, $type, $name ) {

$watching = $this->watchPrevious();

if( $watching == $this->znode ) {

printf( "I'm the new leader!\n" );

$this->setLeader( true );

}

else {

printf( "Now I'm watching %s\n", $watching ); }

}

public function isLeader() {

return $this->isLeader;

}

public function setLeader($flag) {

$this->isLeader = $flag;

}

public function run() {

$this->register();

while( true ) {

if( $this->isLeader() ) {

$this->doLeaderJob();

}

else {

$this->doWorkerJob();

}

sleep( 2 );

}

}

public function doLeaderJob() {

echo "Leading\n";

}

public function doWorkerJob() {

echo "Working\n";

}

}

$worker = new Worker( '127001:2181' );$worker->run();

打开至少3个终端，在每个终端中运行以下脚本：

# term1

$ php workerphp

I'm registred as: w-0000000001Nobody here, I'm the leader

Leading

# term2

$ php workerphp

I'm registred as: w-0000000002I'm watching w-0000000001

Working

# term3

$ php workerphp

I'm registred as: w-0000000003I'm watching w-0000000002

Working

现在模拟Leader崩溃的情形。使用Ctrl+c或其他方法退出第一个脚本。刚开始不会有任何变化，worker可以继续工作。后来，ZooKeeper会发现超时，并选举出新的leader。

虽然这些脚本很容易理解，但是还是有必要对已使用的Zookeeper标志作注释。

$this->znode = $this->create( self::CONTAINER '/w-', null, $this->acl, Zookeeper::EPHEMERAL | Zookeeper::SEQUENCE );

每个znode都是EPHEMERAL和SEQUENCE的。

EPHEMRAL代表当客户端失去连接时移除该znode。这就是为何PHP脚本会知道超时。SEQUENCE代表在每个znode名称后添加顺序标识。我们通过这些唯一标识来标记worker。

在PHP部分还有些问题要注意。该扩展目前还是beta版，如果使用不当很容易发生segmentation fault。比如，不能传入普通函数作为回调函数，传入的必须为方法。我希望更多PHP社区的同仁可以看到Apache ZooKeeper的好，同时该扩展也会获得更多的支持。

ZooKeeper是一个强大的软件，拥有简洁和简单的API。由于文档和示例都做的很好，任何人都可以很容易的编写分布式软件。让我们开始吧，这会很有趣的。

本文基于对redis、zookpeer、rocketmq、elasticsearch学习总结，对于分布式系统学习，一定绕不开一个点，那就是CAP定理。什么是CAP定理，我这里简单的复制摘抄一下百度上的文案。

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

说明一下上面的三个要素各代表的含义：

CAP定理说明上述的三个要素不能兼顾，最多只能满足其中的两个要素，在分布式系统中，一般都是保证分区容错性，而在一致性和可用性之间做取舍。因此存在CP、AP两种分布式集群的实现。

CP集群，即满足一致性和分区容错性，如zookpeer

AP集群，即满足可用性和分区容错性，如redis-cluster

下面，针对与上述的CP和AP问题，我们展开话题。

对于分布式系统，学习了解多了之后，发现其内在的解决方案基本上都是一样的，所谓万变不离其中。总结一下大体在于以下几步：

数据分片，很多分布式系统尤其是中间件服务，一般都会涉及高并发，数据量大的问题，如redis-cluster、recketmq，以及被大家熟知的Elasticsearch。针对于大数据量高并发的问题，若不做处理，服务器的性能将会成为服务的瓶颈，解决的方案之一便是数据分片，将大数据量在集群中按照一定的规则分片，使数据按照一定的规则分布集群的不同服务器上，以减轻单个服务器的压力，保证服务集群的可用性。

redis-cluster的数据分片是通过redis-cluster的哈希槽来实现的，redis-cluster有16384个哈希槽，这个数量是固定的，根据集群中服务器的数量可以手动的调配每个服务上存放的hash槽的数量，哈希槽之间是相互独立的，因此对集群的扩展提供了便利。

rocketmq的分片和topic紧密相关，在使用rocketmq中，无论是消息的生产者还是消费者都需要注册订阅一个topic。在rocketmq集群中，集群中的broker保存这个topic下数据的一部分，也就是topic的其中一个数据分片。当然，rocketmq不仅将一个topic下的数据分片到多个broker上，而且，一个broker上的topic数据还可以被分为多个queue，这是因为rocketmq中，一个queue只能被一个consumer消费，若是consumer的数量多于queue的数量，没有绑定queue的consumer将不能消费数据。

elasticsearch的数据分片在我看来和mysql的分库分表原理是一样的，elasticsearch中，每一个索引都相当于mysql的一个表，将一个索引分成多个shard放在不同的节点上，每个shard存储一部分数据。elasticsearch将数据进行分片，这样可以支持集群的横向扩展，同时，多个节点提供服务可以提高系统的效率和吞吐量。

综上所述，数据分片的一般都有两个好处，一个是支持集群的横向扩展，而是提升服务的吞吐量和性能。数据分片解决了以上两个问题，但是若是集群中一个节点发生宕机，或者因为网络原因和集群断开链接，那么这部分的数据分片甚至整个集群都会不可用，如何解决这个问题，就需要用到数据备份和主备切换。

数据分片的策略 了解了数据分片之后，需要了解以下数据分片的策略，根据集群提供服务的性质不同，可以采用的数据分片策略也各有不同，下面是我学习后的总结：

说到这里，会发现其实这种分片策略和负载均衡的策略还是挺相似的。

数据备份，举个例子来说，我有两台电脑A、电脑B，A用于工作，B用于游戏，我写了一篇文章，保存在电脑上电脑上，若是某一天我的电脑A磁盘坏了，那我这篇文章就找不到了，即便我现在还有电脑B，我也没有办法在对文章进行编辑。但是若是我在之前，就将文章拷贝了一份放在电脑B上，那么现在，我用电脑B就可以对文件进行编辑修改。

举这个例子，我的目的就是为了说明数据备份对于集群可用性的意义，例子中，我的两台电脑可以认为是集群中两台服务器，两台服务器一开始提供的服务可能不相同，A电脑提供的就是编辑文章的服务，数据备份的意义就在于，当原本提供服务的服务器宕机损坏，集群中另外的服务器仍然可以根据已经备份的数据提供相同的服务，而不会影响到用户的工作。

数据备份的目的就是不发生单点问题的措施之一，但是若是数据备份的策略不合适，备份的时机不对，那么备份的数据时效性也是问题。还是从例子出发，这里的文章每次都是我手动从A电脑拷贝到B电脑，这是我的备份策略，若是我选择每天晚上才拷贝一次，那么若是A电脑在我拷贝之前坏了，当天的文章编辑数据就丢失了，采用手动的方式备份，这种备份方式耗时耗力且不可控，而在分布式集群中，不同的系统采用了不同的备份策略，下面一一来说明。

首先明确一点，在分布式集群中，不可能采用人工手动备份，一定是系统程序按照一定的规则自动备份，就好像我将AB连在一起，写个程序，让A电脑自动把文章同步到B电脑。数据备份的方式分为两种：

这里以redis-cluster和zookeeper举例。

在redis-cluster中，当一台新的slave节点加入时，会出发数据同步，需要将主节点的数据同步到从节点。这时根据从节点的状态有两种同步方案：完整重同步 和 部分重同步

完整重同步既是将主节点的全部数据都复制给新的slave节点。大致流程为，当一个新的节点加入进来时，发送PSYNC命令给主节点并携带slave节点自身的信息（重点是复制偏移量），主节点会根据slave传过来的信息判断是完整重同步还是部分重同步，如何判断与数据同步时的复制缓冲区有关，更细节不展开介绍。

相对于redis-cluster，zookeeper中的数据同步有四种方式，和redis-cluster完整重同步和部分重同步相似的SNAP（全量同步）和DIFF（增量同步），以及zk事务处理相关的TRUNC（仅回滚同步）、TRUNC+DIFF（回滚+增量同步）

当节点已经加入集群，成为集群中的从节点，只要不断开连接，一般都只需要进行增量同步，不过系统同步的范围和方式有所差异，大致分为下面六种：

下面还是以具体服务来举例： redis-cluster中，主从复制采用的是异步复制的方式，master节点在做数据变更之后，会由一个异步线程将数据变更同步给slave节点，这是通过push的方式。当redis28之后，slave会周期的获取最新的数据，加入了pull方式。无论是master还是slave，在进行数据同步时，不会阻塞正常的应用请求。所以redis-cluster的主从复制，是异步备份+最终一致性的备份。

elasticsearch的主从复制可以手动设置同步备份或者异步备份，数据备份时不要求强一致性，而是主分片（primary shard）会维护一份需要同步的（replica shard）分片列表，这个分片列表同步完成，则认为数据备份完成，需要注意的是，这里的主从复制不是节点的更新数据，而是分片的更新数据。

rocketmq的主从复制和elasticsearch类似，也可以分为同步备份和异步备份，不同的是rocketetmq的数据备份采用的是pull的方式，从节点会通过HAConnection链接主动向主节点发送待拉取数据偏移量，待主节点返回节点更新数据信息，更新从节点数据偏移量，如此重复。

zookeeper的数据备份则是通过ZAB协议，通过消息广播的方式同步数据到从节点。

当数据备份后，主从节点上就有了相同的数据，为了提升服务的性能，那么可以采用读写分离的方式。主节点提供数据写服务，从节点提供读服务，可以有效的分担主节点的服务器压力。可以进行数据分片的系统，如：redis、rocketmq、elasticsearch，一般都可以配置一主多从、多主多从的集群架构。

读写分离之后，主节点提供写服务，从节点只提供读服务，因此若是主节点发生宕机，从节点依然可以提供读服务，但是服务无法更新数据，这时候就要进行主从切换。早起，主从切换可以由人工手动完成，不过随着技术发展，主从切换已经成为集群的必备功能。想要实现主从切换，必须要解决两个问题：

解决这个问题，需要额外再引入一个角色，相当于是一个监视者的角色，能够长期的对主节点进行监视，若是只有一个监视者，可能会发生误判，所以还需要一套机制去保证当监视者说主节点宕机，那么主节点是真的宕机，否则集群会出现脑裂问题。

以redis为例，在redis的哨兵模式中，这个监视者的角色是一个个哨兵实例，而在redis-cluster架构中，这个监视者的角色是redis实例自己。

在redis哨兵模式中，哨兵集群中的哨兵实例会定期和redis实例进行通信（ping），监视redis实例的在线情况，若是其中一台哨兵发现redis实例master故障，那么该哨兵会将该master状态改为主观下线，并通知其他哨兵，当哨兵集群中达到配置数量的哨兵实例认为该master都为主观下线状态，这时会将master修改为客观下线状态，并开始触发后续的故障转移。

在redis-cluster模式中，集群中的每一个节点都可以和其他节点通讯（ping），当某一个节点A发现主节点B下线了，A会将该主节点B设为疑似下线状态。集群中的节点会通过互发消息维护信息，当另一个节点C收到A的消息时，会将A对B节点的判断记录在C节点的维护信息下，这个信息可以理解为A说C疑似下线了。若是有其他节点发送C的状态信息，A同样也会记录。当某一个节点如C发现记录的B节点信息中，超过半数的主节点都认为B下线了，那么C就会将B节点状态修改为已下线状态，并广播消息给集群的其他节点，开始后续的故障转移。

上面就是redis的两种分布式模式故障检测的方案。大致可以归结为，监视节点会和被监视节点进行通讯，感知被监视节点的状态；监视节点之间也会进行通讯，同步信息。为了防止集群出现脑裂，对于某个主节点的故障判断会十分的谨慎，需要达到一定数量的监视节点都认为主节点故障时，才会认为主节点真的故障，从而触发故障转移。

在rocketmq集群模式中，nameserver扮演着监视者的角色（不同于其他系统，nameserver并不负责集群的主从切换，rocketmq 45之前不支持自动主从切换，45之后，通过dledger实现自动的故障转移）。在elasticsearch集群中，elasticsearch实例本身在扮演监视者角色。zookeeper也是实例本身扮演监视者的角色。

故障转移就是当集群发现集群中的主节点/从节点发生故障之后的处理，从节点比较简单，直接将从节点下线即可，主节点的故障转移流程比较复杂，各个系统根据系统的功能和架构有不同的实现方式，共同点是选举出的主节点一定是集群中数据最新的最完善的节点。

选举过程大致如下：

首先选举成功的条件时集群中具有投票权限的超过半数的节点投票一致，通过某一个节点成为主节点。

开始一轮选举时，定义为一个纪元，用一个自增的id表示。

候选节点将带着纪元id，以及自身信息作为投票申请广播给集群给可投票的节点。

具有投票权限的节点投票只要满足两个条件：1自身在最新纪元没有给投过票 2节点发送过来的投票申请时最新纪元的（如何判断时最新纪元，则是判断一下节点之前通过申请的纪元id是否小于当前申请的纪元id）。

半数以上的投票节点通过某一个候选节点成为leader节点，则leader产生。

若是一个纪元没有产生主节点，则候选节点进入随机的休眠，并且开启下一个纪元，知道产生leader节点。

在zk集群经过崩溃恢复模式之后，需要保证：1已经提交的事务不能丢失 2未被提交的事务不能出现。如何保证以上两点，zk服务集群中维护了zxid，zxid也可以看作是一个自增的id，集群中每产生一个新事物，zxid就会增加。zxid有64位，前32位维护了集群主节点变更情况，每重新选举出一个新的主节点则增加，后32位维护在新的主节点集群下事务的id，产生一个新事物则增加。

ZAB的选举模式有很多种，我主要了解了默认，也是推荐的FastLeaderElection模式，在这个模式下，我会以集群中一台参与选举的服务器的视角来模拟选主的过程；

我是一台zk服务器，我现在很慌，因为我的leader服务器不见了，作为一个有梦想的follower，我也要参加leader的选举，为了这次选举我要准备：myid(在集群中标识是这台服务器的id)，zxid(本台服务器保存的最新事务id)，logicClock(本台服务器发起的第几轮投票)

首先我会自己选自己，这得自信。于是我将自身的选举信息[myid, zxid]放到自己的收票箱，然后将我的选举信息还有我的选举轮次logicClock广播给其他服务器进行PK

作为一个有原则的服务器，我们的选举也是有原则的，当我收到别人的选举信息时，我也会将他和我自己的选举信息进行PK，PK的原则如下：

经过这一系列的PK，终于选出了我心中的leader服务器，要广播给其他服务器。

超过半数的服务器都同意某一台服务器成为leader，选举结束了。

对于多数应用来说，MySQL都是作为最关键的数据存储中心的，所以，如何让MySQL提供HA服务，是我们不得不面对的一个问题。当master当机的时候，我们如何保证数据尽可能的不丢失，如何保证快速的获知master当机并进行相应的故障转移处理，都是需要我们好好思考的。这里，笔者将结合这段时间做的MySQL proxy以及toolsets相关工作，说说我们现阶段以及后续会在项目中采用的MySQL HA方案。

Replication

要保证MySQL数据不丢失，replication是一个很好的解决方案，而MySQL也提供了一套强大的replication机制。只是我们需要知道，为了性能考量，replication是采用的asynchronous模式，也就是写入的数据并不会同步更新到slave上面，如果这时候master当机，我们仍然可能会面临数据丢失的风险。

为了解决这个问题，我们可以使用semi-synchronous replication，semi-synchronous replication的原理很简单，当master处理完一个事务，它会等待至少一个支持semi-synchronous的slave确认收到了该事件并将其写入relay-log之后，才会返回。这样即使master当机，最少也有一个slave获取到了完整的数据。

但是，semi-synchronous并不是100%的保证数据不会丢失，如果master在完成事务并将其发送给slave的时候崩溃，仍然可能造成数据丢失。只是相比于传统的异步复制，semi-synchronous replication能极大地提升数据安全。更为重要的是，它并不慢，MHA的作者都说他们在facebook的生产环境中使用了semi-synchronous（这里），所以我觉得真心没必要担心它的性能问题，除非你的业务量级已经完全超越了facebook或者google。在这篇文章里面已经提到，MySQL 57之后已经使用了Loss-Less Semi-Synchronous replication，所以丢数据的概率已经很小了。

如果真的想完全保证数据不会丢失，现阶段一个比较好的办法就是使用gelera，一个MySQL集群解决方案，它通过同时写三份的策略来保证数据不会丢失。笔者没有任何使用gelera的经验，只是知道业界已经有公司将其用于生产环境中，性能应该也不是问题。但gelera对MySQL代码侵入性较强，可能对某些有代码洁癖的同学来说不合适了:-)

我们还可以使用drbd来实现MySQL数据复制，MySQL官方文档有一篇文档有详细介绍，但笔者并未采用这套方案，MHA的作者写了一些采用drdb的问题，在这里，仅供参考。

在后续的项目中，笔者会优先使用semi-synchronous replication的解决方案，如果数据真的非常重要，则会考虑使用gelera。

Monitor

前面我们说了使用replication机制来保证master当机之后尽可能的数据不丢失，但是我们不能等到master当了几分钟才知道出现问题了。所以一套好的监控工具是必不可少的。

当master当掉之后，monitor能快速的检测到并做后续处理，譬如邮件通知管理员，或者通知守护程序快速进行failover。

通常，对于一个服务的监控，我们采用keepalived或者heartbeat的方式，这样当master当机之后，我们能很方便的切换到备机上面。但他们仍然不能很即时的检测到服务不可用。笔者的公司现阶段使用的是keepalived的方式，但后续笔者更倾向于使用zookeeper来解决整个MySQL集群的monitor以及failover。

对于任何一个MySQL实例，我们都有一个对应的agent程序，agent跟该MySQL实例放到同一台机器上面，并且定时的对MySQL实例发送ping命令检测其可用性，同时该agent通过ephemeral的方式挂载到zookeeper上面。这样，我们可以就能知道MySQL是否当机，主要有以下几种情况：

机器当机，这样MySQL以及agent都会当掉，agent与zookeeper连接自然断开

MySQL当掉，agent发现ping不通，主动断开与zookeeper的连接

Agent当掉，但MySQL未当

上面三种情况，我们都可以认为MySQL机器出现了问题，并且zookeeper能够立即感知。agent与zookeeper断开了连接，zookeeper触发相应的children changed事件，监控到该事件的管控服务就可以做相应的处理。譬如如果是上面前两种情况，管控服务就能自动进行failover，但如果是第三种，则可能不做处理，等待机器上面crontab或者supersivord等相关服务自动重启agent。

使用zookeeper的好处在于它能很方便的对整个集群进行监控，并能即时的获取整个集群的变化信息并触发相应的事件通知感兴趣的服务，同时协调多个服务进行相关处理。而这些是keepalived或者heartbeat做不到或者做起来太麻烦的。

使用zookeeper的问题在于部署起来较为复杂，同时如果进行了failover，如何让应用程序获取到最新的数据库地址也是一个比较麻烦的问题。

对于部署问题，我们要保证一个MySQL搭配一个agent，幸好这年头有了docker，所以真心很简单。而对于第二个数据库地址更改的问题，其实并不是使用了zookeeper才会有的，我们可以通知应用动态更新配置信息，VIP，或者使用proxy来解决。

虽然zookeeper的好处很多，但如果你的业务不复杂，譬如只有一个master，一个slave，zookeeper可能并不是最好的选择，没准keepalived就够了。

Failover

通过monitor，我们可以很方便的进行MySQL监控，同时在MySQL当机之后通知相应的服务做failover处理，假设现在有这样的一个MySQL集群，a为master，b，c为其slave，当a当掉之后，我们需要做failover，那么我们选择b，c中的哪一个作为新的master呢？

原则很简单，哪一个slave拥有最近最多的原master数据，就选哪一个作为新的master。我们可以通过show slave status这个命令来获知哪一个slave拥有最新的数据。我们只需要比较两个关键字段Master_Log_File以及Read_Master_Log_Pos，这两个值代表了slave读取到master哪一个binlog文件的哪一个位置，binlog的索引值越大，同时pos越大，则那一个slave就是能被提升为master。这里我们不讨论多个slave可能会被提升为master的情况。

在前面的例子中，假设b被提升为master了，我们需要将c重新指向新的master b来开始复制。我们通过CHANGE MASTER TO来重新设置c的master，但是我们怎么知道要从b的binlog的哪一个文件，哪一个position开始复制呢？

GTID

为了解决这一个问题，MySQL 56之后引入了GTID的概念，即uuid:gid，uuid为MySQL server的uuid，是全局唯一的，而gid则是一个递增的事务id，通过这两个东西，我们就能唯一标示一个记录到binlog中的事务。使用GTID，我们就能非常方便的进行failover的处理。

仍然是前面的例子，假设b此时读取到的a最后一个GTID为3E11FA47-71CA-11E1-9E33-C80AA9429562:23，而c的为3E11FA47-71CA-11E1-9E33-C80AA9429562:15，当c指向新的master b的时候，我们通过GTID就可以知道，只要在b中的binlog中找到GTID为3E11FA47-71CA-11E1-9E33-C80AA9429562:15这个event，那么c就可以从它的下一个event的位置开始复制了。虽然查找binlog的方式仍然是顺序查找，稍显低效暴力，但比起我们自己去猜测哪一个filename和position，要方便太多了。

google很早也有了一个Global Transaction ID的补丁，不过只是使用的一个递增的整形，LedisDB就借鉴了它的思路来实现failover，只不过google貌似现在也开始逐步迁移到MariaDB上面去了。

MariaDB的GTID实现跟MySQL 56是不一样的，这点其实比较麻烦，对于我的MySQL工具集go-mysql来说，意味着要写两套不同的代码来处理GTID的情况了。后续是否支持MariaDB再看情况吧。

Pseudo GTID

GTID虽然是一个好东西，但是仅限于MySQL 56+，当前仍然有大部分的业务使用的是56之前的版本，笔者的公司就是55的，而这些数据库至少长时间也不会升级到56的。所以我们仍然需要一套好的机制来选择master binlog的filename以及position。

最初，笔者打算研究MHA的实现，它采用的是首先复制relay log来补足缺失的event的方式，但笔者不怎么信任relay log，同时加之MHA采用的是perl，一个让我完全看不懂的语言，所以放弃了继续研究。

幸运的是，笔者遇到了orchestrator这个项目，这真的是一个非常神奇的项目，它采用了一种Pseudo GTID的方式，核心代码就是这个

代码如下:

create database if not exists meta;

drop event if exists metacreate_pseudo_gtid_view_event;

delimiter ;;

create event if not exists

metacreate_pseudo_gtid_view_event

on schedule every 10 second starts current_timestamp

on completion preserve

enable

do

begin

set @pseudo_gtid := uuid();

set @_create_statement := concat('create or replace view metapseudo_gtid_view as select \'', @pseudo_gtid, '\' as pseudo_gtid_unique_val from dual');

PREPARE st FROM @_create_statement;

EXECUTE st;

DEALLOCATE PREPARE st;

end

;;

delimiter ;

set global event_scheduler := 1;

它在MySQL上面创建了一个事件，每隔10s，就将一个uuid写入到一个view里面，而这个是会记录到binlog中的，虽然我们仍然不能像GTID那样直接定位到一个event，但也能定位到一个10s的区间了，这样我们就能在很小的一个区间里面对比两个MySQL的binlog了。

继续上面的例子，假设c最后一次出现uuid的位置为s1，我们在b里面找到该uuid，位置为s2，然后依次对比后续的event，如果不一致，则可能出现了问题，停止复制。当遍历到c最后一个binlog event之后，我们就能得到此时b下一个event对应的filename以及position了，然后让c指向这个位置开始复制。

使用Pseudo GTID需要slave打开log-slave-update的选项，考虑到GTID也必须打开该选项，所以个人感觉完全可以接受。

后续，笔者自己实现的failover工具，将会采用这种Pseudo GTID的方式实现。

在《MySQL High Availability》这本书中，作者使用了另一种GTID的做法，每次commit的时候，需要在一个表里面记录gtid，然后就通过这个gtid来找到对应的位置信息，只是这种方式需要业务MySQL客户端的支持，笔者不很喜欢，就不采用了。

后记

MySQL HA一直是一个水比较深的领域，笔者仅仅列出了一些最近研究的东西，有些相关工具会尽量在go-mysql中实现。

更新

经过一段时间的思考与研究，笔者又有了很多心得与收获，设计的MySQL HA跟先前有了很多不一样的地方。后来发现，自己设计的这套HA方案，跟facebook这篇文章几乎一样，加之最近跟facebook的人聊天听到他们也正在大力实施，所以感觉自己方向是对了。

新的HA，我会完全拥抱GTID，比较这玩意的出现就是为了解决原先replication那一堆问题的，所以我不会考虑非GTID的低版本MySQL了。幸运的是，我们项目已经将MySQL全部升级到56，完全支持GTID了。

不同于fb那篇文章将mysqlbinlog改造支持semi-sync replication协议，我是将go-mysql的replication库支持semi-sync replication协议，这样就能实时的将MySQL的binlog同步到一台机器上面。这可能就是我和fb方案的唯一区别了。

只同步binlog速度铁定比原生slave要快，毕竟少了执行binlog里面event的过程了，而另外真正的slaves，我们仍然使用最原始的同步方式，不使用semi-sync replication。然后我们通过MHA监控整个集群以及进行故障转移处理。

以前我总认为MHA不好理解，但其实这是一个非常强大的工具，而且真正看perl，发现也还是看的懂得。MHA已经被很多公司用于生产环境，经受了检验，直接使用绝对比自己写一个要划算。所以后续我也不会考虑zookeeper，考虑自己写agent了。

一、Zookeeper 的搭建方式

Zookeeper 安装方式有三种，单机模式和集群模式以及伪集群模式。

Zookeeper 通过复制来实现高可用性，只要集合体中半数以上的机器处于可用状态，它就能够保证服务继续。

为什么一定要超过半数呢？ 这跟 Zookeeper 的复制策略有关：Zookeeper 确保对 znode 树的每一个修改都会被复制到集合体中超过半数的机器上。

二、配置JDK环境

三、Zookeeper 单机模式搭建

1、下载 ZooKeeper ：http://mirrorshusteducn/apache/zookeeper/

2、解压

3、配置环境变量

非必须操作

4、修改 Zookeeper 的配置文件 conf/zoocfg

5、启动 ZooKeeper

四、Zookeeper 集群模式搭建

Zookeeper 集群模式搭建方案：

1、解压

2、配置环境变量

非必须操作

3、修改 Zookeeper 的配置文件

zookeeper参数说明

A ：其中 A 是一个数字，表示这个是服务器的编号；B ：是这个服务器的 ip 地址；C ：Leader 选举的端口；D ：Zookeeper 服务器之间的通信端口。

4、添加服务器标识配置 dataDir/myid

5、将修改后的zookeeper分发到其他节点

6、启动

分别在3个节点启动zookeeper

查看状态

五、 Zookeeper 伪集群模式搭建

只需将zookeper复制3份到不同的位置，配置如下

zookeeper服务脚本

1 利用节点名称的唯一性来实现共享锁

ZooKeeper抽象出来的节点结构是一个和unix文件系统类似的小型的树状的目录结构。ZooKeeper机制规定：同一个目录下只能有一个唯一的文件名。例如：我们在Zookeeper目录/test目录下创建，两个客户端创建一个名为Lock节点，只有一个能够成功。

算法思路: 利用名称唯一性，加锁操作时，只需要所有客户端一起创建/test/Lock节点，只有一个创建成功，成功者获得锁。解锁时，只需删除/test/Lock节点，其余客户端再次进入竞争创建节点，直到所有客户端都获得锁。

基于以上机制，利用节点名称唯一性机制的共享锁算法流程如图所示：

该共享锁实现很符合我们通常多个线程去竞争锁的概念，利用节点名称唯一性的做法简明、可靠。

由上述算法容易看出，由于客户端会同时收到/test/Lock被删除的通知，重新进入竞争创建节点，故存在"惊群现象"。

使用该方法进行测试锁的性能列表如下：

总结 这种方案的正确性和可靠性是ZooKeeper机制保证的，实现简单。缺点是会产生“惊群”效应，假如许多客户端在等待一把锁，当锁释放时候所有客户端都被唤醒，仅仅有一个客户端得到锁。

2 利用临时顺序节点实现共享锁的一般做法

首先介绍一下，Zookeeper中有一种节点叫做顺序节点，故名思议，假如我们在/lock/目录下创建节3个点，ZooKeeper集群会按照提起创建的顺序来创建节点，节点分别为/lock/0000000001、/lock/0000000002、/lock/0000000003。

ZooKeeper中还有一种名为临时节点的节点，临时节点由某个客户端创建，当客户端与ZooKeeper集群断开连接，则开节点自动被删除。

利用上面这两个特性，我们来看下获取实现分布式锁的基本逻辑：

客户端调用create()方法创建名为“locknode/guid-lock-”的节点，需要注意的是，这里节点的创建类型需要设置为EPHEMERAL_SEQUENTIAL。

客户端调用getChildren(“locknode”)方法来获取所有已经创建的子节点，同时在这个节点上注册上子节点变更通知的Watcher。

客户端获取到所有子节点path之后，如果发现自己在步骤1中创建的节点是所有节点中序号最小的，那么就认为这个客户端获得了锁。

如果在步骤3中发现自己并非是所有子节点中最小的，说明自己还没有获取到锁，就开始等待，直到下次子节点变更通知的时候，再进行子节点的获取，判断是否获取锁。

释放锁的过程相对比较简单，就是删除自己创建的那个子节点即可。

上面这个分布式锁的实现中，大体能够满足了一般的分布式集群竞争锁的需求。这里说的一般性场景是指集群规模不大，一般在10台机器以内。

不过，细想上面的实现逻辑，我们很容易会发现一个问题，步骤4，“即获取所有的子点，判断自己创建的节点是否已经是序号最小的节点”，这个过程，在整个分布式锁的竞争过程中，大量重复运行，并且绝大多数的运行结果都是判断出自己并非是序号最小的节点，从而继续等待下一次通知——这个显然看起来不怎么科学。客户端无端的接受到过多的和自己不相关的事件通知，这如果在集群规模大的时候，会对Server造成很大的性能影响，并且如果一旦同一时间有多个节点的客户端断开连接，这个时候，服务器就会像其余客户端发送大量的事件通知——这就是所谓的惊群效应。而这个问题的根源在于，没有找准客户端真正的关注点。

我们再来回顾一下上面的分布式锁竞争过程，它的核心逻辑在于：判断自己是否是所有节点中序号最小的。于是，很容易可以联想的到的是，每个节点的创建者只需要关注比自己序号小的那个节点。

3、利用临时顺序节点实现共享锁的改进实现

下面是改进后的分布式锁实现，和之前的实现方式唯一不同之处在于，这里设计成每个锁竞争者，只需要关注”locknode”节点下序号比自己小的那个节点是否存在即可。

算法思路：对于加锁操作，可以让所有客户端都去/lock目录下创建临时顺序节点，如果创建的客户端发现自身创建节点序列号是/lock/目录下最小的节点，则获得锁。否则，监视比自己创建节点的序列号小的节点（比自己创建的节点小的最大节点），进入等待。

对于解锁操作，只需要将自身创建的节点删除即可。

具体算法流程如下图所示:

使用上述算法进行测试的的结果如下表所示：

该算法只监控比自身创建节点序列号小(比自己小的最大的节点)的节点，在当前获得锁的节点释放锁的时候没有“惊群”。

总结 利用临时顺序节点来实现分布式锁机制其实就是一种按照创建顺序排队的实现。这种方案效率高，避免了“惊群”效应，多个客户端共同等待锁，当锁释放时只有一个客户端会被唤醒。

4、使用menagerie

其实就是对方案3的一个封装，不用自己写代码了。直接拿来用就可以了。

menagerie基于Zookeeper实现了javautilconcurrent包的一个分布式版本。这个封装是更大粒度上对各种分布式一致性使用场景的抽象。其中最基础和常用的是一个分布式锁的实现： orgmenagerielocksReentrantZkLock，通过ZooKeeper的全局有序的特性和EPHEMERAL_SEQUENTIAL类型znode的支持，实现了分布式锁。具体做法是：不同的client上每个试图获得锁的线程，都在相同的basepath下面创建一个EPHEMERAL_SEQUENTIAL的node。EPHEMERAL表示要创建的是临时znode，创建连接断开时会自动删除； SEQUENTIAL表示要自动在传入的path后面缀上一个自增的全局唯一后缀,作为最终的path。因此对不同的请求ZK会生成不同的后缀，并分别返回带了各自后缀的path给各个请求。因为ZK全局有序的特性，不管client请求怎样先后到达，在ZKServer端都会最终排好一个顺序，因此自增后缀最小的那个子节点，就对应第一个到达ZK的有效请求。然后client读取basepath下的所有子节点和ZK返回给自己的path进行比较，当发现自己创建的sequential node的后缀序号排在第一个时，就认为自己获得了锁；否则的话，就认为自己没有获得锁。这时肯定是有其他并发的并且是没有断开的client/线程先创建了node。

然后每个文件夹里面解压一个zookeeper的下载包，并且还建了几个文件夹，总体结构如下,最后那个是下载过来压缩包的解压文件

data dataLog logs zookeeper-332

那么首先进入data目录，创建一个myid的文件，里面写入一个数字，比如我这个是server1,那么就写一个1，server2对应myid文件就写入2，server3对应myid文件就写个3

然后进入zookeeper-332/conf目录，那么如果是刚下过来，会有3个文件，configurationxml, log4jproperties,zoo_samplecfg,这3个文件我们首先要做的就是在这个目录创建一个zoocfg的配置文件，当然你可以把zoo_samplecfg文件改成zoocfg，配置的内容如下所示：

tickTime=2000

initLimit=5

syncLimit=2

dataDir=xxxx/zookeeper/server1/data

dataLogDir=xxx/zookeeper/server1/dataLog

clientPort=2181

server1=127001:2888:3888

server2=127001:2889:3889

server3=127001:2890:3890

标红的几个配置应该官网讲得很清楚了，只是需要注意的是clientPort这个端口如果你是在1台机器上部署多个server,那么每台机器都要不同的clientPort，比如我server1是2181,server2是2182，server3是2183，dataDir和dataLogDir也需要区分下。

最后几行唯一需要注意的地方就是 serverX 这个数字就是对应 data/myid中的数字。你在3个server的myid文件中分别写入了1，2，3，那么每个server中的zoocfg都配server1,server2,server3就OK了。因为在同一台机器上，后面连着的2个端口3个server都不要一样，否则端口冲突，其中第一个端口用来集群成员的信息交换，第二个端口是在leader挂掉时专门用来进行选举leader所用。

进入zookeeper-332/bin 目录中，/zkServersh start启动一个server,这时会报大量错误？其实没什么关系，因为现在集群只起了1台server，zookeeper服务器端起来会根据zoocfg的服务器列表发起选举leader的请求，因为连不上其他机器而报错，那么当我们起第二个zookeeper实例后，leader将会被选出，从而一致性服务开始可以使用，这是因为3台机器只要有2台可用就可以选出leader并且对外提供服务(2n+1台机器，可以容n台机器挂掉)。

接下来就可以使用了，我们可以先通过 zookeeper自带的客户端交互程序来简单感受下zookeeper到底做一些什么事情。进入zookeeper-332/bin（3个server中任意一个）下，/zkClish –server 127001:2182,我连的是开着2182端口的机器。

那么，首先我们随便打个命令，因为zookeeper不认识，他会给出命令的help,如下图

ls(查看当前节点数据),

ls2(查看当前节点数据并能看到更新次数等数据) ,

create(创建一个节点) ,

get(得到一个节点，包含数据和更新次数等数据),

set(修改节点)

delete(删除一个节点)

通过上述命令实践，我们可以发现，zookeeper使用了一个类似文件系统的树结构，数据可以挂在某个节点上，可以对这个节点进行删改。另外我们还发现，当改动一个节点的时候，集群中活着的机器都会更新到一致的数据。