【架构】zookeeper在分布式应用中的重要作用

zookeeper是为了“分布式”而诞生的,我反复在说“分布式”,并不是赶潮流,而是被潮流推着向前。在任何互联网生产应用中,哪怕你的公司规模小,访问量用一台服务器足够应付,仍然不能容忍当服务器故障时,没有备用的服务器可切换,这个称为“防止单点故障”,因为你至少要用两台服务器来防止单点故障,所以你已经在“分布式”的服务环境里。

 

我们来回顾上一次讲的话题,我把应用层的通用服务分为“读”服务和“写”服务,“读”服务用集群来实现高可用高性能,而“写”服务用单台服务器来保证事务顺序执行。

那么,“单台服务器”听上去好危险的样子,于是今天的主角登场,我们需要zookeeper

 

你也许听到过,这种应用场景叫做master/slave,或者我更喜欢称为主/备模式,在这种场景下,我有两台服务器(主和备),任何情况下,只有“主”在工作,“备”是在主出现故障时,接替“主”来提供服务。在zookeeper的支持下,这一过程是这样实现的,

 

Zookeeper提供目录和节点的服务,当我的两台服务器启动时,会在zookeeper的指定目录下创建对应自己的临时节点(这个过程称为“注册”),所谓临时节点,是靠心跳(定时向zookeeper服务器发送数据包)维系,当服务器出现故障(无法向zookeeper服务器发送数据包),zookeeper会删除临时节点。服务器向zookeeper注册时,zookeeper会分配序列号,我们认为序列号小的那个,就是“主”,序列号大的那个,就是“备”。

 

当我们的客户端(通常是web server)需要访问“写”服务时,需要连接zookeeper,获得指定目录下的临时节点列表,也就是已经注册的服务器信息,获得序列号小的那台“主”服务器的地址,进行后续的访问操作。以达到“总是访问主服务器”的目的。

 

当“主”服务器发生故障,zookeeper从指定目录下删除对应的临时节点,同时可以通知关心这一变化的所有客户端,高效且迅速的传播这一信息,你想一想,如果不是使用zookeeper,要自己实现这个功能,可没。。。那么简单(不许唱!)

 

我们为了消除单点故障而使用的主/备模式依赖zookeeper,那么zookeeper可不能有单点故障,所以zookeeper在诞生的时候,就是用集群的模式工作,用多台服务器来消除自身的单点故障隐患,怎么样,无可挑剔吧。

 

总结,在多核并行计算模式下,我认定基于消息传递的actor模型(源自erlang)是正确的编程方式,在actor模型下,可以简单实现基于服务层的串行操作,保证“写”操作的完整和一致。使用actor模型,需要用主/备的部署架构来消除单点故障,实现主/备的部署架构,最简单可靠的方法是使用zookeeper。所以我现在的软件架构是这么推导出来的

高并发需求 -> 异步计算 (使用actor model) -> master/slave (使用zookeeper)

展开阅读全文

没有更多推荐了,返回首页