【问题标题】:Can "observer" nodes in zookeeper respond with stale results?zookeeper 中的“观察者”节点可以响应陈旧的结果吗?
【发布时间】:2017-01-24 07:25:34
【问题描述】:

这个问题参考https://zookeeper.apache.org/doc/trunk/zookeeperObservers.html

观察者是合奏中没有投票权的成员,他们只听到 投票的结果,而不是导致投票的协议协议。 除了这个简单的区别之外,观察者的功能与 与追随者相同 - 客户端可以连接到他们并发送读取和 向他们写请求。观察者将这些请求转发给领导者 像追随者一样,但他们只是等待听到结果 投票。因此,我们可以尽可能多地增加观察者的数量 在不影响投票表现的情况下随心所欲。

观察者还有其他优势。因为他们不投票,所以他们是 不是 ZooKeeper 集成的关键部分。因此他们可以 失败或与集群断开连接,而不会损害 ZooKeeper 服务的可用性。对用户的好处是 观察者可能通过比追随者更不可靠的网络链接进行连接。 事实上,Observers 可以用来与 ZooKeeper 服务器从 另一个数据中心。 Observer 的客户端将看到快速读取,因为 所有读取都在本地提供,写入导致最小的网络 流量作为在没有投票时所需的消息数量 协议更小。

1) 乐团的无投票权成员 - 有投票权的成员对什么进行投票?

2) 更新请求如何为观察者工作 - 当 ZK 领导者收到更新请求时,它需要一定数量的节点来响应。观察者节点似乎不被视为仲裁节点。这是否意味着观察者节点落后于领导者节点的更新?如果这是真的,它如何确保观察者节点在读取期间不会响应陈旧数据?

3) Observer 的客户端将看到快速读取,因为所有读取都在本地提供,并且写入导致网络流量最小,因为在没有投票协议的情况下所需的消息数量更少 - 来自所有其他节点的读取也将是本地的,只是因为它们与领导者同步,不是吗?而且我没有得到关于写入的部分。

这些问题应该有助于理解 Zookeeper 和分布式系统。感谢这些的详细解答。提前致谢!

【问题讨论】:

    标签: apache-zookeeper distributed-computing


    【解决方案1】:

    1) 乐团的无投票权成员 - 有投票权的成员对什么进行投票?

    整体的典型成员(不是观察员)对由领导者协调的提议变更的成功/失败进行投票。论文ZooKeeper: Wait-free coordination for Internet-scale systems中对细节有一些进一步的讨论。

    2) 更新请求如何为观察者工作 - 当 ZK 领导者收到更新请求时,它需要一定数量的节点来响应。观察者节点似乎不被视为仲裁节点。这是否意味着观察者节点落后于领导者节点的更新?如果这是真的,它如何确保观察者节点在读取期间不会响应陈旧数据?

    你是正确的,观察者节点不被认为是法定人数的必要参与者。一般来说,更新延迟会受到观察者和领导者之间的网络延迟的影响。 (这是否明显取决于特定的外部因素,例如观察者和领导者是否位于具有低延迟网络链接的同一数据中心。)

    请注意,即使不使用观察者,也不能保证 ensemble 中的每台服务器始终是最新的。 Consistency Guarantees 上的 Apache ZooKeeper 文档包含以下免责声明:

    有时开发人员会错误地假设 ZooKeeper 实际上并没有做出其他保证。这是:

    ZooKeeper 不支持同时一致的跨客户端视图 保证在每个实例中,两个不同的客户端将 拥有相同的 ZooKeeper 数据视图。由于网络等因素 延迟,一个客户端可能会在另一个客户端获取之前执行更新 通知变更。考虑两个客户端 A 和 B 的场景。 如果客户端 A 将 znode /a 的值从 0 设置为 1,则告诉 客户端 B 读取 /a,客户端 B 可能读取旧值 0,具体取决于 它连接到哪个服务器。如果客户 A 很重要 和客户端 B 读取相同的值,客户端 B 应该调用 ZooKeeper API 方法中的 sync() 方法,然后再执行 阅读。

    但是,ZooKeeper 的客户端永远不会通过从他们已经读取的数据之前的时间点读取陈旧数据来“回到过去”。这是通过将单调递增的事务 ID(称为“zxid”)附加到每个 ZooKeeper 事务来实现的。当 ZooKeeper 客户端与服务器交互时,它会将客户端上次看到的 zxid 与服务器的当前 zxid 进行比较。如果服务器在客户端之后,那么它将不允许该服务器处理客户端的下一次读取。

    3) Observer 的客户端将看到快速读取,因为所有读取都在本地提供,并且写入导致网络流量最小,因为在没有投票协议的情况下所需的消息数量更少 - 来自所有其他节点的读取也将是本地的,只是因为它们与领导者同步,不是吗?而且我没有得到关于写入的部分。

    请务必注意,文档中的此语句是在观察者的一个重要用例的上下文中编写的:多个数据中心部署,不同数据中心之间的网络延迟较高。在此声明中,“本地服务”是指从与客户端相同的数据中心内的 ZooKeeper 服务器提供服务,因此它不会受到连接到另一个数据中心的较长延迟的影响。对于完整的上下文,这里是完整报价的副本:

    事实上,Observers 可以用来与来自另一个数据中心的 ZooKeeper 服务器通信。 Observer 的客户端将看到快速读取,因为所有读取都在本地提供,并且写入导致网络流量最小,因为在没有投票协议的情况下所需的消息数量更少。

    【讨论】:

    • 嗨,克里斯,感谢您的解释。我有一个后续问题。我在这个时间线上有以下场景: - 00:00.001 绝对时间,Leader 收到写入 - 00:00.002 绝对时间,Observer 收到 1000 次读取/观看 1) 即使数据过时,观察者是否开始服务以及何时是否会知道新的写入会将其转发给正在观察节点的客户端? 2)如果我们有一个追随者而不是观察者,情况会改变吗? (我们会在跟随案例中保持写入和读取之间的顺序吗?)谢谢!
    • 1) 如果还有其他并发的读取器进程,那么它们可以立即开始从观察器读取。但是,对于作者来说,该进程从完成写入的那一刻起就知道“zxid”(请参阅​​答案文本),因此,它永远不会允许来自未赶上至少该 zxid 的观察者的过时读取. 2) 不,这个 ZooKeeper 客户端排序保证无论与服务器端的 Observer 还是 Follower 交互都是正确的。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-08-14
    • 2011-06-17
    • 1970-01-01
    • 2021-09-25
    • 1970-01-01
    • 1970-01-01
    • 2023-03-10
    相关资源
    最近更新 更多