You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by ju...@apache.org on 2023/02/22 07:01:05 UTC
[pulsar-site] branch main updated: fix doc (#429)
This is an automated email from the ASF dual-hosted git repository.
junma pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/pulsar-site.git
The following commit(s) were added to refs/heads/main by this push:
new 1381c894932 fix doc (#429)
1381c894932 is described below
commit 1381c894932b95da1a7a7bd908f731c20e9c1a18
Author: labuladong <la...@foxmail.com>
AuthorDate: Wed Feb 22 15:00:59 2023 +0800
fix doc (#429)
---
docs/concepts-messaging.md | 23 +++++++++++-----------
.../version-2.11.x/concepts-messaging.md | 23 +++++++++++-----------
2 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/docs/concepts-messaging.md b/docs/concepts-messaging.md
index 11fa5f009f2..e4d5826af73 100644
--- a/docs/concepts-messaging.md
+++ b/docs/concepts-messaging.md
@@ -215,7 +215,7 @@ consumer.acknowledge(message);
### Retry letter topic
-Retry letter topic allows you to store the messages that failed to be consumed and retry consuming them later. With this method, you can customize the interval at which the messages are redelivered. Consumers on the original topic are automatically subscribed to the retry letter topic as well. Once the maximum number of retries has been reached, the unconsumed messages are moved to a [dead letter topic](#dead-letter-topic) for manual processing. The functionality of a retry letter topic [...]
+Retry letter topic allows you to store the messages that failed to be consumed and retry consuming them later. With this method, you can customize the interval at which the messages are redelivered. Consumers on the original topic are automatically subscribed to the retry letter topic as well. Once the maximum number of retries has been reached, the unconsumed messages are moved to a [dead letter topic](#dead-letter-topic) for manual processing. The functionality of a retry letter topic [...]
The diagram below illustrates the concept of the retry letter topic.
@@ -301,7 +301,7 @@ consumer.reconsumeLater(msg, customProperties, 3, TimeUnit.SECONDS);
### Dead letter topic
-Dead letter topic allows you to continue message consumption even when some messages are not consumed successfully. The messages that have failed to be consumed are stored in a specific topic, which is called the dead letter topic. The functionality of a dead letter topic is implemented by consumers. You can decide how to handle the messages in the dead letter topic.
+Dead letter topic allows you to continue message consumption even when some messages are not consumed successfully. The messages that have failed to be consumed are stored in a specific topic, which is called the dead letter topic. The functionality of a dead letter topic is implemented by consumers. You can decide how to handle the messages in the dead letter topic.
Enable dead letter topic in a Java client using the default dead letter topic.
@@ -417,7 +417,6 @@ With message chunking enabled, when the size of a message exceeds the allowed ma
**Limitations:**
- Chunking is only available for persisted topics.
-- Chunking is only available for the exclusive and failover subscription types.
- Chunking cannot be enabled simultaneously with batching.
#### Handle consecutive chunked messages with one ordered consumer
@@ -543,17 +542,17 @@ In the diagram below, **Consumer A**, **Consumer B** and **Consumer C** are all
#### Key_Shared
-In the *Key_Shared* type, multiple consumers can attach to the same subscription. Messages are delivered in distribution across consumers and messages with the same key or same ordering key are delivered to only one consumer. No matter how many times the message is re-delivered, it is delivered to the same consumer.
+In the *Key_Shared* type, multiple consumers can attach to the same subscription. Messages are delivered in distribution across consumers and messages with the same key or same ordering key are delivered to only one consumer. No matter how many times the message is re-delivered, it is delivered to the same consumer.
There are three types of mapping algorithms dictating how to select a consumer for a given message key (or ordering key): Sticky, Auto-split Hash Range, and Auto-split Consistent Hashing. The steps for all algorithms are:
-1. The message key (or ordering key) is passed to a hash function (e.g., Murmur3 32-bit), yielding a 32-bit integer hash.
+1. The message key (or ordering key) is passed to a hash function (e.g., Murmur3 32-bit), yielding a 32-bit integer hash.
2. That hash number is fed to the algorithm to select a consumer from the existing connected consumers.
```
+--------------+ +-----------+
-Message Key -----> / Hash Function / ----- hash (32-bit) -------> / Algorithm / ----> Consumer
+Message Key -----> / Hash Function / ----- hash (32-bit) -------> / Algorithm / ----> Consumer
+---------------+ +----------+
```
@@ -605,7 +604,7 @@ C1 is disconnected:
|------- C3 ------|-------------------------- C2 -----------------------|
```
-The advantages of this algorithm is that it affects only a single existing consumer upon add/delete consumer, at the expense of regions not evenly sized. Thi means some consumers gets more keys that others. The next algorithm does the other way around.
+The advantages of this algorithm is that it affects only a single existing consumer upon add/delete consumer, at the expense of regions not evenly sized. Thi means some consumers gets more keys that others. The next algorithm does the other way around.
##### Auto-split Consistent Hashing
@@ -638,7 +637,7 @@ When adding a consumer, we mark 100 points on that circle and associate them to
Since the hash function has the uniform distribution attribute, those points would be uniformly distributed across the circle.
```
- C1-100
+ C1-100
, - ~ ~ ~ - , C1-1
, ' ' ,
, ,
@@ -650,7 +649,7 @@ Since the hash function has the uniform distribution attribute, those points wou
, ,
, , '
' - , _ _ _ , ' ...
-
+
```
A consumer is selected for a given message key by putting its hash on the circle then continue clock-wise on the circle until you reach a marking point. The point might have more than one consumer on it (hash function might have collisions) there for, we run the following operation to get a position within the list of consumers for that point, then we take the consumer in that position: `hash % consumer_list_size = index`.
@@ -669,7 +668,7 @@ Suppose we have 2 consumers (C1 and C2) each specified their ranges, then:
```
C1 = [0, 16384), [32768, 49152)
C2 = [16384, 32768), [49152, 65536)
-
+
0 16,384 32,768 49,152 65,536
|------- C1 ------|------- C2 ------|------- C1 ------|------- C2 ------|
```
@@ -680,7 +679,7 @@ If the newly connected consumer didn't supply their ranges, or they overlap with
##### How to use them?
-When building the consumer, you can specify the Key Shared Mode:
+When building the consumer, you can specify the Key Shared Mode:
* AUTO_SPLIT - Auto-split Hash Range
* STICKY - Sticky
@@ -696,7 +695,7 @@ That requirement can be relaxed by enabling `allowOutOfOrderDelivery` via the Co
:::note
-When the consumers are using the Key_Shared subscription type, you need to **disable batching** or **use key-based batching** for the producers.
+When the consumers are using the Key_Shared subscription type, you need to **disable batching** or **use key-based batching** for the producers.
:::
There are two reasons why the key-based batching is necessary for the Key_Shared subscription type:
diff --git a/versioned_docs/version-2.11.x/concepts-messaging.md b/versioned_docs/version-2.11.x/concepts-messaging.md
index a1dc0f002cb..1d549b79c79 100644
--- a/versioned_docs/version-2.11.x/concepts-messaging.md
+++ b/versioned_docs/version-2.11.x/concepts-messaging.md
@@ -145,7 +145,6 @@ With message chunking enabled, when the size of a message exceeds the allowed ma
**Limitations:**
- Chunking is only available for persisted topics.
-- Chunking is only available for the exclusive and failover subscription types.
- Chunking cannot be enabled simultaneously with batching.
#### Handle consecutive chunked messages with one ordered consumer
@@ -362,7 +361,7 @@ consumer.acknowledge(message);
### Retry letter topic
-Retry letter topic allows you to store the messages that failed to be consumed and retry consuming them later. With this method, you can customize the interval at which the messages are redelivered. Consumers on the original topic are automatically subscribed to the retry letter topic as well. Once the maximum number of retries has been reached, the unconsumed messages are moved to a [dead letter topic](#dead-letter-topic) for manual processing. The functionality of a retry letter topic [...]
+Retry letter topic allows you to store the messages that failed to be consumed and retry consuming them later. With this method, you can customize the interval at which the messages are redelivered. Consumers on the original topic are automatically subscribed to the retry letter topic as well. Once the maximum number of retries has been reached, the unconsumed messages are moved to a [dead letter topic](#dead-letter-topic) for manual processing. The functionality of a retry letter topic [...]
The diagram below illustrates the concept of the retry letter topic.
@@ -448,7 +447,7 @@ consumer.reconsumeLater(msg, customProperties, 3, TimeUnit.SECONDS);
### Dead letter topic
-Dead letter topic allows you to continue message consumption even when some messages are not consumed successfully. The messages that have failed to be consumed are stored in a specific topic, which is called the dead letter topic. The functionality of a dead letter topic is implemented by consumers. You can decide how to handle the messages in the dead letter topic.
+Dead letter topic allows you to continue message consumption even when some messages are not consumed successfully. The messages that have failed to be consumed are stored in a specific topic, which is called the dead letter topic. The functionality of a dead letter topic is implemented by consumers. You can decide how to handle the messages in the dead letter topic.
Enable dead letter topic in a Java client using the default dead letter topic.
@@ -598,17 +597,17 @@ In the diagram below, **Consumer A**, **Consumer B** and **Consumer C** are all
#### Key_Shared
-In the *Key_Shared* type, multiple consumers can attach to the same subscription. Messages are delivered in distribution across consumers and messages with the same key or same ordering key are delivered to only one consumer. No matter how many times the message is re-delivered, it is delivered to the same consumer.
+In the *Key_Shared* type, multiple consumers can attach to the same subscription. Messages are delivered in distribution across consumers and messages with the same key or same ordering key are delivered to only one consumer. No matter how many times the message is re-delivered, it is delivered to the same consumer.
There are three types of mapping algorithms dictating how to select a consumer for a given message key (or ordering key): Sticky, Auto-split Hash Range, and Auto-split Consistent Hashing. The steps for all algorithms are:
-1. The message key (or ordering key) is passed to a hash function (e.g., Murmur3 32-bit), yielding a 32-bit integer hash.
+1. The message key (or ordering key) is passed to a hash function (e.g., Murmur3 32-bit), yielding a 32-bit integer hash.
2. That hash number is fed to the algorithm to select a consumer from the existing connected consumers.
```
+--------------+ +-----------+
-Message Key -----> / Hash Function / ----- hash (32-bit) -------> / Algorithm / ----> Consumer
+Message Key -----> / Hash Function / ----- hash (32-bit) -------> / Algorithm / ----> Consumer
+---------------+ +----------+
```
@@ -660,7 +659,7 @@ C1 is disconnected:
|------- C3 ------|-------------------------- C2 -----------------------|
```
-The advantages of this algorithm is that it affects only a single existing consumer upon add/delete consumer, at the expense of regions not evenly sized. Thi means some consumers gets more keys that others. The next algorithm does the other way around.
+The advantages of this algorithm is that it affects only a single existing consumer upon add/delete consumer, at the expense of regions not evenly sized. Thi means some consumers gets more keys that others. The next algorithm does the other way around.
##### Auto-split Consistent Hashing
@@ -693,7 +692,7 @@ When adding a consumer, we mark 100 points on that circle and associate them to
Since the hash function has the uniform distribution attribute, those points would be uniformly distributed across the circle.
```
- C1-100
+ C1-100
, - ~ ~ ~ - , C1-1
, ' ' ,
, ,
@@ -705,7 +704,7 @@ Since the hash function has the uniform distribution attribute, those points wou
, ,
, , '
' - , _ _ _ , ' ...
-
+
```
A consumer is selected for a given message key by putting its hash on the circle then continue clock-wise on the circle until you reach a marking point. The point might have more than one consumer on it (hash function might have collisions) there for, we run the following operation to get a position within the list of consumers for that point, then we take the consumer in that position: `hash % consumer_list_size = index`.
@@ -724,7 +723,7 @@ Suppose we have 2 consumers (C1 and C2) each specified their ranges, then:
```
C1 = [0, 16384), [32768, 49152)
C2 = [16384, 32768), [49152, 65536)
-
+
0 16,384 32,768 49,152 65,536
|------- C1 ------|------- C2 ------|------- C1 ------|------- C2 ------|
```
@@ -735,7 +734,7 @@ If the newly connected consumer didn't supply their ranges, or they overlap with
##### How to use them?
-When building the consumer, you can specify the Key Shared Mode:
+When building the consumer, you can specify the Key Shared Mode:
* AUTO_SPLIT - Auto-split Hash Range
* STICKY - Sticky
@@ -751,7 +750,7 @@ That requirement can be relaxed by enabling `allowOutOfOrderDelivery` via the Co
:::note
-When the consumers are using the Key_Shared subscription type, you need to **disable batching** or **use key-based batching** for the producers.
+When the consumers are using the Key_Shared subscription type, you need to **disable batching** or **use key-based batching** for the producers.
:::
There are two reasons why the key-based batching is necessary for the Key_Shared subscription type: