This is an automated email from the ASF dual-hosted git repository.
huzongtang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/rocketmq.wiki.git
The following commit(s) were added to refs/heads/master by this push:
new 94aec19 Created RIP-12 Message Connector (markdown)
94aec19 is described below
commit 94aec19709bcd71e98416ef2f95a297e838933dc
Author: Hu Zongtang <[email protected]>
AuthorDate: Tue Apr 2 15:52:59 2019 +0800
Created RIP-12 Message Connector (markdown)
---
RIP-12-Message-Connector.md | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/RIP-12-Message-Connector.md b/RIP-12-Message-Connector.md
new file mode 100644
index 0000000..48cec53
--- /dev/null
+++ b/RIP-12-Message-Connector.md
@@ -0,0 +1,44 @@
+# Status
+
+Current State: Discuss
+Authors: HuZongTang, WangShaoJie
+Shepherds: DuHeng
+Mailing List discussion: [email protected];[email protected]
+Pull Request:
+Released: <5.0.0>
+
+# Background & Motivation
+## What do we need to do
+In current version of rocketmq project, different cluster can't exchange
messages each other. Although dLedger structure improves availability of
rocketmq much more, it still can't implement backuping messages for different
cluster.
+So, we need a mechanism to implement backuping messages for different cluster.
It can improve availability of multiple rocketmq cluster. Here, we called it
Message Connector.
+
+# Goals
+## What problem is this proposal designed to solve?
+We plan to design a component call Message Connector for RocketMQ. User can
define the topic message routing rule by configing file, such as source topic,
targe topic, filter tag , source cluster and targe cluster info.
+##To what degree should we solve the problem?
+(1)Define some rules in configing files;
+(2)Better availability for messages in multiple cluster enviroment.
+(3)Monitering some parameters in the process of message replication;
+
+# Non-Goals
+## What problem is this proposal NOT designed to solve?
+In this phase, this rip only support starting message replication from the
latest message position currently in the message queue.
+## Are there any limits to this proposal?
+If users want to use this feature, they will deploy Message Connector
Component. It will add a little complexity for operation and maintenance.
+
+# Changes
+If users want to use this feature, they will deploy Message Connector
Component.
+
+# Architecture
+We plan to design the function of Message Connector as a new component. The
total architecture is as below:
+
+https://docs.google.com/document/d/1haZ_HtAFWX39SDyeYWKWWvwT5vSnq0JqZvaNT1RtFFI/edit
+
+Enahncement 1: Sub-project: Implement full messages synchronous replication
+We will implement the basic feature for this rip. In this phase, Users can use
the Message Connector Component for message replication basicly.
+
+Enhancement 2: Sub-project: Monitering some parameters in the process of
message replication
+This phase we will collect some parameters in the process of message
replication, such as message tps, delay, latest synchronous time and so on.User
can show this parameters in their own monitering system.
+
+Enhancement 3: Sub-project: Implement exactly once replication
+This phase we will implement message idempotency to meet the exactly once
demand.
\ No newline at end of file
