您的位置:首页 > 其它

zookeeper系列(六) 官方翻译简介

2015-12-24 16:20 369 查看
Implementation
ZooKeeper Components shows the high-level components of the
ZooKeeper service. 
With the exception of the request
processor, 
each of the servers that make up the ZooKeeper service
replicates its own copy of each of components.

The replicated database is an in-memory database containing
the entire data tree. 
Updates are logged to disk for
recoverability, 
and writes are serialized to disk before they are applied to
the in-memory database.

Every ZooKeeper server services clients. Clients connect to
exactly one server to submit irequests. 
Read requests are serviced from the local replica of each
server database. 
Requests that change the state of the service, write
requests,
 are processed by an agreement
protocol.

 
As part of the agreement protocol all write requests from
clients are forwarded to a single server, 
called the leader. The rest of the ZooKeeper servers, called
followers,
 receive message proposals from the leader
and agree upon message delivery.
 The messaging layer takes care of replacing
leaders on failures and syncing followers with leaders.

ZooKeeper uses a custom atomic messaging protocol. Since the
messaging layer is atomic, ZooKeeper 
can guarantee that the local replicas never diverge.
 When the leader receives a write
request, 
 it calculates what the state of the system
is when
 the write is to be applied and transforms
this into a transaction that captures this new state.

Uses3
The programming interface to ZooKeeper is deliberately
simple. 
With it, however, you can implement higher order operations,
such as synchronizations primitives,
 group membership, ownership, etc. Some
distributed applications have used it to:
 [tbd: add uses from white paper and video
presentation.] For more information, see [tbd]

翻译: 

 zookeeper实现:
 zookeeper组件中 展示了zookeeper服务中比较高级的组件服务.
 除了请求处理器的异常情况之外.
 组成zookeeper服务的每一台zookeeper服务器
保存着每个组件自身备份的副本.
 
 副本数据库是一个内存数据库,保存着整个目录结构树的数据.
 所有的更新操作都记录在磁盘日志当中,用于异常情况的恢复.
在更新作用到内存数据中之前,所有的写入操作都是串行的,
 这就保证了数据的强一致性.
 
 每个zookeeper服务器节点服务若干个客户端.
客户端连接到某一个指定的服务器节点(随机分配算法分配的吧)和zookeeper进行交互.

 读请求都是由每个zookeeper服务器内存数据库的本地副本进行服务的(可以提高读的性能,

 这也就是为什么zookeeper在读写比例为10:1的情况下,性能最佳的原因)
 
 涉及到修改服务器状态和数据的写入操作,需要通过一致性协议进行处理.
  一致性协议中规定:
所有的写入操作都是有选举出来的唯一机器即我们称之为leader(主节点) 的节点进行操作.
 剩下的zookeeper机器,称之为从节点(跟随者),接收来自leader节点的建议
并同意传输过来的消息.
 也就是说对消息只有服从和传输的特性.  消息层
关注的是当leader节点挂掉之后怎么去替换他,并同步leader节点和follower节点之间的数据.
 
 zookeeper 使用客户端端原子消息协议.因为消息层是原子的,zookeeper
能保证本地副本和服务器版本相同步.
 
 当leader节点接收到写入请求时, leader节点会计算下
当前系统的状态是什么,什么时候讲写入作用到服务器,
 并把当前写入操作转换成一个事务并记录下新的状态.
  
 使用情况
 zookeeper的编程接口
设计的非常简单,但是用这些能实现一些其他更高级别的操作,比如同步原语,对成员进行分组和选举等等.
 一些分布式的应用用这些接口实现一些其他比较高级的功能
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: