This is an automated email from the ASF dual-hosted git repository.
zhaijia pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/pulsar.wiki.git
The following commit(s) were added to refs/heads/master by this push:
new 1758841 Updated PIP 34: Add new subscribe type Key_Failover (markdown)
1758841 is described below
commit 17588413e04c7b320bae36ba5901fda46910b6c1
Author: Jia Zhai <zhai...@apache.org>
AuthorDate: Mon Apr 8 18:58:00 2019 +0800
Updated PIP 34: Add new subscribe type Key_Failover (markdown)
---
PIP-34:-Add-new-subscribe-type-Key_Failover.md | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/PIP-34:-Add-new-subscribe-type-Key_Failover.md
b/PIP-34:-Add-new-subscribe-type-Key_Failover.md
index 1163c4c..e94b7a6 100644
--- a/PIP-34:-Add-new-subscribe-type-Key_Failover.md
+++ b/PIP-34:-Add-new-subscribe-type-Key_Failover.md
@@ -19,12 +19,13 @@ The main work is on the hash layer and the new dispatcher.
As in the mail discussing, Any hash mechanism that can map a key to a
consumer should work here. We will make the hashing mechanism pluggable in
this proposal.
+
The hash value of message key determines the target consumer. The hash layer
has the following requirements:
1. Each consumer serves a fixed range of hash value.
1. The whole range of hash value could be covered by all the consumers.
1. Once a consumer is removed, the left consumers could still serve the whole
range.
-In the dispatcher, broker could collect the dispatch rate for each consumer.
+Here is an example hash method: In the dispatcher, broker could collect the
dispatch rate for each consumer.
When a new consumer is added, we could choose the busiest consumer and split
its hash range, and share a half of the hash range to the new consumer.
When a consumer is closed, we could assign its hash range to adjacent
consumer, which has less dispatch rate.
