学习过程中发现这 6 个方便的正则表达式

然而，如果我们只是用一个进程来充当这个工作。那么这个进程就成为了这个集群的“单点”——意思就是，如果这个进程故障了，那么整个集群可能都无法运行的。所以存放集群状态的目录服务，也需要是分布式的。幸好我们有ZooKeeper这个优秀的开源软件，它正是一个分布式的目录服务区。

ZooKeeper可以简单启动奇数个进程，来形成一个小的目录服务集群。这个集群会提供给所有其他进程，进行读写其巨大的“配置树”的能力。这些数据不仅仅会存放在一个ZooKeeper进程中，而是会根据一套非常安全的算法，让多个进程来承载。这让ZooKeeper成为一个优秀的分布式数据保存系统。

由于ZooKeeper的数据存储结构，是一个类似文件目录的树状系统，所以我们常常会利用它的功能，把每个进程都绑定到其中一个“分枝”上，然后通过检查这些“分支”，来进行服务器请求的转发，就能简单的解决请求路由(由谁去做)的问题。另外还可以在这些“分支”上标记进程的负载的状态，这样负载均衡也很容易做了。

目录服务是分布式系统中最关键的组件之一。而ZooKeeper是一个很好的开源软件，正好是用来完成这个任务。

消息队列服务(ActiveMQ、ZeroMQ、Jgroups)

两个进程间如果要跨机器通讯，我们几乎都会用TCP/UDP这些协议。但是直接使用网络API去编写跨进程通讯，是一件非常麻烦的事情。除了要编写大量的底层socket代码外，我们还要处理诸如：如何找到要交互数据的进程，如何保障数据包的完整性不至于丢失，如果通讯的对方进程挂掉了，或者进程需要重启应该怎样等等这一系列问题。这些问题包含了容灾扩容、负载均衡等一系列的需求。

为了解决分布式系统进程间通讯的问题，人们总结出了一个有效的模型，就是“消息队列”模型。消息队列模型，就是把进程间的交互，抽象成对一个个消息的处理，而对于这些消息，我们都有一些“队列”，也就是管道，来对消息进行暂存。每个进程都可以访问一个或者多个队列，从里面读取消息(消费)或写入消息(生产)。由于有一个缓存的管道，我们可以放心的对进程状态进行变化。当进程起来的时候，它会自动去消费消息就可以了。而消息本身的路由，也是由存放的队列决定的，这样就把复杂的路由问题，变成了如何管理静态的队列的问题。

一般的消息队列服务，都是提供简单的“投递”和“收取”两个接口，但是消息队列本身的管理方式却比较复杂，一般来说有两种。一部分的消息队列服务，提倡点对点的队列管理方式：每对通信节点之间，都有一个单独的消息队列。这种做法的好处是不同来源的消息，可以互不影响，不会因为某个队列的消息过多，挤占了其他队列的消息缓存空间。而且处理消息的程序也可以自己来定义处理的优先级——先收取、多处理某个队列，而少处理另外一些队列。

但是这种点对点的消息队列，会随着集群的增长而增加大量的队列，这对于内存占用和运维管理都是一个复杂的事情。因此更高级的消息队列服务，开始可以让不同的队列共享内存空间，而消息队列的地址信息、建立和删除，都采用自动化的手段。——这些自动化往往需要依赖上文所述的“目录服务”，来登记队列的ID对应的物理IP和端口等信息。比如很多开发者使用ZooKeeper来充当消息队列服务的中央节点;而类似Jgropus这类软件，则自己维护一个集群状态来存放各节点今昔。


 

于分布式系统日志数量的庞大，以及日志复杂程度的提高。我们变得必须要掌握类似Map Reduce技术，才能真正的对分布式系统进行数据统计。而且我们还需要想办法提高统计工作的工作效率。

解决分布式系统可管理性的基本手段 目录服务(ZooKeeper)

分布式系统是一个由很多进程组成的整体，这个整体中每个成员部分，都会具备一些状态，比如自己的负责模块，自己的负载情况，对某些数据的掌握等等。而这些和其他进程相关的数据，在故障恢复、扩容缩容的时候变得非常重要。

简单的分布式系统，可以通过静态的配置文件，来记录这些数据：进程之间的连接对应关系，他们的IP地址和端口，等等。然而一个自动化程度高的分布式系统，必然要求这些状态数据都是动态保存的。这样才能让程序自己去做容灾和负载均衡的工作。

一些程序员会专门自己编写一个DIR服务(目录服务)，来记录集群中进程的运行状态。集群中进程会和这个DIR服务产生自动关联，这样在容灾、扩容、负载均衡的时候，就可以自动根据这些DIR服务里的数据，来调整请求的发送目地，从而达到绕开故障机器、或连接到新的服务器的操作。

（编辑：宜春站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!