[
https://issues.apache.org/jira/browse/ZOOKEEPER-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733571#action_12733571
]
Henry Robinson commented on ZOOKEEPER-368:
------------------------------------------
I agree that using a quorum of weight 0 would emulate most of the behaviour of
Observers.
For:
* Would simplify the patch (presumably still need code to ensure that observers
aren't elected as leaders)
* Exercises existing code
Against:
* Adds an extra message to each proposal instance, increasing chatter across
the WAN (yes they don't need to send ACKs, but they will still receive PROPOSAL
and COMMIT msgs)
* Perhaps less easy to customise request processor behaviour, although it's not
established that we'll definitely want to do this.
* Adding subscription behaviour (see mailing list discussion) would be less
clean - we would need to decide if we wanted all Followers to be able to choose
the znodes they receive updates from (I think this would overcomplicate the
Leader which would need to determine when / if it had a quorum for each node,
and under which conditions it was to revoke its own Leadership). The
alternative with the proposed approach is to only allow weight-0 Followers to
choose a subscription, which seems a bit hacky to me.
My vote would probably be for continuing with the current approach (perhaps I'm
biased because I don't want to throw away the work already done :)).
There are actually two orthogonal issues related to the coding of this patch.
1. Do we want to separate out Observers into a separate class, and retain the
Peer-> [Follower|Observer] hierarchy?
2. How do we implement Observers - as members of a weight-0 quorum or with
INFORM packets and some custom logic on the Leader side?
The main complexity of this patch is due to 1. (Note how the patch size spiked
by 50kb when I included the class hierarchy split). The actual logic needed to
make Observers work as implemented is fairly simple: on the server side the
main changes are in QuorumPeer and Leader.
I would argue in favour of 1 - I think there is an increased readability with
splitting the Follower code out and this gives a natural point to customise the
behaviour of Followers or Observers in the future; plus if we should ever
decide we want another kind of Peer the class hierarchy is already in place to
make it happen more easily. Plus, as I argued above, I think only Observers
should have partial subscription ability; this class gives us the right place
to put it.
Given 1, I would then argue for implementing Observers as currently imagined
due to the small advantage of losing the extra message, plus the benefits of
keeping the implementation separate on the Leader to make it easy to implement
subscriptions later. The size of the implementation patch compared to the size
of the restructuring patch is small.
If we decide against 1, then the situation is less clear as implementing 2 with
weight-0 quorums would probably lead to a smaller patch.
> Observers
> ---------
>
> Key: ZOOKEEPER-368
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-368
> Project: Zookeeper
> Issue Type: New Feature
> Components: quorum
> Reporter: Flavio Paiva Junqueira
> Assignee: Henry Robinson
> Attachments: ZOOKEEPER-368.patch, ZOOKEEPER-368.patch,
> ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch,
> ZOOKEEPER-368.patch
>
>
> Currently, all servers of an ensemble participate actively in reaching
> agreement on the order of ZooKeeper transactions. That is, all followers
> receive proposals, acknowledge them, and receive commit messages from the
> leader. A leader issues commit messages once it receives acknowledgments from
> a quorum of followers. For cross-colo operation, it would be useful to have a
> third role: observer. Using Paxos terminology, observers are similar to
> learners. An observer does not participate actively in the agreement step of
> the atomic broadcast protocol. Instead, it only commits proposals that have
> been accepted by some quorum of followers.
> One simple solution to implement observers is to have the leader forwarding
> commit messages not only to followers but also to observers, and have
> observers applying transactions according to the order followers agreed upon.
> In the current implementation of the protocol, however, commit messages do
> not carry their corresponding transaction payload because all servers
> different from the leader are followers and followers receive such a payload
> first through a proposal message. Just forwarding commit messages as they
> currently are to an observer consequently is not sufficient. We have a couple
> of options:
> 1- Include the transaction payload along in commit messages to observers;
> 2- Send proposals to observers as well.
> Number 2 is simpler to implement because it doesn't require changing the
> protocol implementation, but it increases traffic slightly. The performance
> impact due to such an increase might be insignificant, though.
> For scalability purposes, we may consider having followers also forwarding
> commit messages to observers. With this option, observers can connect to
> followers, and receive messages from followers. This choice is important to
> avoid increasing the load on the leader with the number of observers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
