mirror of
https://github.com/apache/rocketmq.git
synced 2026-08-28 20:09:14 +08:00
Co-authored-by: djzhu <zhudejun1@huya.com>
This commit is contained in:
gogodjzhu
+1
-1
@@ -604,7 +604,7 @@ Before introducing the mqadmin management tool, the following points need to be
|
||||
</tr>
|
||||
<tr height=23 style='height:17.0pt'>
|
||||
<td height=23 class=xl67 width=87 style='height:17.0pt;width:65pt'>-i</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>uniqe msg id</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>unique msg id</td>
|
||||
</tr>
|
||||
<tr height=36 style='height:27.0pt'>
|
||||
<td height=36 class=xl67 width=87 style='height:27.0pt;width:65pt'>-g</td>
|
||||
|
||||
+2
-2
@@ -4,7 +4,7 @@
|
||||
|
||||
RocketMQ message model is mainly composed of Producer, Broker and Consumer. The producer is responsible for producing messages and the consumer is for consuming messages, while the broker stores messages.
|
||||
The broker is an independent server during actual deployment, and each broker can store messages from multiple topics. Even messages from the same topic can be stored in the different brokers by sharding strategy.
|
||||
The message queue is used to store physical offsets of messages, and the message addresses are stored in seperate queues. The consumer group consists of multiple consumer instances.
|
||||
The message queue is used to store physical offsets of messages, and the message addresses are stored in separate queues. The consumer group consists of multiple consumer instances.
|
||||
## 2 Producer
|
||||
The Producer is responsible for producing messages, typically by business systems. It sends messages generated by the systems to brokers. RocketMQ provides multiple paradigms of sending: synchronous, asynchronous, sequential and one-way. Both synchronous and asynchronous methods require the confirmation information return from the Broker, but one-way method does not require it.
|
||||
## 3 Consumer
|
||||
@@ -38,4 +38,4 @@ Under the Strictly Ordered Message mode, all messages received by the consumers
|
||||
The physical carrier of information transmitted by a messaging system, the smallest unit of production and consumption data, each message must belong to one topic.
|
||||
Each Message in RocketMQ has a unique message id and can carry a key used to store business-related value. The system has the function to query messages by its id or key.
|
||||
## 16 Tag
|
||||
Flags set for messages to distinguish different types of messages under the same topic, functioning as a "sub-topic". Messages from the same business unit can set different tags under the same topic in terms of different business purposes. The tag can effectively maintain the clarity and consistency of the code and optimize the query system provided by RocketMQ. The consumer can realize different "sub-topic" by using tag in order to achieve better expansibility.
|
||||
Flags set for messages to distinguish different types of messages under the same topic, functioning as a "sub-topic". Messages from the same business unit can set different tags under the same topic in terms of different business purposes. The tag can effectively maintain the clarity and consistency of the code and optimize the query system provided by RocketMQ. The consumer can realize different "sub-topic" by using tag in order to achieve better expandability.
|
||||
|
||||
@@ -18,7 +18,7 @@ consumer.setNamesrvAddr("192.168.0.1:9876;192.168.0.2:9876");
|
||||
```text
|
||||
-Drocketmq.namesrv.addr=192.168.0.1:9876;192.168.0.2:9876
|
||||
```
|
||||
- Specified ```Name Server``` address in the envionment variables
|
||||
- Specified ```Name Server``` address in the environment variables
|
||||
|
||||
```text
|
||||
export NAMESRV_ADDR=192.168.0.1:9876;192.168.0.2:9876
|
||||
|
||||
@@ -59,7 +59,7 @@ There is a os.sh script that lists a lot of kernel parameters in folder bin whic
|
||||
|
||||
|
||||
|
||||
- **vm.swappiness**, define how aggressive the kernel will swap memory pages. Higher values will increase agressiveness, lower values decrease the amount of swap. 10 is recommended for this value to avoid swap latency.
|
||||
- **vm.swappiness**, define how aggressive the kernel will swap memory pages. Higher values will increase aggressiveness, lower values decrease the amount of swap. 10 is recommended for this value to avoid swap latency.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -73,7 +73,7 @@ The boot command shown above is used in the case of a single NameServer.For clus
|
||||
|
||||
### 3 Multiple Master And Multiple Slave Mode-Asynchronous replication
|
||||
|
||||
Each master node configures more thran one slave nodes, with multiple pairs of master-slave.HA uses asynchronous replication, with a short message delay (millisecond) between master node and slave node.The advantages and disadvantages of this mode are as follows:
|
||||
Each master node configures more than one slave nodes, with multiple pairs of master-slave.HA uses asynchronous replication, with a short message delay (millisecond) between master node and slave node.The advantages and disadvantages of this mode are as follows:
|
||||
|
||||
- Advantages:
|
||||
1. Even if the disk is corrupted, very few messages will be lost and the real-time performance of the message will not be affected.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# Message Filter
|
||||
RocketMQ - a distributed message queue, is different with all other MQ middleware, on the way of filtering messages. It's do the filter when the messages are subscribed via consumer side.RocketMQ do it lies in the separate storage mechanism that Producer side writing messages and Consomer subscribe messages, Consumer side will get an index from a logical message queue ConsumeQueue when subscribing, then read message entity from CommitLog using the index. So in the end, it is still impossible to get around its storage structure.The storage structure of ConsumeQueue is as follows, and there is a 8-byte Message Tag hashcode, The message filter based on Tag value is just used this Message Tag hash-code.
|
||||
RocketMQ - a distributed message queue, is different with all other MQ middleware, on the way of filtering messages. It's do the filter when the messages are subscribed via consumer side.RocketMQ do it lies in the separate storage mechanism that Producer side writing messages and Consumer subscribe messages, Consumer side will get an index from a logical message queue ConsumeQueue when subscribing, then read message entity from CommitLog using the index. So in the end, it is still impossible to get around its storage structure.The storage structure of ConsumeQueue is as follows, and there is a 8-byte Message Tag hashcode, The message filter based on Tag value is just used this Message Tag hash-code.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
## Load Balancing
|
||||
Load balancing in RocketMQ is accomplished on Client side. Specifically, it can be divided into load balancing at Producer side when sending messages and load balancing at Constumer side when subscribing messages.
|
||||
Load balancing in RocketMQ is accomplished on Client side. Specifically, it can be divided into load balancing at Producer side when sending messages and load balancing at Consumer side when subscribing messages.
|
||||
|
||||
### Producer Load Balancing
|
||||
When the Producer sends a message, it will first find the specified TopicPublishInfo according to Topic. After getting the routing information of TopicPublishInfo, the RocketMQ client will select a queue (MessageQueue) from the messageQueue List in TopicPublishInfo to send the message by default.Specific fault-tolerant strategies are defined in the MQFaultStrategy class.
|
||||
|
||||
@@ -19,7 +19,7 @@ Header field | Type | Request desc | Response desc
|
||||
code |int | Request code. answering business processing is different according to different requests code | Response code. 0 means success, and non-zero means errors.
|
||||
language | LanguageCode | Language implemented by the requester | Language implemented by the responder
|
||||
version | int | Version of Request Equation | Version of Response Equation
|
||||
opaque | int |Equivalent to reqeustId, the different request identification codes on the same connection correspond to those in the response message| The response returns directly without modification
|
||||
opaque | int |Equivalent to requestId, the different request identification codes on the same connection correspond to those in the response message| The response returns directly without modification
|
||||
flag | int | Sign, used to distinguish between ordinary RPC or oneway RPC | Sign, used to distinguish between ordinary RPC or oneway RPC
|
||||
remark | String | Transfer custom text information | Transfer custom text information
|
||||
extFields | HashMap<String, String> | Request custom extension information| Response custom extension information
|
||||
@@ -45,6 +45,6 @@ Number of thread | Name of thread | Desc of thread
|
||||
1 | NettyBoss_%d | Reactor Main thread
|
||||
N | NettyServerEPOLLSelector_%d_%d | Reactor thread pool
|
||||
M1 | NettyServerCodecThread_%d | Worker thread pool
|
||||
M2 | RemotingExecutorThread_%d | bussiness processor thread pool
|
||||
M2 | RemotingExecutorThread_%d | business processor thread pool
|
||||
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("CID_EXAMPLE");
|
||||
consumer.subscribe("TOPIC", "TAGA || TAGB || TAGC");
|
||||
```
|
||||
|
||||
The consumer will recieve messages that contains TAGA or TAGB or TAGC. But the limitation is that one message only can have one tag, and this may not work for sophisticated scenarios. In this case, you can use SQL expression to filter out messages.
|
||||
The consumer will receive messages that contains TAGA or TAGB or TAGC. But the limitation is that one message only can have one tag, and this may not work for sophisticated scenarios. In this case, you can use SQL expression to filter out messages.
|
||||
SQL feature could do some calculation through the properties you put in when sending messages. Under the grammars defined by RocketMQ, you can implement some interesting logic. Here is an example:
|
||||
|
||||
```
|
||||
@@ -73,7 +73,7 @@ Use `MessageSelector.bySql` to select messages through SQL when consuming.
|
||||
|
||||
```java
|
||||
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("please_rename_unique_group_name_4");
|
||||
// only subsribe messages have property a, also a >=0 and a <= 3
|
||||
// only subscribe messages have property a, also a >=0 and a <= 3
|
||||
consumer.subscribe("TopicTest", MessageSelector.bySql("a between 0 and 3"));
|
||||
consumer.registerMessageListener(new MessageListenerConcurrently() {
|
||||
@Override
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# OpenMessaging Example
|
||||
[OpenMessaging](https://openmessaging.github.io/), which includes the establishment of industry guidelines and messaging, streaming specifications to provide a common framework for finance, ecommerce, IoT and big-data area. The design principles are the cloud-oriented, simplicity, flexibility, and language independent in distributed heterogeneous environments. Conformance to these specifications will make it possible to develop a heterogeneous messaging applications across all major platforms and operating systems.
|
||||
[OpenMessaging](https://openmessaging.github.io/), which includes the establishment of industry guidelines and messaging, streaming specifications to provide a common framework for finance, e-commerce, IoT and big-data area. The design principles are the cloud-oriented, simplicity, flexibility, and language independent in distributed heterogeneous environments. Conformance to these specifications will make it possible to develop a heterogeneous messaging applications across all major platforms and operating systems.
|
||||
|
||||
RocketMQ provides a partial implementation of OpenMessaging 0.1.0-alpha, the following examples demonstrate how to access RocketMQ based on OpenMessaging.
|
||||
|
||||
|
||||
+3
-3
@@ -88,11 +88,11 @@ Messages can no longer be sent to this broker set, but if you have another broke
|
||||
|
||||
 2) Some slave crash
|
||||
|
||||
As long as there is another working slave, there will be no impact on sending messages. There will also be no impact on consuming messages except when the consumer group is set to consume from this slave preferably. By default, comsumer group consumes from master.
|
||||
As long as there is another working slave, there will be no impact on sending messages. There will also be no impact on consuming messages except when the consumer group is set to consume from this slave preferably. By default, consumer group consumes from master.
|
||||
|
||||
 3) All slaves crash
|
||||
|
||||
There will be no impact on sending messages to master, but, if the master is SYNC_MASTER, producer will get a SLAVE_NOT_AVAILABLE indicating that the message is not sent to any slaves. There will also be no impact on consuming messages except that if the consumer group is set to consume from slave preferably. By default, comsumer group consumes from master.
|
||||
There will be no impact on sending messages to master, but, if the master is SYNC_MASTER, producer will get a SLAVE_NOT_AVAILABLE indicating that the message is not sent to any slaves. There will also be no impact on consuming messages except that if the consumer group is set to consume from slave preferably. By default, consumer group consumes from master.
|
||||
|
||||
### 4. Producer complains “No Topic Route Info”, how to diagnose?
|
||||
|
||||
@@ -104,6 +104,6 @@ This happens when you are trying to send messages to a topic whose routing info
|
||||
|
||||
 3) Make sure that your brokers are sending heartbeats to the same list of name servers your producer is connecting to.
|
||||
|
||||
 4) Make sure that the topic’s permssion is 6(rw-), or at least 2(-w-).
|
||||
 4) Make sure that the topic’s permission is 6(rw-), or at least 2(-w-).
|
||||
|
||||
If you can’t find this topic, create it on a broker via admin tools command updateTopic or web console.
|
||||
|
||||
+1
-1
@@ -33,7 +33,7 @@ In the four cases of 1), 2), 3), and 4) where the hardware resource can be recov
|
||||
At least Once refers to that every message will be delivered at least once. RocketMQ supports this feature because the Consumer pulls the message locally and does not send an ack back to the server until it has consumed it.
|
||||
|
||||
## 6 Backtracking Consumption
|
||||
Backtracking consumption refers to that the Consumer has consumed the message successfully, but the business needs to consume again. To support this function, the message still needs to be retained after the Broker sends the message to the Consumer successfully. The re-consumption is normally based on time dimension. For example, after the recovery of the Consumer system failured, the data one hour ago needs to be re-consumed, then the Broker needs to provide a mechanism to reverse the consumption progress according to the time dimension. RocketMQ supports backtracking consumption by time trace, with the time dimension down to milliseconds.
|
||||
Backtracking consumption refers to that the Consumer has consumed the message successfully, but the business needs to consume again. To support this function, the message still needs to be retained after the Broker sends the message to the Consumer successfully. The re-consumption is normally based on time dimension. For example, after the recovery of the Consumer system failures, the data one hour ago needs to be re-consumed, then the Broker needs to provide a mechanism to reverse the consumption progress according to the time dimension. RocketMQ supports backtracking consumption by time trace, with the time dimension down to milliseconds.
|
||||
|
||||
## 7 Transactional Message
|
||||
RocketMQ transactional message refers to the fact that the application of a local transaction and the sending of a Message operation can be defined in a global transaction which means both succeed or failed simultaneously. RocketMQ transactional message provides distributed transaction functionality similar to X/Open XA, enabling the ultimate consistency of distributed transactions through transactional message.
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
### 1 Consumption process idempotent
|
||||
|
||||
RocketMQ cannot avoid Exactly-Once, so if the business is very sensitive to consumption repetition, it is important to perform deduplication at the business level. Deduplication can be done with a relational database. First, you need to determine the unique key of the message, which can be either msgId or a unique identifier field in the message content, such as the order Id. Determine if a unique key exists in the relational database before consumption. If it does not exist, insert it and consume it, otherwise skip it. (The actual process should consider the atomic problem, determine whether there is an attempt to insert, if the primary key conflicts, the insertion fails, skip directly)
|
||||
RocketMQ cannot achieve Exactly-Once, so if the business is very sensitive to consumption repetition, it is important to perform deduplication at the business level. Deduplication can be done with a relational database. First, you need to determine the unique key of the message, which can be either msgId or a unique identifier field in the message content, such as the order Id. Determine if a unique key exists in the relational database before consumption. If it does not exist, insert it and consume it, otherwise skip it. (The actual process should consider the atomic problem, determine whether there is an attempt to insert, if the primary key conflicts, the insertion fails, skip directly)
|
||||
|
||||
### 2 Slow message processing
|
||||
|
||||
@@ -27,7 +27,7 @@ When a message is accumulated, if the consumption speed cannot keep up with the
|
||||
public ConsumeConcurrentlyStatus consumeMessage(
|
||||
List<MessageExt> msgs,
|
||||
ConsumeConcurrentlyContext context){
|
||||
long offest = msgs.get(0).getQueueOffset();
|
||||
long offset = msgs.get(0).getQueueOffset();
|
||||
String maxOffset =
|
||||
msgs.get(0).getProperty(Message.PROPERTY_MAX_OFFSET);
|
||||
long diff = Long.parseLong(maxOffset) - offset;
|
||||
@@ -36,7 +36,7 @@ public ConsumeConcurrentlyStatus consumeMessage(
|
||||
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
|
||||
}
|
||||
//TODO Normal consumption process
|
||||
return ConcumeConcurrentlyStatus.CONSUME_SUCCESS;
|
||||
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
@@ -33,7 +33,7 @@ The send method of Producer can be retried, the retry process is illustrated be
|
||||
|
||||
The strategy above could make sure message sending successfully to a certain degree. Some more retry strategies, such as we could try to save the message to database if calling the send synchronous method failed and then retry by background thread's timed tasks, which will make sure the message is sent to Broker,could be improved if asking for high reliability business requirement.
|
||||
|
||||
The reasons why the retry strategy using database have not integrated by the RocketMQ client will be explained below: Firstly, the design mode of the RocketMQ client is stateless mode. It means that the client is designed to be horizontally scalable at each level and the consumption of the client to physical resources is only CPU, memory and network. Then, if a key-value memory module is integrated by the client itself, the Asyn-Saving strategy will be utilized in consideration of the high resource consumption of the Syn-Saving strategy. However, given that operations staff does not manage the client shutoff, some special commands, such as kill -9, may be used which will lead to the lost of message because of no saving in time. Furthermore, the physical resource running Producer is not appropriate to save some significant data because of low reliability. Above all, the retry process should be controlled by program itself.
|
||||
The reasons why the retry strategy using database have not integrated by the RocketMQ client will be explained below: Firstly, the design mode of the RocketMQ client is stateless mode. It means that the client is designed to be horizontally scalable at each level and the consumption of the client to physical resources is only CPU, memory and network. Then, if a key-value memory module is integrated by the client itself, the Async-Saving strategy will be utilized in consideration of the high resource consumption of the Syn-Saving strategy. However, given that operations staff does not manage the client shutoff, some special commands, such as kill -9, may be used which will lead to the lost of message because of no saving in time. Furthermore, the physical resource running Producer is not appropriate to save some significant data because of low reliability. Above all, the retry process should be controlled by program itself.
|
||||
|
||||
##### 3 Send Messages in One-way Mode
|
||||
The message sending is usually a process like below:
|
||||
|
||||
@@ -37,7 +37,7 @@ namesrvAddr=XX.XX.XX.XX:9876
|
||||
Each Broker node in the RocketMQ cluster is used to store message trace data collected and sent from the Client.Therefore, there are no requirements or restrictions on the number of Broker nodes in the RocketMQ cluster.
|
||||
|
||||
### 2.3 Physical IO Isolation Mode
|
||||
For scenarios with large amount of trace message data , one of the Broker nodes in the RocketMQ cluster can be selected to store the trace message , so that the common message data of the user and the physical IO of the trace message data are completely isolated from each other.In this mode, there are at least two Broker nodes in the RockeMQ cluster, one of which is defined as the server on which message trace data is stored.
|
||||
For scenarios with large amount of trace message data , one of the Broker nodes in the RocketMQ cluster can be selected to store the trace message , so that the common message data of the user and the physical IO of the trace message data are completely isolated from each other.In this mode, there are at least two Broker nodes in the RocketMQ cluster, one of which is defined as the server on which message trace data is stored.
|
||||
|
||||
### 2.4 Start the Broker that Starts the MessageTrace
|
||||
`nohup sh mqbroker -c ../conf/2m-noslave/broker-a.properties &`
|
||||
@@ -92,7 +92,7 @@ In order to reduce as much as possible the transformation work of RocketMQ messa
|
||||
```
|
||||
|
||||
### 4.3 Support for Custom Storage Message Trace Topic
|
||||
The initialization of `DefaultMQProducer` and `DefaultMQPushConsumer` instances can be changed to support the custom storage message trace Topic as follows when sending and subscriving messages above.
|
||||
The initialization of `DefaultMQProducer` and `DefaultMQPushConsumer` instances can be changed to support the custom storage message trace Topic as follows when sending and subscribing messages above.
|
||||
|
||||
```
|
||||
##Where Topic_test11111 needs to be pre-created by the user to save the message trace；
|
||||
|
||||
+1
-1
@@ -1,7 +1,7 @@
|
||||
Apache RocketMQ Developer Guide
|
||||
--------
|
||||
|
||||
##### This guide helps develpers understand and use Apache RocketMQ quickly.
|
||||
##### This guide helps developers to understand and use Apache RocketMQ quickly.
|
||||
|
||||
### 1. Concepts & Features
|
||||
|
||||
|
||||
@@ -73,4 +73,4 @@ SendResult [sendStatus=SEND_OK, msgId=0A42333A0DC818B4AAC246C290FD0000, offsetMs
|
||||
```
|
||||
|
||||
- msgId，for the client, the msgId is generated by the producer instance. Specifically, the method `MessageClientIDSetter.createUniqIDBuffer()` is called to generate a unique Id.
|
||||
- offsetMsgId, offsetMsgId is generated by the Broker server when writing a message ( string concating "IP address + port" and "CommitLog's physical offset address"), and offsetMsgId is the messageId used to query in the RocketMQ console.
|
||||
- offsetMsgId, offsetMsgId is generated by the Broker server when writing a message ( string consists of "IP address + port" and "CommitLog's physical offset address"), and offsetMsgId is the messageId used to query in the RocketMQ console.
|
||||
|
||||
@@ -73,4 +73,4 @@ The verification of the required permissions of the user requires attention to t
|
||||
(2) For a resource, if there is explicit configuration permission, the configured permission is used; if there is no explicit configuration permission, the default permission is adopted;
|
||||
|
||||
## 5. Hot loading modified Access control
|
||||
The default implementation of RocketrMQ's permission control store is based on the yml configuration file. Users can dynamically modify the properties defined by the permission control without restarting the Broker service node.
|
||||
The default implementation of RocketMQ's permission control store is based on the yml configuration file. Users can dynamically modify the properties defined by the permission control without restarting the Broker service node.
|
||||
|
||||
@@ -43,7 +43,7 @@ To make sure nothing lost, you should also enable the SYNC_MASTER or SYNC_FLUSH.
|
||||
- **FLUSH_DISK_TIMEOUT**
|
||||
|
||||
Message send successfully, but the server flush messages to disk timeout.At this point, the message has entered the server's memory, and the message will be lost only when the server is down.
|
||||
Flush mode and sync flush time interval can be set in the configuration parameters. It will return FLUSH_DISK_TIMEOUT when Broker server doesn't finish flush message to disk in timout(default is 5s
|
||||
Flush mode and sync flush time interval can be set in the configuration parameters. It will return FLUSH_DISK_TIMEOUT when Broker server doesn't finish flush message to disk in timeout(default is 5s
|
||||
) when sets FlushDiskType=SYNC_FLUSH(default is async flush).
|
||||
|
||||
- **FLUSH_SLAVE_TIMEOUT**
|
||||
|
||||
+1
-1
@@ -5,7 +5,7 @@
|
||||
|
||||
|
||||
|
||||
#### 1.1 The Architecure of Message Store
|
||||
#### 1.1 The Architecture of Message Store
|
||||
|
||||
#### 1.2 PageCache and Memory-Map(Mmap)
|
||||
|
||||
|
||||
@@ -104,7 +104,7 @@ Adjusting instantiation of DefaultMQProducer and DefaultMQPushConsumer as follow
|
||||
### 4.4 Send and query message trace by mqadmin command
|
||||
- send message
|
||||
```shell
|
||||
./mqadmin sendMessage -m true --topic some-topic-name -n 127.0.0.1:9876 -p "your meesgae content"
|
||||
./mqadmin sendMessage -m true --topic some-topic-name -n 127.0.0.1:9876 -p "your message content"
|
||||
```
|
||||
- query trace
|
||||
```shell
|
||||
|
||||
+33
-33
@@ -104,7 +104,7 @@ $ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broke
|
||||
|
||||
Each Master node is equipped with one Slave node, this mode has many Master-Slave group, using synchronous double write for HA, application's write operation is successful means both master and slave write successful, advantages and disadvantages of this mode are shown below:
|
||||
|
||||
- advantages:both data and service have no single point failure, message has no lantancy even if Master is down, service available and data available is very high;
|
||||
- advantages:both data and service have no single point failure, message has no latency even if Master is down, service available and data available is very high;
|
||||
|
||||
- disadvantages:this mode's performance is 10% lower than async replication mode, sending latency is a little high, in the current version, it do not have auto Master-Slave switch when Master is down.
|
||||
|
||||
@@ -158,7 +158,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td height=23 class=xl63 width=177 style='height:17.0pt;width:133pt'>name</td>
|
||||
<td class=xl64 width=175 style='width:131pt'>meaning</td>
|
||||
<td class=xl64 width=177 style='width:133pt'>command items</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explaination</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explanation</td>
|
||||
</tr>
|
||||
<tr height=132 style='height:99.0pt'>
|
||||
<td rowspan=8 height=593 class=xl68 width=163 style='border-bottom:1.0pt;
|
||||
@@ -170,7 +170,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
</tr>
|
||||
<tr height=132 style='height:99.0pt'>
|
||||
<td height=132 class=xl65 width=149 style='height:99.0pt;width:112pt'>-c</td>
|
||||
<td class=xl66 width=159 style='width:119pt'>cluster name, whic cluster that topic belongs to(query cluster info by clusterList)</td>
|
||||
<td class=xl66 width=159 style='width:119pt'>cluster name, which cluster that topic belongs to(query cluster info by clusterList)</td>
|
||||
</tr>
|
||||
<tr height=23 style='height:17.0pt'>
|
||||
<td height=23 class=xl65 width=149 style='height:17.0pt;width:112pt'>-h-</td>
|
||||
@@ -226,7 +226,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
</tr>
|
||||
<tr height=207 style='height:155.0pt'>
|
||||
<td height=207 class=xl65 width=149 style='height:155.0pt;width:112pt'>-c</td>
|
||||
<td class=xl66 width=159 style='width:119pt'>return topic list only if do not contains -c, if containis -c, it will return cluster name, topic name, consumer group name</td>
|
||||
<td class=xl66 width=159 style='width:119pt'>return topic list only if do not contains -c, if contains -c, it will return cluster name, topic name, consumer group name</td>
|
||||
</tr>
|
||||
<tr height=57 style='height:43.0pt'>
|
||||
<td height=57 class=xl65 width=149 style='height:43.0pt;width:112pt'>-n</td>
|
||||
@@ -306,7 +306,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
</tr>
|
||||
<tr height=207 style='height:155.0pt'>
|
||||
<td height=207 class=xl65 width=149 style='height:155.0pt;width:112pt'>-c</td>
|
||||
<td class=xl66 width=159 style='width:119pt'>cluster name, which topic belongs to(query cluster info by clusterList), if do not have -b, execute comman an all brokers.</td>
|
||||
<td class=xl66 width=159 style='width:119pt'>cluster name, which topic belongs to(query cluster info by clusterList), if do not have -b, execute command on all brokers.</td>
|
||||
</tr>
|
||||
<tr height=23 style='height:17.0pt'>
|
||||
<td rowspan=5 height=199 class=xl68 width=163 style='border-bottom:1.0pt;
|
||||
@@ -350,7 +350,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
</tr>
|
||||
<tr height=95 style='height:71.0pt'>
|
||||
<td height=95 class=xl65 width=149 style='height:71.0pt;width:112pt'>-i</td>
|
||||
<td class=xl66 width=159 style='width:119pt'>ipList, seperate by comma, calculate which topic queue that ips will load.</td>
|
||||
<td class=xl66 width=159 style='width:119pt'>ipList, separate by comma, calculate which topic queue that ips will load.</td>
|
||||
</tr>
|
||||
<tr height=23 style='height:17.0pt'>
|
||||
<td rowspan=4 height=142 class=xl68 width=163 style='border-bottom:1.0pt solid black;
|
||||
@@ -387,7 +387,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td height=23 class=xl63 width=177 style='height:17.0pt;width:133pt'>名称</td>
|
||||
<td class=xl64 width=175 style='width:131pt'>meaning</td>
|
||||
<td class=xl64 width=177 style='width:133pt'>command items</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explaination</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explanation</td>
|
||||
</tr>
|
||||
<tr height=207 style='height:155.0pt'>
|
||||
<td rowspan=4 height=326 class=xl67 width=177 style='border-bottom:1.0pt;
|
||||
@@ -429,7 +429,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
</tr>
|
||||
<tr height=76 style='height:57.0pt'>
|
||||
<td height=76 class=xl65 width=177 style='height:57.0pt;width:133pt'>-p</td>
|
||||
<td class=xl66 width=185 style='width:139pt'>whether print format log, splitted by |, default is not print</td>
|
||||
<td class=xl66 width=185 style='width:139pt'>whether print format log, split by |, default is not print</td>
|
||||
</tr>
|
||||
<tr height=23 style='height:17.0pt'>
|
||||
<td height=23 class=xl65 width=177 style='height:17.0pt;width:133pt'>-h</td>
|
||||
@@ -461,7 +461,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td height=23 class=xl63 width=177 style='height:17.0pt;width:133pt'>名称</td>
|
||||
<td class=xl64 width=175 style='width:131pt'>meaning</td>
|
||||
<td class=xl64 width=177 style='width:133pt'>command items</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explaination</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explanation</td>
|
||||
</tr>
|
||||
<tr height=57 style='height:43.0pt'>
|
||||
<td rowspan=6 height=206 class=xl69 width=191 style='border-bottom:1.0pt;
|
||||
@@ -497,7 +497,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td rowspan=3 class=xl72 width=87 style='border-bottom:1.0pt;
|
||||
border-top:none;width:65pt'>get Broker's statistics info, running status(including whatever you want).</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>-b</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>Broker address, fomat isip:port</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>Broker address, format is ip:port</td>
|
||||
</tr>
|
||||
<tr height=23 style='height:17.0pt'>
|
||||
<td height=23 class=xl67 width=87 style='height:17.0pt;width:65pt'>-h</td>
|
||||
@@ -511,9 +511,9 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td rowspan=6 height=256 class=xl69 width=191 style='border-bottom:1.0pt;
|
||||
height:192.0pt;border-top:none;width:143pt'>brokerConsumeStats</td>
|
||||
<td rowspan=6 class=xl72 width=87 style='border-bottom:1.0pt;
|
||||
border-top:none;width:65pt'>Broker's consumer info, including Consume Offset, Broker Offset, Diff, Timestamp that ordered by essage Queue</td>
|
||||
border-top:none;width:65pt'>Broker's consumer info, including Consume Offset, Broker Offset, Diff, Timestamp that ordered by message Queue</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>-b</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>Broker address, fomat isip:port</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>Broker address, format is ip:port</td>
|
||||
</tr>
|
||||
<tr height=23 style='height:17.0pt'>
|
||||
<td height=23 class=xl67 width=87 style='height:17.0pt;width:65pt'>-t</td>
|
||||
@@ -525,7 +525,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
</tr>
|
||||
<tr height=57 style='height:43.0pt'>
|
||||
<td height=57 class=xl67 width=87 style='height:43.0pt;width:65pt'>-o</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>whether is sequencial topic, generally false</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>whether is sequential topic, generally false</td>
|
||||
</tr>
|
||||
<tr height=23 style='height:17.0pt'>
|
||||
<td height=23 class=xl67 width=87 style='height:17.0pt;width:65pt'>-h</td>
|
||||
@@ -541,7 +541,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td rowspan=2 class=xl72 width=87 style='border-bottom:1.0pt
|
||||
border-top:none;width:65pt'>get Broker's config</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>-b</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>Broker address, fomat isip:port</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>Broker address, format is ip:port</td>
|
||||
</tr>
|
||||
<tr height=57 style='height:43.0pt'>
|
||||
<td height=57 class=xl67 width=87 style='height:43.0pt;width:65pt'>-n</td>
|
||||
@@ -553,7 +553,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td rowspan=3 class=xl72 width=87 style='border-bottom:1.0pt
|
||||
border-top:none;width:65pt'>revoke broker's write authority from NameServer.</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>-b</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>Broker address, fomat isip:port</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>Broker address, format is ip:port</td>
|
||||
</tr>
|
||||
<tr height=57 style='height:43.0pt'>
|
||||
<td height=57 class=xl67 width=87 style='height:43.0pt;width:65pt'>-n</td>
|
||||
@@ -577,7 +577,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
</tr>
|
||||
<tr height=57 style='height:43.0pt'>
|
||||
<td height=57 class=xl67 width=87 style='height:43.0pt;width:65pt'>-b</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>Broker address, fomat isip:port</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>Broker address, format is ip:port</td>
|
||||
</tr>
|
||||
<tr height=23 style='height:17.0pt'>
|
||||
<td height=23 class=xl67 width=87 style='height:17.0pt;width:65pt'>-c</td>
|
||||
@@ -587,7 +587,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td rowspan=4 height=191 class=xl69 width=191 style='border-bottom:1.0pt;
|
||||
height:143.0pt;border-top:none;width:143pt'>cleanUnusedTopic</td>
|
||||
<td rowspan=4 class=xl72 width=87 style='border-bottom:1.0pt
|
||||
border-top:none;width:65pt'>clean Broker's unused Topic that deleted mannually to release memory that Topic's Consume Queue occupied.</td>
|
||||
border-top:none;width:65pt'>clean Broker's unused Topic that deleted manually to release memory that Topic's Consume Queue occupied.</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>-n</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>NameServer Service address, format is ip:port</td>
|
||||
</tr>
|
||||
@@ -597,7 +597,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
</tr>
|
||||
<tr height=57 style='height:43.0pt'>
|
||||
<td height=57 class=xl67 width=87 style='height:43.0pt;width:65pt'>-b</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>Broker address, fomat isip:port</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>Broker address, format is ip:port</td>
|
||||
</tr>
|
||||
<tr height=23 style='height:17.0pt'>
|
||||
<td height=23 class=xl67 width=87 style='height:17.0pt;width:65pt'>-c</td>
|
||||
@@ -641,7 +641,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td height=23 class=xl63 width=177 style='height:17.0pt;width:133pt'>名称</td>
|
||||
<td class=xl64 width=175 style='width:131pt'>meaning</td>
|
||||
<td class=xl64 width=177 style='width:133pt'>command items</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explaination</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explanation</td>
|
||||
</tr>
|
||||
<tr height=128 style='height:96.0pt'>
|
||||
<td rowspan=3 height=208 class=xl69 width=87 style='border-bottom:1.0pt;
|
||||
@@ -721,7 +721,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
</tr>
|
||||
<tr height=23 style='height:17.0pt'>
|
||||
<td height=23 class=xl67 width=87 style='height:17.0pt;width:65pt'>-i</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>uniqe msg id</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>unique msg id</td>
|
||||
</tr>
|
||||
<tr height=36 style='height:27.0pt'>
|
||||
<td height=36 class=xl67 width=87 style='height:27.0pt;width:65pt'>-g</td>
|
||||
@@ -739,7 +739,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td rowspan=5 height=149 class=xl69 width=87 style='border-bottom:1.0pt
|
||||
height:111.0pt;border-top:none;width:65pt'>checkMsgSendRT</td>
|
||||
<td rowspan=5 class=xl72 width=87 style='border-bottom:1.0pt;
|
||||
border-top:none;width:65pt'>detect RT of sending a message to a topic, similiar to clusterRT</td>
|
||||
border-top:none;width:65pt'>detect RT of sending a message to a topic, similar to clusterRT</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>-h</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>print help info</td>
|
||||
</tr>
|
||||
@@ -799,7 +799,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td rowspan=10 height=312 class=xl69 width=87 style='border-bottom:1.0pt;
|
||||
height:232.0pt;border-top:none;width:65pt'>consumeMessage</td>
|
||||
<td rowspan=10 class=xl72 width=87 style='border-bottom:1.0pt;
|
||||
border-top:none;width:65pt'>consume message. Differert consume logic depends on offset, start & end timestamp, message queue, please refer to ConsumeMessageCommand for details.</td>
|
||||
border-top:none;width:65pt'>consume message. Different consume logic depends on offset, start & end timestamp, message queue, please refer to ConsumeMessageCommand for details.</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>-h</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>print help info</td>
|
||||
</tr>
|
||||
@@ -825,7 +825,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
</tr>
|
||||
<tr height=23 style='height:17.0pt'>
|
||||
<td height=23 class=xl67 width=87 style='height:17.0pt;width:65pt'>-g</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>consumer gropu</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>consumer group</td>
|
||||
</tr>
|
||||
<tr height=39 style='height:29.0pt'>
|
||||
<td height=39 class=xl67 width=87 style='height:29.0pt;width:65pt'>-s</td>
|
||||
@@ -865,7 +865,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
</tr>
|
||||
<tr height=39 style='height:29.0pt'>
|
||||
<td height=39 class=xl67 width=87 style='height:29.0pt;width:65pt'>-b</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>timestap at start, refer to -h to get format</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>timestamp at start, refer to -h to get format</td>
|
||||
</tr>
|
||||
<tr height=23 style='height:17.0pt'>
|
||||
<td height=23 class=xl67 width=87 style='height:17.0pt;width:65pt'>-e</td>
|
||||
@@ -931,7 +931,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td rowspan=7 height=410 class=xl69 width=87 style='border-bottom:1.0pt;
|
||||
height:307.0pt;border-top:none;width:65pt'>resetOffsetByTime</td>
|
||||
<td rowspan=7 class=xl72 width=87 style='border-bottom:1.0pt;
|
||||
border-top:none;width:65pt'>reset offset by timestamp, Broker and consumer will all be reseted</td>
|
||||
border-top:none;width:65pt'>reset offset by timestamp, Broker and consumer will all be reset</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>-h</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>print help info</td>
|
||||
</tr>
|
||||
@@ -973,7 +973,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td height=23 class=xl63 width=177 style='height:17.0pt;width:133pt'>name</td>
|
||||
<td class=xl64 width=175 style='width:131pt'>meaning</td>
|
||||
<td class=xl64 width=177 style='width:133pt'>command items</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explaination</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explanation</td>
|
||||
</tr>
|
||||
<tr height=39 style='height:29.0pt'>
|
||||
<td rowspan=4 height=158 class=xl69 width=87 style='border-bottom:1.0pt;
|
||||
@@ -1069,7 +1069,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
</tr>
|
||||
<tr height=132 style='height:99.0pt'>
|
||||
<td height=132 class=xl67 width=87 style='height:99.0pt;width:65pt'>-w</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>If broker consume from slave, whic slave node depends on this config that configed by BrokerId, eg: 1.</td>
|
||||
<td class=xl68 width=87 style='width:65pt'>If broker consume from slave, which slave node depends on this config that defined by BrokerId, eg: 1.</td>
|
||||
</tr>
|
||||
<tr height=76 style='height:57.0pt'>
|
||||
<td height=76 class=xl67 width=87 style='height:57.0pt;width:65pt'>-a</td>
|
||||
@@ -1143,11 +1143,11 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td height=23 class=xl63 width=177 style='height:17.0pt;width:133pt'>name</td>
|
||||
<td class=xl64 width=175 style='width:131pt'>meaning</td>
|
||||
<td class=xl64 width=177 style='width:133pt'>command items</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explaination</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explanation</td>
|
||||
</tr>
|
||||
<tr height=39 style='height:29.0pt'>
|
||||
<td rowspan=3 height=119 class=xl69 width=87 style='border-bottom:1.0pt
|
||||
height:89.0pt;border-top:none;width:65pt'>consumerConnec tion</td>
|
||||
height:89.0pt;border-top:none;width:65pt'>consumerConnection</td>
|
||||
<td rowspan=3 class=xl72 width=87 style='border-bottom:1.0pt
|
||||
border-top:none;width:65pt'>query Consumer's connection</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>-g</td>
|
||||
@@ -1163,7 +1163,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
</tr>
|
||||
<tr height=39 style='height:29.0pt'>
|
||||
<td rowspan=4 height=142 class=xl69 width=87 style='border-bottom:1.0pt
|
||||
height:106.0pt;border-top:none;width:65pt'>producerConnec tion</td>
|
||||
height:106.0pt;border-top:none;width:65pt'>producerConnection</td>
|
||||
<td rowspan=4 class=xl72 width=87 style='border-bottom:1.0pt
|
||||
border-top:none;width:65pt'>query Producer's connection</td>
|
||||
<td class=xl67 width=87 style='width:65pt'>-g</td>
|
||||
@@ -1197,7 +1197,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td height=23 class=xl63 width=177 style='height:17.0pt;width:133pt'>name</td>
|
||||
<td class=xl64 width=175 style='width:131pt'>meaning</td>
|
||||
<td class=xl64 width=177 style='width:133pt'>command items</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explaination</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explanation</td>
|
||||
</tr>
|
||||
<tr height=21 style='height:16.0pt'>
|
||||
<td rowspan=5 height=143 class=xl69 width=87 style='border-bottom:1.0pt
|
||||
@@ -1291,7 +1291,7 @@ The above Broker matches Slave by specifying the same BrokerName, Master's Broke
|
||||
<td height=23 class=xl63 width=177 style='height:17.0pt;width:133pt'>name</td>
|
||||
<td class=xl64 width=175 style='width:131pt'>meaning</td>
|
||||
<td class=xl64 width=177 style='width:133pt'>command items</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explaination</td>
|
||||
<td class=xl64 width=185 style='width:139pt'>explanation</td>
|
||||
</tr>
|
||||
<tr height=57 style='height:43.0pt'>
|
||||
<td rowspan=2 height=80 class=xl69 width=87 style='border-bottom:1.0pt
|
||||
@@ -1342,7 +1342,7 @@ Solution: rocketmq's default policy is consume from latest, that is skip oldest
|
||||
consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_LAST_OFFSET);
|
||||
```
|
||||
|
||||
- a new consumer group consume from oldest postion at first startup, then consume from last time's offset at next startup, that is consume the unexpired message;
|
||||
- a new consumer group consume from oldest position at first startup, then consume from last time's offset at next startup, that is consume the unexpired message;
|
||||
|
||||
```java
|
||||
consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);
|
||||
|
||||
Reference in New Issue
Block a user