zookeeper的热备

【题外话】

今天开了一天会的感觉。很多具体的事情都没有做。令我感到兴奋的事情，倒是有一件。我从其他渠道获取了一道网易的面试题。做起来特别有意思。

题目是这样的：有一个数组A{22,34,455,332,678,334,3} 将其组成一个最大的整数。

这道题的答案是 67845534334333222

我是这样算的，过程如下：{34,349}

1.先把数据解构，生成{22} {3,34,332,334} {455}{678}四个数组

2.启动4个线程，去将这四个数组分别求出最大的拼接数

        遍历数组，将数字转化成为最长的位数，然后对新的数组进行排序，排序后的序列就是之前的数组的排序。转化规则是3转化成为333,34转化成为344，这样的规则。

3.将4个线程执行的结果放在一个地方

4.按照首数字降序进行拼接

{3,34,332,334}=》{333,343,332,334}排序结果为{343,334,333,332}=》故最大数为3433343332 

我觉得我的这个过程不会太慢。我很自信。当然不采用多线程直接这样处理也可以。主要思想是：将这个问题转化成为排序问题。

zookeeper的监控明天再说了。

 

【题外话】2016-4-7

今天帮助俊哥去搬家了。帮助别人会让我内心感到快乐。我希望我能一直这样。

最近我和室友熊熊一起逛了很多地方。知道了很多fashion的元素，ZARA，阿迪，old nav，newbalance，HM...开始走进我的生活。我想，生活需要一点点儿的新鲜元素。嘿嘿。

 

继续接着昨天的学习。使用zookeeper进行分布式监控管理机器。 Zookeeper同样很容易实现这个功能，比如我在zookeeper服务器端有一个znode叫/APP1SERVERS,那么集群中每一个机器启动的时候都去这个节点下创建一个EPHEMERAL类型的节点，比如server1创建/APP1SERVERS/SERVER1(可以使用ip,保证不重复)，server2创建/APP1SERVERS/SERVER2，然后SERVER1和SERVER2都watch/APP1SERVERS这个父节点，那么也就是这个父节点下数据或者子节点变化都会通知对该节点进行watch的客户端。因为EPHEMERAL类型节点有一个很重要的特性，就是客户端和服务器端连接断掉或者session过期就会使节点消失，那么在某一个机器挂掉或者断链的时候，其对应的节点就会消失，然后集群中所有对/APP1SERVERS进行watch的客户端都会收到通知。

通过这种方式进行建立监控：

ZooKeeper zk = new ZooKeeper("127.0.0.1:2181", 500000,new Watcher() {
           // 监控所有被触发的事件
             public void process(WatchedEvent event) {
           //dosomething
           }
      });

 

我明日会去做相应的测试。

 

【题外话】2016-4-10

今天过来继续学习zookeeper。

北京的天气还可以。

 

zookeeper具备两大特性：

1.客户端如果对ZooKeeper的一个数据节点注册Watcher监听，那么当该数据节点的内容或者是其子节点列表发生变更时，Zookeeper服务器就会向订阅的客户端发送变更通知。

2.对zookeeper上创建的临时节点，一旦客户端与服务器之间的会话失效，那么该临时节点也就被自动清除。

 

zookeeper中的节点类型：

1.持久点（PERSISTENT）

2.临时点（EPHEMERAL）

3.顺序节点（SEQUENTIAL）

在创建时可以生成

1.持久节点（PERSISTENT）

2.持久顺序节点（PERSISTENT_SEQUENTIAL）

3.临时节点（EPHEMERAL）

4.临时顺序节点（EPHEMERAL_SEQUENTIAL）

 

【题外话】4-13

 今天继续学习zookeeper。现在是北京时间 2016 4-14 02:09分。北京的夜晚很安静。

 

zookeeper是一个典型的发布/订阅模式的分布式数据管理与协调框架，开发人员可以使用他来进行分布式数据的发布和订阅。另一方面，通过对zookeeper中丰富的数据节点类型进行交叉使用，配合Watcher事件通知机制，可以非常方便地构建一系列分布式应用中都会涉及的核心功能，如数据的发布/订阅，负载均衡、命名服务、分布式协调/通知、集群管理、master选举、分布式锁、和分布式队列。

 

任务热备份

 

为了应对复制任务故障或者复制任务所在主机故障，复制组件采用“热备份”的容灾方式，即将同一个复制任务部署在不同的主机上，我们称这样的机器为“任务机器”，主、备任务机器通过zookeeper相互检测运行的健康状态。

 

为了实现上述热备方案，无论在第一步中是否创建了任务节点，每台任务任务机器都需要在/mysql_replicator/task/copy_hot_item/instance节点上将自己的主机名注册上去。注意，这里的注册节点类型很特殊，是一个临时的顺序节点。最后的序列号就是临时顺序节点的精华所在。

 

在完成该子节点的创建后，每台任务机器都可以获得自己创建的节点的完成节点名以及所有子节点的列表，然后通过对比判断自己是不是所有子节点中序号最小的。如果自己的序号是最新的子节点，那么就将自己的运行状态设置为RUNNING，其余的任务机器则将自己的运行状态设置为STANDBY---小序号优先策略。

 

热备切换

 

完成运行状态的标识后，任务的客户机器就能正常工作了，其中标记为RUNNING的客户机机器进行正常的数据复制，而标记为STANDBY的客户机器则进入待命状态。这里的待命状态，就是说一旦标记为RUNNING的机器出现故障停止了任务执行，那么就需要在所有标记为STANDBY的客户机中再次按照’小号优先‘策略选出RUNNING的机器来执行。具体做法就是标记为STANDBY的机器都需要在节点上注册一个子节点列表变更的Watcher监听，用来订阅所有任务执行机器的变化情况，一旦RUNNING机器宕机与ZOOkeeper断开连接之后，对应的节点就会消失，于是其他机器也就收到了这个变更通知，从而开始新的RUNNING选举。

 

今天就学到这里。全部都是热备的知识。