zookeeper 和分布式系统的一般问题

什么是分布式系统，就是系统由多台机器组成，每台机器上有不同的role，mediaroom就是典型的分布式系统。具体化一下，多台机器其实就是多process，不要觉得机器上有很多程序，在系统设计领域，说一台机器实质上就是说一个process。只不过是不同机器上的process，和同一台机器上的多进程相比，不能用OS系统调用或者本地磁盘的机制进行同步或者数据共享。

process是什么就是一个封装或者隔离，逻辑和相关数据的一个封装，隔离是说，这个process挂了，不会影响遇到别的process。线程也有一定隔离性，一个线程的run方法内的异常捕获了，理论上不会使程序崩溃，但这个是不保险的。

多进程 vs 单进程内多线程

安全性：单进程多线程模式，一个进程挂了，服务就挂了，一个线程有可能使进程挂；多进程的，一个进程挂了还有别的进程。

升级、部署方便：多进程模式，每个进程可以对应一个binary 副本，这样可以有灰度，先升级一个跑着看看，慢慢升级。而多线程模式，无法做到先让一个线程跑新的代码

再回到分布式（不同机器上的process)，由于没有共同的host OS, 这些process也需要数据交换和同步，怎么办？ 需要一个中介，zookeeper就是干这个的。

zookeeper维护一个树形的类似文件系统的东西，并且支持变化通知，以及EPHEMERAL节点，  做为实现各种同步、协调的支持机制。

经典应用：

1）NameService 

不多说，本身就是一个共享的树形文件系统

2）配置管理

不同的process watch 自己的配置znode, 当配置变化可以收到通知

3）集群membership管理

集群节点下，每个server对应一个EPHEMERAL的节点，节点名就是server name/ IP，当它和zookeeper的心跳断了，对应的节点被删除，并且所有集群内的节点可以收到新的child List，保证每个server都知道进群内的其他server

4) master 选举

和3）类似，但是节点换成EPHEMERAL_SEQUENTIAL的，大家都约定以当前编号最小的server做为master。当master挂了，每个server都会被通知到一份新的server 列表，大家都把编号最小的那个作为master

5) 分布式独占锁，类似java synchronized的语义

在约定的锁节点上创建EPHEMERAL_SEQUENTIAL节点作为等待队列，如果编号最小的就是自己就获得锁，否则wait()住。获得锁的process通过删除自己的节点释放锁，这样每个等待的process会得到通知，在事件处理函数里判断自己是不是最小的编号，如果是则唤醒之前wait住的线程，这样本进程就获得了锁。

6）barrier 屏障

意思是所有相关的process都到达齐了再往下执行。实现方法，也是在barrier节点创建EPHEMERAL_SEQUENTIAL的节点，每个process都会得到变化后的children list，当大小为barrier要求数的时候，各个process继续执行。

zookeeper作为分布式process协调的中介，本身是一个单点failure点，所以它本身也做为一个集群，通常部署2n + 1台， 客户端连接不同的zookeeper server，但是得到视图是一样的，这点是zookeeper内部保证的

想想 mediaroom里的 分布式process之间的协调

1）主要是基于数据库表（importstatus, job, cdtask等表）的工作队列 + timer-base-pull controller，队列里的job即有job本身的数据，又有用来维护job执行的状态的field。

2) 同步交给数据库transaction，比如多个controller同时拿job

3)其实很costly的方式，但编程简单。主要是controller少。

4）主从的情况，standby的process主动的周期性个check master的 last ping, 超时则take over, 大家通过isMaster 字段得知谁是master，