zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Nixon (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-3140) Allow Followers to host Observers
Date Fri, 12 Oct 2018 19:49:00 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648379#comment-16648379

Brian Nixon commented on ZOOKEEPER-3140:

A note on future work - it would be cool to see the serialized format of the QuorumVerifier
(used for the dynamic config files and the like) updated to a more extensible form so we can
track more topology and port information through it. This would give us a lot more flexibility
in setting and propagating the observer master port, in particular in letting each server
publish its own port instead of requiring a single static port for the whole ensemble. Would
also be useful for purposes such as ZOOKEEPER-3166.

I thought there was an existent Jira on this requested change but didn't see one in a cursory
search. I will create one specifically eventually, if I get the time. :)

> Allow Followers to host Observers
> ---------------------------------
>                 Key: ZOOKEEPER-3140
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3140
>             Project: ZooKeeper
>          Issue Type: New Feature
>          Components: server
>    Affects Versions: 3.6.0
>            Reporter: Brian Nixon
>            Assignee: Brian Nixon
>            Priority: Minor
>              Labels: pull-request-available
>          Time Spent: 5h
>  Remaining Estimate: 0h
> Observers function simple as non-voting members of the ensemble, sharing the Learner
interface with Followers and holding only a slightly difference internal pipeline. Both maintain
connections along the quorum port with the Leader by which they learn of all new proposals
on the ensemble. 
>  There are benefits to allowing Observers to connect to the Followers to plug into the
commit stream in addition to connecting to the Leader. It shifts the burden of supporting
Observers off the Leader and allow it to focus on coordinating the commit of writes. This
means better performance when the Leader is under high load, particularly high network load
such as can happen after a leader election when many Learners need to sync. It also reduces
the total network connections maintained on the Leader when there are a high number of observers.
One the other end, Observer availability is improved since it will take shorter time for a
high number of Observers to finish syncing and start serving client traffic.
>  The current implementation only supports scaling the number of Observers into the hundreds
before performance begins to degrade. By opening up Followers to also host Observers, over
a thousand observers can be hosted on a typical ensemble without major negative impact under
both normal operation and during post-leader election sync.

This message was sent by Atlassian JIRA

View raw message