分布式系统为什么要同步，同步所需要的构件有哪些

在Zookeeper的官 网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services 这大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服务，提供分布式同步以及集群管理。那这些服务又到底是什么呢？我们为什么需要这样的服务？我们又为什么要使用Zookeeper来实现呢，使用Zookeeper有什么优势？接下来我会挨个介绍这些到底是什么，以及有哪些开源系统中使用了。配置管理在我们的应用中除了代码外，还有一些就是各种配置。比如数据库连接等。一般我们都是使用配置文件的方式，在代码中引入这些配置文件。但是当我们只有一种配置，只有一台服务器，并且不经常修改的时候，使用配置文件是一个很好的做法，但是如果我们配置非常多，有很多服务器都需要这个配置，而且还可能是动态的话使用配置文件就不是个好主意了。这个时候往往需要寻找一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得变更。比如我们可以把配置放在数据库里，然后所有需要配置的服务都去这个数据库读取配置。但是，因为很多服务的正常运行都非常依赖这个配置，所以需要这个集中提供配置服务的服务具备很高的可靠性。一般我们可以用一个集群来提供这个配置服务，但是用集群提升可靠性，那如何保证配置在集群中的一致性呢？ 这个时候就需要使用一种实现了一致性协议的服务了。Zookeeper就是这种服务，它使用Zab这种一致性协议来提供一致性。现在有很多开源项目使用Zookeeper来维护配置，比如在HBase中，客户端就是连接一个Zookeeper，获得必要的HBase集群的配置信息，然后才可以进一步 *** 作。还有在开源的消息队列Kafka中，也使用Zookeeper来维护broker的信息。在Alibaba开源的SOA框架Dubbo中也广泛的使用Zookeeper管理一些配置来实现服务治理。名字服务名字服务这个就很好理解了。比如为了通过网络访问一个系统，我们得知道对方的IP地址，但是IP地址对人非常不友好，这个时候我们就需要使用域名来访问。但是计算机是不能是别域名的。怎么办呢？如果我们每台机器里都备有一份域名到IP地址的映射，这个倒是能解决一部分问题，但是如果域名对应的IP发生变化了又该怎么办呢？于是我们有了DNS这个东西。我们只需要访问一个大家熟知的(known)的点，它就会告诉你这个域名对应的IP是什么。在我们的应用中也会存在很多这类问题，特别是在我们的服务特别多的时候，如果我们在本地保存服务的地址的时候将非常不方便，但是如果我们只需要访问一个大家都熟知的访问点，这里提供统一的入口，那么维护起来将方便得多了。分布式锁其实在第一篇文章中已经介绍了Zookeeper是一个分布式协调服务。这样我们就可以利用Zookeeper来协调多个分布式进程之间的活动。比如在一个分布式环境中，为了提高可靠性，我们的集群的每台服务器上都部署着同样的服务。但是，一件事情如果集群中的每个服务器都进行的话，那相互之间就要协调，编程起来将非常复杂。而如果我们只让一个服务进行 *** 作，那又存在单点。通常还有一种做法就是使用分布式锁，在某个时刻只让一个服务去干活，当这台服务出问题的时候锁释放，立即fail over到另外的服务。这在很多分布式系统中都是这么做，这种设计有一个更好听的名字叫Leader Election(leader选举)。比如HBase的Master就是采用这种机制。但要注意的是分布式锁跟同一个进程的锁还是有区别的，所以使用的时候要比同一个进程里的锁更谨慎的使用。集群管理在分布式的集群中，经常会由于各种原因，比如硬件故障，软件故障，网络问题，有些节点会进进出出。有新的节点加入进来，也有老的节点退出集群。这个时候，集群中其他机器需要感知到这种变化，然后根据这种变化做出对应的决策。比如我们是一个分布式存储系统，有一个中央控制节点负责存储的分配，当有新的存储进来的时候我们要根据现在集群目前的状态来分配存储节点。这个时候我们就需要动态感知到集群目前的状态。还有，比如一个分布式的SOA架构中，服务是一个集群提供的，当消费者访问某个服务时，就需要采用某种机制发现现在有哪些节点可以提供该服务(这也称之为服务发现，比如Alibaba开源的SOA框架Dubbo就采用了Zookeeper作为服务发现的底层机制)。还有开源的Kafka队列就采用了Zookeeper作为Cosnumer的上下线管理。后记在这篇文章中，列出了一些Zookeeper可以提供的服务，并给出了一些开源系统里面的实例。后面我们从Zookeeper的安装配置开始，并用示例进一步介绍Zookeeper如何使用。(转载）

简介ZooKeeper是Hadoop的正式子项目，它是一个针对大型分布式系统的可靠协调系统，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
Zookeeper是Google的Chubby一个开源的实现是高有效和可靠的协同工作系统Zookeeper能够用来leader选举,配置信息维护等在一个分布式的环境中,我们需要一个Master实例或存储一些配置信息,确保文件写入的一致性等[1]
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，包含一个简单的原语集，是Hadoop和Hbase的重要组件。

说白了是hadoop的组件之一，用来管理hadoop。

安装jsvc（利用tomcat方式）：

进入tomcat下面的bin目录：

[root@tomcat ~]# cd /opt/tomcat/bin/

[root@tomcat bin]# tar xf commons-daemon-nativetargz

[root@tomcat bin]# cd commons-daemon-1015-native-src/unix/

[root@tomcat unix]# /configure --with-java=$JAVA_HOME



All done

Now you can issue "make"                      

[root@tomcat unix]# make

编译完成后，会在当前文件夹生成一个jsvc的文件，将它拷贝到/opt/tomcat/bin/下：

tomcat目录可自行设置

[root@tomcat unix]# cp jsvc /opt/tomcat/bin/

安装jsvc（无tomcat方式，利用commons-daemon-nativetargz和commons-daemon-110jar）

将commons-daemon-nativetargz放到某个目录，这里放到/opt/jsvc

[root@localhost jsvc]# cd /opt/jsvc

[root@localhost jsvc]# ll

total 404

-rw-r--r-- 1 root root  25145 Aug 15 23:03 commons-daemon-110jar

drwxr-xr-x 4 root root    109 Aug 15 23:03 commons-daemon-110-native-src

-rw-r--r-- 1 root root 207125 Aug 15 23:03 commons-daemon-110-native-srctargz

-rwxr-xr-x 1 root root 174312 Aug 15 23:05 jsvc

解压commons-daemon-110-native-srctargz

[root@localhost jsvc]# tar -xvf commons-daemon-110-native-srctargz

commons-daemon-110-native-src/LICENSEtxt

commons-daemon-110-native-src/RELEASE-NOTEStxt

commons-daemon-110-native-src/NOTICEtxt

commons-daemon-110-native-src/README

commons-daemon-110-native-src/unix/

commons-daemon-110-native-src/unix/man/

commons-daemon-110-native-src/unix/native/

commons-daemon-110-native-src/unix/support/

commons-daemon-110-native-src/unix/configurein

commons-daemon-110-native-src/unix/INSTALLtxt

commons-daemon-110-native-src/unix/man/jsvc1xml

commons-daemon-110-native-src/unix/man/README

commons-daemon-110-native-src/unix/native/debugc

commons-daemon-110-native-src/unix/native/indentpro

commons-daemon-110-native-src/unix/native/locksh

commons-daemon-110-native-src/unix/native/helpc

commons-daemon-110-native-src/unix/native/replacec

commons-daemon-110-native-src/unix/native/javac

commons-daemon-110-native-src/unix/native/replaceh

commons-daemon-110-native-src/unix/native/helph

commons-daemon-110-native-src/unix/native/signalsc

commons-daemon-110-native-src/unix/native/jsvc-unixc

commons-daemon-110-native-src/unix/native/locationh

commons-daemon-110-native-src/unix/native/locksc

commons-daemon-110-native-src/unix/native/homeh

commons-daemon-110-native-src/unix/native/debugh

commons-daemon-110-native-src/unix/native/javah

commons-daemon-110-native-src/unix/native/versionh

commons-daemon-110-native-src/unix/native/argumentsh

commons-daemon-110-native-src/unix/native/dsoh

commons-daemon-110-native-src/unix/native/homec

commons-daemon-110-native-src/unix/native/Makefilein

commons-daemon-110-native-src/unix/native/locationc

commons-daemon-110-native-src/unix/native/signalsh

commons-daemon-110-native-src/unix/native/dso-dlfcnc

commons-daemon-110-native-src/unix/native/dso-dyldc

commons-daemon-110-native-src/unix/native/jsvch

commons-daemon-110-native-src/unix/native/argumentsc

commons-daemon-110-native-src/unix/Makedefsin

commons-daemon-110-native-src/unix/support/configguess

commons-daemon-110-native-src/unix/support/apsupportm4

commons-daemon-110-native-src/unix/support/configsub

commons-daemon-110-native-src/unix/support/apfunctionsm4

commons-daemon-110-native-src/unix/support/apjavam4

commons-daemon-110-native-src/unix/Makefilein

commons-daemon-110-native-src/unix/configure

commons-daemon-110-native-src/unix/man/fetchsh

commons-daemon-110-native-src/unix/support/mkdistsh

commons-daemon-110-native-src/unix/support/installsh

commons-daemon-110-native-src/unix/support/buildconfsh

commons-daemon-110-native-src/windows/

commons-daemon-110-native-src/windows/apps/

commons-daemon-110-native-src/windows/apps/prunmgr/

commons-daemon-110-native-src/windows/apps/prunsrv/

commons-daemon-110-native-src/windows/include/

commons-daemon-110-native-src/windows/resources/

commons-daemon-110-native-src/windows/xdocs/

commons-daemon-110-native-src/windows/src/

commons-daemon-110-native-src/windows/apps/prunmgr/prunmgrc

commons-daemon-110-native-src/windows/apps/prunmgr/Makefile

commons-daemon-110-native-src/windows/apps/prunmgr/prunmgrmanifest

commons-daemon-110-native-src/windows/apps/prunmgr/prunmgrh

commons-daemon-110-native-src/windows/apps/prunsrv/prunsrvmanifest

commons-daemon-110-native-src/windows/apps/prunsrv/Makefile

commons-daemon-110-native-src/windows/apps/prunsrv/prunsrvc

commons-daemon-110-native-src/windows/apps/prunsrv/prunsrvh

commons-daemon-110-native-src/windows/include/consoleh

commons-daemon-110-native-src/windows/include/cmdlineh

commons-daemon-110-native-src/windows/include/apxwinh

commons-daemon-110-native-src/windows/include/Makefileinc

commons-daemon-110-native-src/windows/include/javajnih

commons-daemon-110-native-src/windows/include/guih

commons-daemon-110-native-src/windows/include/handlesh

commons-daemon-110-native-src/windows/include/serviceh

commons-daemon-110-native-src/windows/include/registryh

commons-daemon-110-native-src/windows/include/logh

commons-daemon-110-native-src/windows/include/rprocessh

commons-daemon-110-native-src/windows/resources/licensertf

commons-daemon-110-native-src/windows/xdocs/indexxml

commons-daemon-110-native-src/windows/src/javajnic

commons-daemon-110-native-src/windows/src/mclibh

commons-daemon-110-native-src/windows/src/consolec

commons-daemon-110-native-src/windows/src/servicec

commons-daemon-110-native-src/windows/src/handlesc

commons-daemon-110-native-src/windows/src/utilsc

commons-daemon-110-native-src/windows/src/registryc

commons-daemon-110-native-src/windows/src/mclibc

commons-daemon-110-native-src/windows/src/privateh

commons-daemon-110-native-src/windows/src/cmdlinec

commons-daemon-110-native-src/windows/src/guic

commons-daemon-110-native-src/windows/src/rprocessc

commons-daemon-110-native-src/windows/src/logc

commons-daemon-110-native-src/windows/README

commons-daemon-110-native-src/windows/apps/prunmgr/prunmgrrc

commons-daemon-110-native-src/windows/apps/prunsrv/prunsrvrc

commons-daemon-110-native-src/windows/resources/susersbmp

commons-daemon-110-native-src/windows/resources/commonsbmp

commons-daemon-110-native-src/windows/resources/procrunsico

commons-daemon-110-native-src/windows/resources/procrunrico

commons-daemon-110-native-src/windows/resources/procrunwico

[root@localhost jsvc]# ls

commons-daemon-110jar  commons-daemon-110-native-src  commons-daemon-110-native-srctargz

进入commons-daemon-110-native-src/unix目录

[root@localhost jsvc]# cd src

[root@localhost commons-daemon-110-native-src]# ls

LICENSEtxt  NOTICEtxt  README  RELEASE-NOTEStxt  unix  windows

[root@localhost commons-daemon-110-native-src]# cd unix

[root@localhost unix]# ls

configure  configurein  INSTALLtxt  Makedefsin  Makefilein  man  native  support

查找当前环境java_home目录

[root@localhost unix]# find / -name java

/etc/pki/ca-trust/extracted/java

/etc/pki/java

/etc/alternatives/java

/var/lib/alternatives/java

/usr/bin/java

/usr/local/zookeeper-3412/contrib/loggraph/src/java

/usr/local/zookeeper-3412/contrib/fatjar/src/java

/usr/local/zookeeper-3412/contrib/ZooInspector/src/java

/usr/local/zookeeper-3412/recipes/election/src/java

/usr/local/zookeeper-3412/recipes/queue/src/java

/usr/local/zookeeper-3412/recipes/lock/src/java

/usr/local/zookeeper-3412/src/contrib/rest/src/java

/usr/local/zookeeper-3412/src/contrib/loggraph/src/java

/usr/local/zookeeper-3412/src/contrib/zooinspector/src/java

/usr/local/zookeeper-3412/src/contrib/fatjar/src/java

/usr/local/zookeeper-3412/src/recipes/election/src/java

/usr/local/zookeeper-3412/src/recipes/queue/src/java

/usr/local/zookeeper-3412/src/recipes/lock/src/java

/usr/local/zookeeper-3412/src/java

/usr/java

/usr/java/jdk180_171-amd64/bin/java

/usr/java/jdk180_171-amd64/jre/bin/java

检查java环境是否正确

[root@localhost unix]# /configure --with-java=/usr/java/jdk180_171-amd64

Current host

checking build system type x86_64-pc-linux-gnu

checking host system type x86_64-pc-linux-gnu

checking cached host system type ok

C-Language compilation tools

checking for gcc gcc

checking whether the C compiler works yes

checking for C compiler default output file name aout

checking for suffix of executables

checking whether we are cross compiling no

checking for suffix of object files o

checking whether we are using the GNU C compiler yes

checking whether gcc accepts -g yes

checking for gcc option to accept ISO C89 none needed

checking for ranlib ranlib

checking for strip strip

Host support

checking C flags dependant on host system type ok

Java compilation tools

checking JAVA_HOME /usr/java/jdk180_171-amd64

checking for JDK os include directory  linux

gcc flags added

checking how to run the C preprocessor gcc -E

checking for grep that handles long lines and -e /usr/bin/grep

checking for egrep /usr/bin/grep -E

checking for ANSI C header files yes

checking for sys/typesh yes

checking for sys/stath yes

checking for stdlibh yes

checking for stringh yes

checking for memoryh yes

checking for stringsh yes

checking for inttypesh yes

checking for stdinth yes

checking for unistdh yes

checking sys/capabilityh usability no

checking sys/capabilityh presence no

checking for sys/capabilityh no

configure: WARNING: cannot find headers for libcap

Writing output files

configure: creating /configstatus

configstatus: creating Makefile

configstatus: creating Makedefs

configstatus: creating native/Makefile

All done

Now you can issue "make"

输入make命令进行编译

[root@localhost unix]# make

(cd native; make  all)

make[1]: Entering directory `/opt/jsvc/commons-daemon-110-native-src/unix/native'

gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"amd64\" -Wall -Wstrict-prototypes   -I/usr/java/jdk180_171-amd64/include -I/usr/java/jdk180_171-amd64/include/linux -c jsvc-unixc -o jsvc-unixo

jsvc-unixc: In function ‘run_controller’:

jsvc-unixc:1304:20: warning: assignment from incompatible pointer type [enabled by default]

     actsa_handler = controller;

                    ^

gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"amd64\" -Wall -Wstrict-prototypes   -I/usr/java/jdk180_171-amd64/include -I/usr/java/jdk180_171-amd64/include/linux -c argumentsc -o argumentso

gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"amd64\" -Wall -Wstrict-prototypes   -I/usr/java/jdk180_171-amd64/include -I/usr/java/jdk180_171-amd64/include/linux -c debugc -o debugo

gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"amd64\" -Wall -Wstrict-prototypes   -I/usr/java/jdk180_171-amd64/include -I/usr/java/jdk180_171-amd64/include/linux -c dso-dlfcnc -o dso-dlfcno

gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"amd64\" -Wall -Wstrict-prototypes   -I/usr/java/jdk180_171-amd64/include -I/usr/java/jdk180_171-amd64/include/linux -c dso-dyldc -o dso-dyldo

gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"amd64\" -Wall -Wstrict-prototypes   -I/usr/java/jdk180_171-amd64/include -I/usr/java/jdk180_171-amd64/include/linux -c helpc -o helpo

gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"amd64\" -Wall -Wstrict-prototypes   -I/usr/java/jdk180_171-amd64/include -I/usr/java/jdk180_171-amd64/include/linux -c homec -o homeo

gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"amd64\" -Wall -Wstrict-prototypes   -I/usr/java/jdk180_171-amd64/include -I/usr/java/jdk180_171-amd64/include/linux -c javac -o javao

gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"amd64\" -Wall -Wstrict-prototypes   -I/usr/java/jdk180_171-amd64/include -I/usr/java/jdk180_171-amd64/include/linux -c locationc -o locationo

gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"amd64\" -Wall -Wstrict-prototypes   -I/usr/java/jdk180_171-amd64/include -I/usr/java/jdk180_171-amd64/include/linux -c replacec -o replaceo

gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"amd64\" -Wall -Wstrict-prototypes   -I/usr/java/jdk180_171-amd64/include -I/usr/java/jdk180_171-amd64/include/linux -c locksc -o lockso

gcc -g -O2 -DOS_LINUX -DDSO_DLFCN -DCPU=\"amd64\" -Wall -Wstrict-prototypes   -I/usr/java/jdk180_171-amd64/include -I/usr/java/jdk180_171-amd64/include/linux -c signalsc -o signalso

ar cr libservicea argumentso debugo dso-dlfcno dso-dyldo helpo homeo javao locationo replaceo lockso signalso

ranlib libservicea

gcc   jsvc-unixo libservicea -ldl -lpthread -o /jsvc

make[1]: Leaving directory `/opt/jsvc/commons-daemon-110-native-src/unix/native'

编译完成，查看目录会生成jsvc文件，将jsvc拷贝到上级目录

[root@localhost unix]# ls

configlog  confignice  configstatus  configure  configurein  INSTALLtxt  jsvc  Makedefs  Makedefsin  Makefile  Makefilein  man  native  support

[root@localhost unix]# cp jsvc //

java 是什么语言写的

JAVA中就虚拟机是其它语言开发的，用的是C语言+汇编语言 基于此之上就是JAVA本身了 虚拟机只起到解析作用
另外，JAVA并不比C语言慢，说JAVA慢一般是九十年代那时候的JAVA， 而现在 在一段优秀的JAVA程序和C程序执行效率上来比较是没有多大差距的 并且现在JAVA已经可以像C语言那样，直接编译为可执行文件（不用虚拟机，跨平台为代价）了
不知道你看过 卓越编程之道二（运用底层思维编写高级代码） 没有，那里面详细的讲述了高级语言从编写到编译执行的过程，通过目标文件的反汇编对比，发现C，C++，JAVA，dephi等语言在同等质量下的目标文件长度上基本上没多大区别，一门语言的运行速度快慢，与你编写代码过程中是否符合编译器规则息息相关。 有空你可以去看看这本书。

glusterfs 是什么语言写的

glusterfs 是什么语言写的
使用opencv需要编译源码，得到库文件。可以用cmake构建项目后编译，也可以直接用官方提供的编译好的版本。
官方提供的编译库一般只是标准版本，没有附加某些库，比如tbb等，要想让opencv使用tbb等库，就只能自己构建项目后编译。
当然，一般使用的话，用官方提供的库即可。OpenCV231版本就提供编译好的库，可以直接设置使用。

bigtable是什么语言写的

不过有人大费周折为他建立了一个类似于“关于 Chuck Norris 的事实”这样的网站，这倒是件不同寻常的事。这是因为 Jeff Dean 是一位软件工程师

zookeeper是什么语言写的

本文是Jason Wilder对于常见的服务发现项目 Zookeeper ， Doozer ， Etcd 所写的一篇博客，其原文地址如下： Open-Source Service Discovery 。
服务发现是大多数分布式系统以及面向服务架构（SOA）的一个核心组成部分。这个难题，简单来说，可以认为是：当一项服务存在于多个主机节点上时，client端如何决策获取相应正确的IP和port。
在传统情况下，当出现服务存在于多个主机节点上时，都会使用静态配置的方法来实现服务信息的注册。但是当大型系统中，需要部署更多服务的时候，事情就显得复杂得多。在一个实时的系统中，由于自动或者人工的服务扩展，或者服务的新添加部署，还有主机的宕机或者被替换，服务的location信息可能会很频繁的变化。
在这样的场景下，为了避免不必要的服务中断，动态的服务注册和发现就显得尤为重要。
关于服务发现的话题，已经很多次被人所提及，而且也的确不断的在发展。现在，笔者介绍一下该领域内一些open-source或者被经常被世人广泛讨论的解决方案，尝试理解它们到底是如何工作的。特别的是，我们会较为专注于每一个解决方案的一致性算法，到底是强一致性，还是弱一致性；运行时依赖；client的集成选择；以后最后这些特性的折中情况。
本文首先从几个强一致性的项目于开始，比如Zookeeper，Doozer，Etcd，这些项目主要用于服务间的协调，同时又可用于服务的注册。
随后，本文将讨论一些在服务注册以及发现方面比较有意思的项目，比如：Airbnb的SmartStack，Netflix的Eureka，Bitly的NSQ，Serf，Spotify and DNS，最后是SkyDNS。
问题陈述
在定位服务的时候，其实会有两个方面的问题：服务注册（Service Registration）和服务发现（Service Discovery）。
服务注册—— 一个服务将其位置信息在中心注册节点注册的过程。该服务一般会将它的主机IP地址以及端口号进行注册，有时也会有服务访问的认证信息，使用协议，版本号，以及关于环境的一些细节信息。
服务发现—— client端的应用实例查询中心注册节点以获知服务位置的过程。
每一个服务的服务注册以及服务发现，都需要考虑一些关于开发以及运营方面的问题：
监控—— 当一个已注册完毕的服务失效的时候，如何处理。一些情况下，在一个设定的超时定时(timeout)后，该服务立即被一个其他的进程在中心注册节点处注销。这种情况下，服务通常需要执行一个心跳机制，来确保自身的存活状态；而客户端必然需要能够可靠处理失效的服务。
负载均衡—— 如果多个相同地位的服务都注册完毕，如何在这些服务之间均衡所有client的请求负载？如果有一个master节点的话，是否可以正确处理client访问的服务的位置。
集成方式—— 信息注册节点是否需要提供一些语言绑定的支持，比如说，只支持Java？集成的过程是否需要将注册过程以及发现过程的代码嵌入到你的应用程序中，或者使用一个类似于集成助手的进程？
运行时依赖—— 是否需要JVM，ruby或者其他在你的环境中并不兼容的运行时？
可用性考虑—— 如果系统失去一个节点的话，是否还能正常工作？系统是否可以实时更新或升级，而不造成任何系统的瘫痪？既然集群的信息注册节点是架构中的中心部分，那该模块是否会存在单点故障问题？
强一致性的Registries
首先介绍的三个服务注册系统都采用了强一致性协议，实际上为达到通用的效果，使用了一致性的数据存储。尽管我们把它们看作服务的注册系统，其实它们还可以用于协调服务来协助leader选举，以及在一个分布式clients的集合中做centralized locking。
Zookeeper
Zookeeper是一个集中式的服务，该服务可以维护服务配置信息，命名空间，提供分布式的同步，以及提供组化服务。Zookeeper是由Java语言实现，实现了强一致性（CP），并且是使用 Zab协议 在ensemble集群之间协调服务信息的变化。
Zookeeper在ensemble集群中运行3个，5个或者7个成员。众多client端为了可以访问ensemble，需要使用绑定特定的语言。这种访问形式被显性的嵌入到了client的应用实例以及服务中。
服务注册的实现主要是通过命令空间（namespace）下的 ephemeral nodes 。ephemeral nodes只有在client建立连接后才存在。当client所在节点启动之后，该client端会使用一个后台进程获取client的位置信息，并完成自身的注册。如果该client失效或者失去连接的时候，该ephemeral node就从树中消息。
服务发现是通过列举以及查看具体服务的命名空间来完成的。Client端收到目前所有注册服务的信息，无论一个服务是否不可用或者系统新添加了一个同类的服务。Client端同时也需要自行处理所有的负载均衡工作，以及服务的失效工作。
Zookeeper的API用起来可能并没有那么方便，因为语言的绑定之间可能会造成一些细小的差异。如果使用的是基于JVM的语言的话， Curator Service Discovery Extension 可能会对你有帮助。
由于Zookeeper是一个CP强一致性的系统，因此当网络分区（Partition）出故障的时候，你的部分系统可能将出出现不能注册的情况，也可能出现不能找到已存在的注册信息，即使它们可能在Partition出现期间仍然正常工作。特殊的是，在任何一个non-quorum端，任何读写都会返回一个错误信息。
Doozer
Doozer是一个一致的分布式数据存储系统，Go语言实现，通过 Paxos算法 来实现共识的强一致性系统。这个项目开展了数年之后，停滞了一段时间，而且现在也关闭了一些fork数，使得fork数降至160 。不幸的是，现在很难知道该项目的实际发展状态，以及它是否适合使用于生产环境。
Doozer在集群中运行3，5或者7个节点。和Zookeeper类似，Client端为了访问集群，需要在自身的应用或者服务中使用特殊的语言绑定。
Doozer的服务注册就没有Zookeeper这么直接，因为Doozer没有那些ephemeral node的概念。一个服务可以在一条路径下注册自己，如果该服务不可用的话，它也不会自动地被移除。
现有很多种方式来解决这样的问题。一个选择是给注册进程添加一个时间戳和心跳机制，随后在服务发现进程中处理那些超时的路径，也就是注册的服务信息，当然也可以通过另外一个清理进程来实现。
服务发现和Zookeeper很类似，Doozer可以罗列出指定路径下的所有入口，随后可以等待该路径下的任意改动。如果你在注册期间使用一个时间戳和心跳，你就可以在服务发现期间忽略或者删除任何过期的入口，也就是服务信息。
和Zookeeper一样，Doozer是一个CP强一致性系统，当发生网络分区故障时，会导致同样的后果。
Etcd
Etcd 是一个高可用的K-V存储系统，主要应用于共享配置、服务发现等场景。Etcd可以说是被Zookeeper和Doozer催生而出。整个系统使用Go语言实现，使用Raft算法来实现选举一致，同时又具有一个基于>1、torm集群中包含两类节点：主控节点（Master Node）和工作节点（Work Node）。其分别对应的角色如下：
主控节点（Master Node）上运行一个被称为Nimbus的后台程序，它负责在Storm集群内分发代码，分配任务给工作机器，并且负责监控集群运行状态。Nimbus的作用类似于Hadoop中JobTracker的角色。
每个工作节点（Work Node）上运行一个被称为Supervisor的后台程序。Supervisor负责监听从Nimbus分配给它执行的任务，据此启动或停止执行任务的工作进程。每一个工作进程执行一个Topology的子集；一个运行中的Topology由分布在不同工作节点上的多个工作进程组成。
Nimbus和Supervisor节点之间所有的协调工作是通过Zookeeper集群来实现的。此外，Nimbus和Supervisor进程都是快速失败（fail-fast)和无状态（stateless）的；Storm集群所有的状态要么在Zookeeper集群中，要么存储在本地磁盘上。这意味着你可以用kill -9来杀死Nimbus和Supervisor进程，它们在重启后可以继续工作。这个设计使得Storm集群拥有不可思议的稳定性。
如何安装部署Storm集群
这一章节将详细描述如何搭建一个Storm集群。下面是接下来需要依次完成的安装步骤：•搭建Zookeeper集群；•安装Storm依赖库；•下载并解压Storm发布版本；•修改stormyaml配置文件；•启动Storm各个后台进程。
21 搭建Zookeeper集群
Storm使用Zookeeper协调集群，由于Zookeeper并不用于消息传递，所以Storm给Zookeeper带来的压力相当低。大多数情况下，单个节点的Zookeeper集群足够胜任，不过为了确保故障恢复或者部署大规模Storm集群，可能需要更大规模节点的Zookeeper集群（对于Zookeeper集群的话，官方推荐的最小节点数为3个）。在Zookeeper集群的每台机器上完成以下安装部署步骤：
1）下载安装Java JDK，官方下载链接为javasuncom/javase/downloads/indexjsp，JDK版本为JDK 6或以上。
2）根据Zookeeper集群的负载情况，合理设置Java堆大小，尽可能避免发生swap，导致Zookeeper性能下降。保守期间，4GB内存的机器可以为Zookeeper分配3GB最大堆空间。
3）下载后解压安装Zookeeper包，官方下载链接为hadoopapacheorg/zookeeper/releaseshtml。
4）根据Zookeeper集群节点情况，创建如下格式的Zookeeper配置文件zoocfg：tickTime=2000dataDir=/var/zookeeper/clientPort=2181initLimit=5syncLimit=2server1=zoo1:2888:3888server2=zoo2:2888:3888server3=zoo3:2888:3888
其中，dataDir指定Zookeeper的数据文件目录；其中serverid=host:port:port，id是为每个Zookeeper节点的编号，保存在dataDir目录下的myid文件中，zoo1~zoo3表示各个Zookeeper节点的hostname，第一个port是用于连接leader的端口，第二个port是用于leader选举的端口。
5）在dataDir目录下创建myid文件，文件中只包含一行，且内容为该节点对应的serverid中的id编号。
6）启动Zookeeper服务：
java -cp zookeeperjar:lib/log4j-1215jar:conf \ orgapachezookeeperserverquorumQuorumPeerMain zoocfg
也可以通过bin/zkServersh脚本启动Zookeeper服务。
7）通过Zookeeper客户端测试服务是否可用：•Java客户端下，执行如下命令：
java -cp zookeeperjar:src/java/lib/log4j-1215jar:conf:src/java/lib/jline-0994jar \ orgapachezookeeperZooKeeperMain -server 127001:2181
也可以通过bin/zkClish脚本启动Zookeeper Java客户端。•C客户端下，进入src/c目录下，编译单线程或多线程客户端：
/configuremake cli_stmake cli_mt
运行进入C客户端：
cli_st 127001:2181cli_mt 127001:2181
至此，完成了Zookeeper集群的部署与启动。
3、向集群提交任务
1）启动Storm Topology：
storm jar allmycodejar orgmeMyTopology arg1 arg2 arg3
其中，allmycodejar是包含Topology实现代码的jar包，orgmeMyTopology的main方法是Topology的入口，arg1、arg2和arg3为orgmeMyTopology执行时需要传入的参数。
2）停止Storm Topology：
storm kill {toponame}
其中，{toponame}为Topology提交到Storm集群时指定的Topology任务名称。

---