散布式化网站遇到的典型问题

在大型散布式互联网零碎中，session问题是典型的散布式化过程当中会遇到的难题。由于session数据必需在服务真个机械中同享，并要包管状况的一致性。

zookeeper是一个散布式的，开放源码的散布式应用程序协调服务，它是一个为散布式应用提供一~致性服务的软件，所提供的功用包括:设置维护、域名服务、散布式同步、组服务等。下面咱们引见一下典型的散布式环境下遇到的一些典型问题的解决法子。

1.集群管理(group membership)

zookeeper可能很容易地实现集群管理的功用，如图1.15所示。若是多台server构成一个服务集群，那末必需有一个“总管”知道当前集群中每台机械的服务状况，一旦有机械不克不及提供服务，就必需知会合群中的其余集群，并从头分配服务战略。一样，当集群的服务威力添加时，就会添加一台或多台server， 这些也必需让“总管”知道。

zo0 keeper不只可能维护当前集群中机械的服务状况，并且可能选出一个“总管”，让“总管”来管理集群一这就是 zookeeper i的另外一个功用 leader election。

它的实现体式格局是在 zookeeper上创立一个 ephemeral类型的目次节点，而后每一个 server在它们创立目次节点的父目次节点上挪用 getchildrenf string path， boolean watch)要领并设置 watch为true。由于是 ephemeral目次节点，当创立它的 server死去时，这个目次节点也随之被删除，以是 children将会变革；这时候 get children上的watch将会被挪用，告诉其余 server某台 server已死了。新增 server也是一样的道理。

那末，z0 keeper怎样实现 leader election，也就是选出一个 master server呢?和前面的一样，每台 server创立一个 ephiemeral目次节点，差别的是它仍是一个sequential目次节点，以是它是个 ephemeral sequential目次节点。之以是它是 ephemeral sequential目次节点，是由于咱们可以给每台 server g编号。

咱们可以选择当前最小编号的 server为 master，假设这个最小编号的 server死去，由于它是 ephemeral节点，死去的 server对应的节点也被删除，以是在当前的节点列表中又泛起一个最小编号的节点，咱们就选择这个节点为当前 master。如许就实现了动态选择 master，制止传统上单 master容易泛起的单点故障问题。

2.同享锁( locks)

在统一个进程中，同享锁很容易实现，可是在跨进程或者差别 server的情况下就欠好实现了。然而 zookeeper能很容易地实现这个功用，它的实现体式格局也是经由过程得到锁的 server创立一个 ephemeral sequential目次节点，再经由过程挪用 getchildren要领，查询当前的目次节点列表中最小的目次节点是否是本身创立的目次节点，若是是本身创立的，那末它就得到了这个锁；若是否是，那末它就挪用 exists(string path，boolean watch)要领，并监控 zookeeper上目次节点列表的变革，直到使本身创立的节点是列表中最小编号的目次节点，从而得到锁。开释锁很简略，只有删除前面它本身所创立的目次节点便可。

3.队列管理

keener可之外理以下两种型的队列

其一，同队伍列。即当一个队列的成员都聚齐时，这个队列才可用，不然一直等候一切成员达到。

其二，队列根据fifo体式格局进行入队和出队操纵，比方实现出产者和消费者模子。用zo0 keeper实现同队伍列的实现思绪以下。

创立一个父目次/ synchronizing，每一个成员都监控标志( set watch)位目次/ synchronizing/start是否存在，而后每一个成员都加人这个队列；

加人队列的体式格局就是创立 /synchronizing/member i的姑且目次节点，之后每一个成员获取/ synchronizing目次的一切目次节点，也就是 member_i；?判断i的值是否曾经是成员的个数，若是小于成员个数等候/ 'synchronizing/ start的泛起，若是曾经相称就创立 /synchronizing/star。

用 zookeeper实现fifo队列的思绪以下。

在特定的网站建设目次下创立 sequential类型的子目次 queue i，如许就能包管一切成员插手队列时都是有编号的；出队列时经由过程 get children()要领返回当前一切队列中元素，再消费此中最小的一个，如许就能包管fifo。