[
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
(v7.6.3#76005)
