从远程调用框架遇到Zookeeper(2)

远程呼叫管理组件是一个完全符合Zookeeper方案或标准Zookeeper应用程序的应用程序. 为了便于以后的讨论，我将进一步解释远程呼叫管理组件的功能. 从前面的描述中，我们知道远程呼叫管理组件的核心功能是存储服务提供者与服务调用者之间通信的配置信息，例如存储服务提供者的IP地址和端口，记录服务提供商的IP地址和端口. 服务提供者的服务类型，它还记录服务调用者的IP地址和端口号（此信息在远程呼叫管理组件的Web管理系统中输入）以及服务调用者与服务提供者之间的控制关系. 对于服务提供商，远程呼叫管理组件还提供了心跳机制来检测服务提供商的健康状况. 如果远程呼叫管理组件发现服务提供商的某些服务器有问题，它将及时更新服务提供商的配置信息，并将这些更改及时地推送给服务调用者. 如上所述，从配置信息存储的角度来看，远程呼叫管理组件实际上是用于远程存储配置信息的系统，并且心跳机制和推送机制是观察者模式，并且以上功能都在分布式环境中. 下一个功能要求高可靠性. Zookeeper的最典型应用程序是可用于分布式应用程序的配置服务. 具体点是我们通常编写的配置文件. 在分布式系统中，它还需要一个独立的系统来完成，并且是一种动态配置服务.

由于Zookeeper可以提供分布式配置服务，因此我们可以通过分布式配置服务的特征反向了解Zookeeper的作用. 当我进行JAVA Web开发时，我将使用很多配置文件. 通常，这些文件是用属性属性文件完成的. 服务启动时，属性文件中的信息将被读取到内存中，并且Web系统将从内存中读取这些信息. 配置信息. 此配置信息具有几个特征: 属性文件通常不会太大（此处是指与系统操作有关的配置文件），配置信息是持久的，使用时首先将其加载到内存中，然后从内存中读取， Zookeeper也可以做到这一点，其特征与传统配置文件几乎相同. Zookeeper有一个文件系统. 此文件系统用于存储小文件. 当我们读取配置信息时，会将其读取到内存中，这非常有效. 很高，Zookeeper在写入信息时将保留配置信息. 这就是为什么有些书介绍了Zookeeper的性能的原因:

Zookeeper的基本吞吐量可以超过10,000个操作，对于主要是读取操作的工作负载，吞吐量要高出几倍.

这句话很有道理. 小文件写入速度非常快. 10,000次操作怎么了？通过内存进行读取. 当然，它要高出几倍.

系统操作的配置信息的可靠性非常高. 由于我们现在使用分布式系统来完成配置信息的读写操作，因此确保信息读写的准确性非常重要. 尤其是对于编写而言，要求是绝对成功或失败，这种情况是线程安全的. 但是，我们现在是一个分布式系统，不同服务器之间的操作不程类别中，而在进程类别中. 因此，需要新技术来确保操作安全，换句话说，就是过程安全机制. 另外，分布式配置服务之所以使用分布式，是为了确保配置服务系统的稳定性和安全性，从而继续为用户提供高质量的服务. 这两个问题似乎无关，但是有一个解决方案可以同时解决此问题. 此解决方案是Zookeeper的Zab协议. 为了阐明Zab协议，我们举一个例子. 例如，我们使用5台服务器作为Zookeeper服务器. 我们向Zookeeper集群发送指令. 该指令是读操作或写操作. Zookeeper集群将完成以下两项操作:

操作1: 选举. Zookeeper启动时，这五台服务器将选出一个领导者机器，其他机器作为跟随者. 如果超过一半的追随者与该领导者进行沟通，确认状态，则该阶段将完成. 如果领导者始终健康远程调用框架，将不会再次触发领导者选举的操作. 如果领导者有问题，Zookeeper将再次触发领导者选举的操作. （我在这里有一个问题. 我不确定: Zookeeper的负责人在检测跟随者的健康状况时会使用心跳机制吗？）

操作2: 如果发出的指令是写请求，则所有写请求都将转发给领导者，然后领导者会将更新后的广播发送给跟随者. 当超过一半的关注者将修改持久性时，领导者将提交此更新，然后客户端将收到成功的更新响应. 达成共识的方法被设计为原子方法，如果操作失败或成功，操作将失败.

以上操作确保了读写的原子性，并且不会发生脏数据. 反复选举也可确保服务的可靠性. 当然，如果领导者失败了，这里仍然有问题吗？此时，Zookeeper集群将重复上述领导者选举操作. 这也解释了为什么Zookeeper群集需要奇数个服务器. 五台服务器中的两台被挂起，该服务仍可以正常运行. 如果是六台服务器，则仅允许两台服务器发生故障，因为如果三台服务器挂起，那么如果剩余服务器的数量不超过一半，则Zookeeper会自动挂起，因此，奇数服务器不会造成服务器资源的浪费.

对于读取操作，Zookeeper中的任何服务器都可以直接提供服务，而其他操作很少，因此效率很高；在进行写操作时，Zookeeper仅在所有服务器都保留了数据之后才更新内存中的相应内存. 数据，因此它比读取操作要慢得多.

Zookeeper存储数据的操作模式与Unix文件系统的路径操作相同，而内存数据存储的模型为树形结构. 树结构的节点称为znode，znode用于存储和读取数据. 该树的操作如下:

创建

要创建一个znode，您必须有一个父节点

删除

删除没有任何子节点的znode

存在

如果znode存在，并查询其元数据

getACL，setACL

获取/设置znode的ACL

getChildren

获取子节点列表

getData，setData

获取/设置znode保存的数据

与Zookeeper同步客户端的znode视图

我们存储的配置信息是通过以下操作完成的，例如: 服务提供商启动时，将其配置信息推送到远程呼叫管理组件，该组件将执行创建节点或设置由其保存的数据的操作. znode，成功保存数据后，Zookeeper将立即将信息推送给服务调用者. Zookeeper也可以完成此推送工作. Zookeeper中的znode进行了某种形式的更改. 每个znode都有一个观察机制. 此观察客户端机制将通知客户端，并且此客户端是服务调用者. 如果心跳机制检测到服务提供商的服务器发生故障，Zookeeper还将修改相应的znode信息. 这时，观察机制也将被触发，以将更改通知服务调用者.

Zookeeper的功能非常强大，不仅包括上面作者提到的应用程序，而且这篇文章是作者对Zookeeper进行深入研究的开始. 在目前的基础上，深入学习Zookeeper会容易得多.

作者简介: 夏军拥有近十年的一线开发经验. 早年从事企业级项目开发，设计开发了宝钢采购系统，上海市厅综合查询系统，后来加入互联网行业，参与盛大数据中心通过JAVA Web应用程序开发工作. 目前在中国银联互联网部工作，从事JAVA Web应用程序的开发. 最擅长Web前端开发，JAVA Web开发和分布式系统开发，并且对Hadoop相关技术也进行了大量研究.

原始链接: 体系结构设计-远程呼叫服务体系结构设计和Zookeeper技术的详细说明（编辑: 周小路）

CSDN建议: 欢迎免费订阅“ Hadoop和大数据周刊”，以获取更多Hadoop技术文献和生态系统趋势.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-186411-2.html