This is an automated email from the ASF dual-hosted git repository.
lhotari 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 0b060fd55e3 docs: add hyperlinks for common keywords on
getting-started + architecture pages (partial #23150) (#1135)
0b060fd55e3 is described below
commit 0b060fd55e3553313e0fe5a44a304047ab18a2d2
Author: Mukunda Rao Katta <[email protected]>
AuthorDate: Sun May 3 23:12:18 2026 -0700
docs: add hyperlinks for common keywords on getting-started + architecture
pages (partial #23150) (#1135)
* docs: add hyperlinks for common keywords on getting-started +
architecture pages (partial #23150)
Adds inline cross-reference links for high-traffic keywords (Topic,
Subscription, Producer, Consumer, Broker, BookKeeper, Cluster,
Namespace, Metadata store) on a small starter set of pages so readers
can jump to the primary definition pages from the first mention.
Pages touched:
- docs/getting-started-home.md
- docs/getting-started-standalone.md
- docs/getting-started-docker.md
- docs/concepts-architecture-overview.md
Partial fix for #23150 - establishes the linking pattern; remaining
pages can follow in subsequent PRs.
Signed-off-by: Mukunda Katta <[email protected]>
* Revert change in stats example
* Apply similar changes to versioned_docs
---------
Signed-off-by: Mukunda Katta <[email protected]>
Co-authored-by: Lari Hotari <[email protected]>
---
docs/concepts-architecture-overview.md | 32 +++++++++++-----------
docs/getting-started-docker.md | 10 +++----
docs/getting-started-home.md | 4 ++-
docs/getting-started-standalone.md | 14 +++++-----
.../concepts-architecture-overview.md | 24 ++++++++--------
.../version-4.0.x/getting-started-docker.md | 6 ++--
.../version-4.0.x/getting-started-home.md | 4 ++-
.../version-4.0.x/getting-started-standalone.md | 14 +++++-----
.../concepts-architecture-overview.md | 24 ++++++++--------
.../version-4.2.x/getting-started-docker.md | 10 +++----
.../version-4.2.x/getting-started-home.md | 4 ++-
.../version-4.2.x/getting-started-standalone.md | 14 +++++-----
12 files changed, 83 insertions(+), 77 deletions(-)
diff --git a/docs/concepts-architecture-overview.md
b/docs/concepts-architecture-overview.md
index 31e7a9cb654..c89bd5cec1f 100644
--- a/docs/concepts-architecture-overview.md
+++ b/docs/concepts-architecture-overview.md
@@ -5,11 +5,11 @@ sidebar_label: "Architecture"
description: Get a comprehensive understanding of the architecture of Apache
Pulsar
---
-At the highest level, a Pulsar instance is composed of one or more Pulsar
clusters. Clusters within an instance can [replicate](concepts-replication.md)
data amongst themselves.
+At the highest level, a Pulsar instance is composed of one or more Pulsar
[clusters](#clusters). Clusters within an instance can
[replicate](concepts-replication.md) data amongst themselves.
A Pulsar cluster consists of the following components:
-* One or more brokers handles and [load
balances](administration-load-balance.md) incoming messages from producers,
dispatches messages to consumers, communicates with the Pulsar metadata store
to handle various coordination tasks, stores messages in BookKeeper instances
(aka bookies), and coordinates cluster operations through the metadata store.
+* One or more [brokers](#brokers) handles and [load
balances](administration-load-balance.md) incoming messages from
[producers](concepts-clients.md#producer), dispatches messages to
[consumers](concepts-clients.md#consumer), communicates with the Pulsar
[metadata store](#metadata-store) to handle various coordination tasks, stores
messages in [BookKeeper](#apache-bookkeeper) instances (aka bookies), and
coordinates cluster operations through the metadata store.
* A BookKeeper cluster consisting of one or more bookies handles [persistent
storage](#persistent-storage) of messages.
* A metadata store cluster (ZooKeeper, etcd, or other supported backend)
handles coordination tasks and cluster-specific metadata storage.
@@ -17,18 +17,18 @@ The diagram below illustrates a Pulsar cluster:
-At the broader instance level, an instance-wide ZooKeeper cluster called the
configuration store handles coordination tasks involving multiple clusters, for
example, [geo-replication](concepts-replication.md).
+At the broader instance level, an instance-wide ZooKeeper cluster called the
[configuration store](#configuration-store) handles coordination tasks
involving multiple clusters, for example,
[geo-replication](concepts-replication.md).
## Brokers
The Pulsar message broker is a stateless component that's primarily
responsible for running two other components:
-* An HTTP server that exposes a {@inject: rest:REST:/} API for both
administrative tasks and [topic lookup](concepts-clients.md#client-setup-phase)
for producers and consumers. The producers connect to the brokers to publish
messages and the consumers connect to the brokers to consume the messages.
+* An HTTP server that exposes a {@inject: rest:REST:/} API for both
administrative tasks and [topic lookup](concepts-clients.md#client-setup-phase)
for [producers](concepts-clients.md#producer) and
[consumers](concepts-clients.md#consumer). The producers connect to the brokers
to publish messages and the consumers connect to the brokers to consume the
messages.
* A dispatcher, which is an asynchronous TCP server over a custom [binary
protocol](developing-binary-protocol.md) used for all data transfers
-Messages are typically dispatched out of a [managed ledger](#managed-ledgers)
cache for the sake of performance, *unless* the backlog exceeds the cache size.
If the backlog grows too large for the cache, the broker will start reading
entries from BookKeeper.
+Messages are typically dispatched out of a [managed ledger](#managed-ledgers)
cache for the sake of performance, *unless* the backlog exceeds the cache size.
If the backlog grows too large for the cache, the broker will start reading
entries from [BookKeeper](#apache-bookkeeper).
-Finally, to support geo-replication on global topics, the broker manages
replicators that tail the entries published in the local region and republish
them to the remote region using the Pulsar [Java client
library](/docs/client-libraries/java).
+Finally, to support [geo-replication](concepts-replication.md) on global
[topics](concepts-messaging.md#topics), the broker manages replicators that
tail the entries published in the local region and republish them to the remote
region using the Pulsar [Java client library](/docs/client-libraries/java).
> For a guide to managing Pulsar brokers, see the
> [brokers](admin-api-brokers.md) guide.
@@ -38,7 +38,7 @@ A Pulsar instance consists of one or more Pulsar *clusters*.
Clusters, in turn,
* One or more Pulsar [brokers](#brokers)
* A ZooKeeper quorum used for cluster-level configuration and coordination
-* An ensemble of bookies used for [persistent storage](#persistent-storage) of
messages
+* An ensemble of [bookies](#apache-bookkeeper) used for [persistent
storage](#persistent-storage) of messages
Clusters can replicate among themselves using
[geo-replication](concepts-replication.md).
@@ -46,7 +46,7 @@ Clusters can replicate among themselves using
[geo-replication](concepts-replica
## Metadata store
-The Pulsar metadata store maintains all the metadata of a Pulsar cluster, such
as topic metadata, schema, broker load data, and so on. Pulsar supports
multiple metadata store backends to provide flexibility in deployment
architectures and operational requirements:
+The Pulsar metadata store maintains all the metadata of a Pulsar cluster, such
as [topic](concepts-messaging.md#topics) metadata,
[schema](schema-overview.md), broker load data, and so on. Pulsar supports
multiple metadata store backends to provide flexibility in deployment
architectures and operational requirements:
### Supported Metadata Store Backends
@@ -79,24 +79,24 @@ The Pulsar metadata store can be deployed on a separate
cluster or integrated wi
In a Pulsar instance:
-* A configuration store quorum stores configuration for tenants, namespaces,
and other entities that need to be globally consistent.
-* Each cluster has its own local ZooKeeper ensemble that stores
cluster-specific configuration and coordination such as which brokers are
responsible for which topics as well as ownership metadata, broker load
reports, BookKeeper ledger metadata, and more.
+* A configuration store quorum stores configuration for
[tenants](concepts-multi-tenancy.md),
[namespaces](concepts-messaging.md#namespaces), and other entities that need to
be globally consistent.
+* Each cluster has its own local ZooKeeper ensemble that stores
cluster-specific configuration and coordination such as which brokers are
responsible for which [topics](concepts-messaging.md#topics) as well as
ownership metadata, broker load reports, BookKeeper ledger metadata, and more.
## Configuration store
-The configuration store is a ZooKeeper quorum that is used for
configuration-specific tasks and it maintains all the configurations of a
Pulsar instance, such as clusters, tenants, namespaces, partitioned
topic-related configurations, and so on. A Pulsar instance can have a single
local cluster, multiple local clusters, or multiple cross-region clusters.
Consequently, the configuration store can share the configurations across
multiple clusters under a Pulsar instance. The configuration [...]
+The configuration store is a ZooKeeper quorum that is used for
configuration-specific tasks and it maintains all the configurations of a
Pulsar instance, such as clusters, [tenants](concepts-multi-tenancy.md),
[namespaces](concepts-messaging.md#namespaces), partitioned topic-related
configurations, and so on. A Pulsar instance can have a single local cluster,
multiple local clusters, or multiple cross-region clusters. Consequently, the
configuration store can share the configurations acr [...]
## Persistent storage
-Pulsar provides guaranteed message delivery for applications. If a message
successfully reaches a Pulsar broker, it will be delivered to its intended
target.
+Pulsar provides guaranteed message delivery for applications. If a message
successfully reaches a Pulsar [broker](#brokers), it will be delivered to its
intended target.
-This guarantee requires that non-acknowledged messages are stored durably
until they can be delivered to and acknowledged by consumers. This mode of
messaging is commonly called *persistent messaging*. In Pulsar, N copies of all
messages are stored and synced on disk, for example, 4 copies across two
servers with mirrored [RAID](https://en.wikipedia.org/wiki/RAID) volumes on
each server.
+This guarantee requires that non-acknowledged messages are stored durably
until they can be delivered to and acknowledged by
[consumers](concepts-clients.md#consumer). This mode of messaging is commonly
called *persistent messaging*. In Pulsar, N copies of all messages are stored
and synced on disk, for example, 4 copies across two servers with mirrored
[RAID](https://en.wikipedia.org/wiki/RAID) volumes on each server.
### Apache BookKeeper
Pulsar uses a system called [Apache BookKeeper](http://bookkeeper.apache.org/)
for persistent message storage. BookKeeper is a distributed [write-ahead
log](https://en.wikipedia.org/wiki/Write-ahead_logging) (WAL) system that
provides several crucial advantages for Pulsar:
-* It enables Pulsar to utilize many independent logs, called
[ledgers](#ledgers). Multiple ledgers can be created for topics over time.
+* It enables Pulsar to utilize many independent logs, called
[ledgers](#ledgers). Multiple ledgers can be created for
[topics](concepts-messaging.md#topics) over time.
* It offers very efficient storage for sequential data that handles entry
replication.
* It guarantees read consistency of ledgers in the presence of various system
failures.
* It offers even distribution of I/O across bookies.
@@ -180,7 +180,7 @@ Some important things to know about the Pulsar proxy:
Service discovery is a mechanism that enables connecting
[clients](concepts-clients.md) to use just a single URL to interact with an
entire Pulsar instance.
-You can use your own service discovery system if you'd like. If you use your
own system, there is just one requirement: when a client performs an HTTP
request to an endpoint, such as `http://pulsar.us-west.example.com:8080`, the
client needs to be redirected to *some* active broker in the desired cluster,
whether via DNS, an HTTP or IP redirect, or some other means.
+You can use your own service discovery system if you'd like. If you use your
own system, there is just one requirement: when a client performs an HTTP
request to an endpoint, such as `http://pulsar.us-west.example.com:8080`, the
client needs to be redirected to *some* active [broker](#brokers) in the
desired cluster, whether via DNS, an HTTP or IP redirect, or some other means.
The diagram below illustrates Pulsar service discovery:
@@ -196,7 +196,7 @@ client = Client('pulsar://pulsar-cluster.acme.com:6650')
:::note
-In Pulsar, each topic is handled by only one broker. Initial requests from a
client to read, update or delete a topic are sent to a broker that may not be
the topic owner. If the broker cannot handle the request for this topic, it
redirects the request to the appropriate broker.
+In Pulsar, each [topic](concepts-messaging.md#topics) is handled by only one
[broker](#brokers). Initial requests from a client to read, update or delete a
topic are sent to a broker that may not be the topic owner. If the broker
cannot handle the request for this topic, it redirects the request to the
appropriate broker.
:::
diff --git a/docs/getting-started-docker.md b/docs/getting-started-docker.md
index 2cde0f54207..58fc5661f8f 100644
--- a/docs/getting-started-docker.md
+++ b/docs/getting-started-docker.md
@@ -62,11 +62,11 @@ bin/pulsar standalone --advertised-address localhost
:::tip
-These examples set `--advertised-address localhost` to preserve the previous
local Docker behavior. A client can connect to `localhost:6650` on the host
machine, and the broker will also advertise `localhost` back to the client as
the address to use for subsequent connections.
+These examples set `--advertised-address localhost` to preserve the previous
local Docker behavior. A client can connect to `localhost:6650` on the host
machine, and the [broker](concepts-architecture-overview.md#brokers) will also
advertise `localhost` back to the client as the address to use for subsequent
connections.
If you omit this option, Pulsar uses the container's FQDN by default. That
works when the advertised hostname is resolvable and reachable from your
clients, such as from other containers on the same network or from remote
hosts, but it can break host-machine clients if that FQDN is not reachable from
outside the container.
-By default, Pulsar uses RocksDB as the metadata store, which is recommended
for standalone instances.
+By default, Pulsar uses RocksDB as the [metadata
store](concepts-architecture-overview.md#metadata-store), which is recommended
for standalone instances.
If you encounter issues with RocksDB or need compatibility with existing
ZooKeeper-based installations, you can use ZooKeeper as the metadata store by
adding:
@@ -144,7 +144,7 @@ After starting Pulsar successfully, you can see
`INFO`-level log messages like t
:::tip
* To perform a health check, you can use the `bin/pulsar-admin brokers
healthcheck` command. For more information, see [Pulsar admin
docs](/reference/#/@pulsar:version_reference@/pulsar-admin/).
-* When you start a local standalone cluster, a `public/default` namespace is
created automatically. The namespace is used for development purposes. All
Pulsar topics are managed within namespaces. For more information, see
[Topics](concepts-messaging.md#topics).
+* When you start a local standalone cluster, a `public/default`
[namespace](concepts-messaging.md#namespaces) is created automatically. The
namespace is used for development purposes. All Pulsar topics are managed
within namespaces. For more information, see
[Topics](concepts-messaging.md#topics).
:::
@@ -166,7 +166,7 @@ pip install pulsar-client
### Consume a message
-Create a consumer and subscribe to the topic:
+Create a [consumer](concepts-clients.md#consumer) and
[subscribe](concepts-messaging.md#subscriptions) to the
[topic](concepts-messaging.md#topics):
```python
import pulsar
@@ -184,7 +184,7 @@ client.close()
### Produce a message
-Start a producer to send some test messages:
+Start a [producer](concepts-clients.md#producer) to send some test messages:
```python
import pulsar
diff --git a/docs/getting-started-home.md b/docs/getting-started-home.md
index 8cb765ab76a..b50b86c73de 100644
--- a/docs/getting-started-home.md
+++ b/docs/getting-started-home.md
@@ -8,5 +8,7 @@ Getting up and running with Pulsar is simple. Download it,
install it, and try i
You have three options. Click any of these links to begin your Pulsar journey!
* [Run a standalone Pulsar cluster locally](getting-started-standalone.md) -
Run a single instance of Pulsar in standalone mode on a single machine.
-* [Run a standalone Pulsar cluster in Docker](getting-started-docker.md) - Run
one or more instances of Pulsar in a Docker container. If you want to quickly
set up a small Pulsar cluster on your local laptop, go to [Run a Pulsar cluster
with Docker Compose](getting-started-docker-compose.md).
+* [Run a standalone Pulsar cluster in Docker](getting-started-docker.md) - Run
one or more instances of Pulsar in a Docker container. If you want to quickly
set up a small Pulsar [cluster](concepts-architecture-overview.md#clusters) on
your local laptop, go to [Run a Pulsar cluster with Docker
Compose](getting-started-docker-compose.md).
* [Run a standalone Pulsar cluster in Kubernetes](getting-started-helm.md) -
Run one or more instances of Pulsar in Kubernetes using a Helm chart.
+
+If you are new to Pulsar, you may also want to read the [Concepts and
Architecture](concepts-architecture-overview.md) guide and the
[Messaging](concepts-messaging.md) concepts (covering
[topics](concepts-messaging.md#topics),
[subscriptions](concepts-messaging.md#subscriptions),
[producers](concepts-clients.md#producer), and
[consumers](concepts-clients.md#consumer)) before diving in.
diff --git a/docs/getting-started-standalone.md
b/docs/getting-started-standalone.md
index 576b530a4dd..978946d251f 100644
--- a/docs/getting-started-standalone.md
+++ b/docs/getting-started-standalone.md
@@ -5,7 +5,7 @@ sidebar_label: "Run Pulsar locally"
description: Get started with Apache Pulsar on your local machine.
---
-For local development and testing, you can run Pulsar in standalone mode on
your machine. The standalone mode runs all components inside a single Java
Virtual Machine (JVM) process.
+For local development and testing, you can run Pulsar in standalone mode on
your machine. The standalone mode runs all components of a Pulsar
[cluster](concepts-architecture-overview.md#clusters) inside a single Java
Virtual Machine (JVM) process.
:::tip
@@ -68,7 +68,7 @@ The following directories are created:
## Step 2: Start a Pulsar standalone cluster
-Run this command to start a standalone Pulsar cluster:
+Run this command to start a standalone Pulsar
[cluster](concepts-architecture-overview.md#clusters):
```bash
bin/pulsar standalone
@@ -78,7 +78,7 @@ When the Pulsar cluster starts, the following directories are
created:
| Directory | Description |
| --------- | ------------------------------------------ |
-| **data** | All data created by BookKeeper and RocksDB |
+| **data** | All data created by
[BookKeeper](concepts-architecture-overview.md#apache-bookkeeper) and RocksDB |
| **logs** | All server-side logs |
:::tip
@@ -90,7 +90,7 @@ When the Pulsar cluster starts, the following directories are
created:
## Step 3: Create a topic
-Pulsar stores messages in topics. It's a good practice to explicitly create
topics before using them, even if Pulsar can automatically create topics when
they are referenced.
+Pulsar stores messages in [topics](concepts-messaging.md#topics). It's a good
practice to explicitly create topics before using them, even if Pulsar can
automatically create topics when they are referenced.
To create a new topic, run this command:
@@ -100,7 +100,7 @@ bin/pulsar-admin topics create
persistent://public/default/my-topic
## Step 4: Write messages to the topic
-You can use the `pulsar` command line tool to write messages to a topic. This
is useful for experimentation, but in practice you'll use the Producer API in
your application code, or Pulsar IO connectors for pulling data in from other
systems to Pulsar.
+You can use the `pulsar` command line tool to write messages to a topic. This
is useful for experimentation, but in practice you'll use the
[Producer](concepts-clients.md#producer) API in your application code, or
[Pulsar IO](io-overview.md) connectors for pulling data in from other systems
to Pulsar.
Run this command to produce a message:
@@ -110,7 +110,7 @@ bin/pulsar-client produce my-topic --messages 'Hello
Pulsar!'
## Step 5: Read messages from the topic
-Now that some messages have been written to the topic, run this command to
launch the consumer and read those messages back:
+Now that some messages have been written to the topic, run this command to
launch the [consumer](concepts-clients.md#consumer) and read those messages
back:
```bash
bin/pulsar-client consume my-topic -s 'my-subscription' -p Earliest -n 0
@@ -118,7 +118,7 @@ bin/pulsar-client consume my-topic -s 'my-subscription' -p
Earliest -n 0
Earliest means consuming from the earliest **unconsumed** message. `-n`
configures the number of messages to consume, 0 means to consume forever.
-As before, this is useful for experimenting with messages, but in practice
you'll use the Consumer API in your application code, or Pulsar IO connectors
for reading data from Pulsar to push to other systems.
+As before, this is useful for experimenting with messages, but in practice
you'll use the [Consumer](concepts-clients.md#consumer) API in your application
code, or [Pulsar IO](io-overview.md) connectors for reading data from Pulsar to
push to other systems.
You'll see the messages you produce in the previous step:
diff --git a/versioned_docs/version-4.0.x/concepts-architecture-overview.md
b/versioned_docs/version-4.0.x/concepts-architecture-overview.md
index 44433e88746..c9c042ff6da 100644
--- a/versioned_docs/version-4.0.x/concepts-architecture-overview.md
+++ b/versioned_docs/version-4.0.x/concepts-architecture-overview.md
@@ -5,11 +5,11 @@ sidebar_label: "Architecture"
description: Get a comprehensive understanding of the architecture of Apache
Pulsar
---
-At the highest level, a Pulsar instance is composed of one or more Pulsar
clusters. Clusters within an instance can [replicate](concepts-replication.md)
data amongst themselves.
+At the highest level, a Pulsar instance is composed of one or more Pulsar
[clusters](#clusters). Clusters within an instance can
[replicate](concepts-replication.md) data amongst themselves.
A Pulsar cluster consists of the following components:
-* One or more brokers handles and [load
balances](administration-load-balance.md) incoming messages from producers,
dispatches messages to consumers, communicates with the Pulsar metadata store
to handle various coordination tasks, stores messages in BookKeeper instances
(aka bookies), and coordinates cluster operations through the metadata store.
+* One or more [brokers](#brokers) handles and [load
balances](administration-load-balance.md) incoming messages from
[producers](concepts-clients.md#producer), dispatches messages to
[consumers](concepts-clients.md#consumer), communicates with the Pulsar
[metadata store](#metadata-store) to handle various coordination tasks, stores
messages in [BookKeeper](#apache-bookkeeper) instances (aka bookies), and
coordinates cluster operations through the metadata store.
* A BookKeeper cluster consisting of one or more bookies handles [persistent
storage](#persistent-storage) of messages.
* A metadata store cluster (ZooKeeper, etcd, or other supported backend)
handles coordination tasks and cluster-specific metadata storage.
@@ -38,7 +38,7 @@ A Pulsar instance consists of one or more Pulsar *clusters*.
Clusters, in turn,
* One or more Pulsar [brokers](#brokers)
* A ZooKeeper quorum used for cluster-level configuration and coordination
-* An ensemble of bookies used for [persistent storage](#persistent-storage) of
messages
+* An ensemble of [bookies](#apache-bookkeeper) used for [persistent
storage](#persistent-storage) of messages
Clusters can replicate among themselves using
[geo-replication](concepts-replication.md).
@@ -46,7 +46,7 @@ Clusters can replicate among themselves using
[geo-replication](concepts-replica
## Metadata store
-The Pulsar metadata store maintains all the metadata of a Pulsar cluster, such
as topic metadata, schema, broker load data, and so on. Pulsar supports
multiple metadata store backends to provide flexibility in deployment
architectures and operational requirements:
+The Pulsar metadata store maintains all the metadata of a Pulsar cluster, such
as [topic](concepts-messaging.md#topics) metadata,
[schema](schema-overview.md), broker load data, and so on. Pulsar supports
multiple metadata store backends to provide flexibility in deployment
architectures and operational requirements:
### Supported Metadata Store Backends
@@ -79,24 +79,24 @@ The Pulsar metadata store can be deployed on a separate
cluster or integrated wi
In a Pulsar instance:
-* A configuration store quorum stores configuration for tenants, namespaces,
and other entities that need to be globally consistent.
-* Each cluster has its own local ZooKeeper ensemble that stores
cluster-specific configuration and coordination such as which brokers are
responsible for which topics as well as ownership metadata, broker load
reports, BookKeeper ledger metadata, and more.
+* A configuration store quorum stores configuration for
[tenants](concepts-multi-tenancy.md),
[namespaces](concepts-messaging.md#namespaces), and other entities that need to
be globally consistent.
+* Each cluster has its own local ZooKeeper ensemble that stores
cluster-specific configuration and coordination such as which brokers are
responsible for which [topics](concepts-messaging.md#topics) as well as
ownership metadata, broker load reports, BookKeeper ledger metadata, and more.
## Configuration store
-The configuration store is a ZooKeeper quorum that is used for
configuration-specific tasks and it maintains all the configurations of a
Pulsar instance, such as clusters, tenants, namespaces, partitioned
topic-related configurations, and so on. A Pulsar instance can have a single
local cluster, multiple local clusters, or multiple cross-region clusters.
Consequently, the configuration store can share the configurations across
multiple clusters under a Pulsar instance. The configuration [...]
+The configuration store is a ZooKeeper quorum that is used for
configuration-specific tasks and it maintains all the configurations of a
Pulsar instance, such as clusters, [tenants](concepts-multi-tenancy.md),
[namespaces](concepts-messaging.md#namespaces), partitioned topic-related
configurations, and so on. A Pulsar instance can have a single local cluster,
multiple local clusters, or multiple cross-region clusters. Consequently, the
configuration store can share the configurations acr [...]
## Persistent storage
-Pulsar provides guaranteed message delivery for applications. If a message
successfully reaches a Pulsar broker, it will be delivered to its intended
target.
+Pulsar provides guaranteed message delivery for applications. If a message
successfully reaches a Pulsar [broker](#brokers), it will be delivered to its
intended target.
-This guarantee requires that non-acknowledged messages are stored durably
until they can be delivered to and acknowledged by consumers. This mode of
messaging is commonly called *persistent messaging*. In Pulsar, N copies of all
messages are stored and synced on disk, for example, 4 copies across two
servers with mirrored [RAID](https://en.wikipedia.org/wiki/RAID) volumes on
each server.
+This guarantee requires that non-acknowledged messages are stored durably
until they can be delivered to and acknowledged by
[consumers](concepts-clients.md#consumer). This mode of messaging is commonly
called *persistent messaging*. In Pulsar, N copies of all messages are stored
and synced on disk, for example, 4 copies across two servers with mirrored
[RAID](https://en.wikipedia.org/wiki/RAID) volumes on each server.
### Apache BookKeeper
Pulsar uses a system called [Apache BookKeeper](http://bookkeeper.apache.org/)
for persistent message storage. BookKeeper is a distributed [write-ahead
log](https://en.wikipedia.org/wiki/Write-ahead_logging) (WAL) system that
provides several crucial advantages for Pulsar:
-* It enables Pulsar to utilize many independent logs, called
[ledgers](#ledgers). Multiple ledgers can be created for topics over time.
+* It enables Pulsar to utilize many independent logs, called
[ledgers](#ledgers). Multiple ledgers can be created for
[topics](concepts-messaging.md#topics) over time.
* It offers very efficient storage for sequential data that handles entry
replication.
* It guarantees read consistency of ledgers in the presence of various system
failures.
* It offers even distribution of I/O across bookies.
@@ -180,7 +180,7 @@ Some important things to know about the Pulsar proxy:
Service discovery is a mechanism that enables connecting
[clients](concepts-clients.md) to use just a single URL to interact with an
entire Pulsar instance.
-You can use your own service discovery system if you'd like. If you use your
own system, there is just one requirement: when a client performs an HTTP
request to an endpoint, such as `http://pulsar.us-west.example.com:8080`, the
client needs to be redirected to *some* active broker in the desired cluster,
whether via DNS, an HTTP or IP redirect, or some other means.
+You can use your own service discovery system if you'd like. If you use your
own system, there is just one requirement: when a client performs an HTTP
request to an endpoint, such as `http://pulsar.us-west.example.com:8080`, the
client needs to be redirected to *some* active [broker](#brokers) in the
desired cluster, whether via DNS, an HTTP or IP redirect, or some other means.
The diagram below illustrates Pulsar service discovery:
@@ -196,7 +196,7 @@ client = Client('pulsar://pulsar-cluster.acme.com:6650')
:::note
-In Pulsar, each topic is handled by only one broker. Initial requests from a
client to read, update or delete a topic are sent to a broker that may not be
the topic owner. If the broker cannot handle the request for this topic, it
redirects the request to the appropriate broker.
+In Pulsar, each [topic](concepts-messaging.md#topics) is handled by only one
[broker](#brokers). Initial requests from a client to read, update or delete a
topic are sent to a broker that may not be the topic owner. If the broker
cannot handle the request for this topic, it redirects the request to the
appropriate broker.
:::
diff --git a/versioned_docs/version-4.0.x/getting-started-docker.md
b/versioned_docs/version-4.0.x/getting-started-docker.md
index c885933090d..5baef82718b 100644
--- a/versioned_docs/version-4.0.x/getting-started-docker.md
+++ b/versioned_docs/version-4.0.x/getting-started-docker.md
@@ -140,7 +140,7 @@ After starting Pulsar successfully, you can see
`INFO`-level log messages like t
:::tip
* To perform a health check, you can use the `bin/pulsar-admin brokers
healthcheck` command. For more information, see [Pulsar admin
docs](/reference/#/@pulsar:version_reference@/pulsar-admin/).
-* When you start a local standalone cluster, a `public/default` namespace is
created automatically. The namespace is used for development purposes. All
Pulsar topics are managed within namespaces. For more information, see
[Topics](concepts-messaging.md#topics).
+* When you start a local standalone cluster, a `public/default`
[namespace](concepts-messaging.md#namespaces) is created automatically. The
namespace is used for development purposes. All Pulsar topics are managed
within namespaces. For more information, see
[Topics](concepts-messaging.md#topics).
:::
@@ -162,7 +162,7 @@ pip install pulsar-client
### Consume a message
-Create a consumer and subscribe to the topic:
+Create a [consumer](concepts-clients.md#consumer) and
[subscribe](concepts-messaging.md#subscriptions) to the
[topic](concepts-messaging.md#topics):
```python
import pulsar
@@ -180,7 +180,7 @@ client.close()
### Produce a message
-Start a producer to send some test messages:
+Start a [producer](concepts-clients.md#producer) to send some test messages:
```python
import pulsar
diff --git a/versioned_docs/version-4.0.x/getting-started-home.md
b/versioned_docs/version-4.0.x/getting-started-home.md
index 8cb765ab76a..b50b86c73de 100644
--- a/versioned_docs/version-4.0.x/getting-started-home.md
+++ b/versioned_docs/version-4.0.x/getting-started-home.md
@@ -8,5 +8,7 @@ Getting up and running with Pulsar is simple. Download it,
install it, and try i
You have three options. Click any of these links to begin your Pulsar journey!
* [Run a standalone Pulsar cluster locally](getting-started-standalone.md) -
Run a single instance of Pulsar in standalone mode on a single machine.
-* [Run a standalone Pulsar cluster in Docker](getting-started-docker.md) - Run
one or more instances of Pulsar in a Docker container. If you want to quickly
set up a small Pulsar cluster on your local laptop, go to [Run a Pulsar cluster
with Docker Compose](getting-started-docker-compose.md).
+* [Run a standalone Pulsar cluster in Docker](getting-started-docker.md) - Run
one or more instances of Pulsar in a Docker container. If you want to quickly
set up a small Pulsar [cluster](concepts-architecture-overview.md#clusters) on
your local laptop, go to [Run a Pulsar cluster with Docker
Compose](getting-started-docker-compose.md).
* [Run a standalone Pulsar cluster in Kubernetes](getting-started-helm.md) -
Run one or more instances of Pulsar in Kubernetes using a Helm chart.
+
+If you are new to Pulsar, you may also want to read the [Concepts and
Architecture](concepts-architecture-overview.md) guide and the
[Messaging](concepts-messaging.md) concepts (covering
[topics](concepts-messaging.md#topics),
[subscriptions](concepts-messaging.md#subscriptions),
[producers](concepts-clients.md#producer), and
[consumers](concepts-clients.md#consumer)) before diving in.
diff --git a/versioned_docs/version-4.0.x/getting-started-standalone.md
b/versioned_docs/version-4.0.x/getting-started-standalone.md
index c3a1db6b65e..66e29c89c51 100644
--- a/versioned_docs/version-4.0.x/getting-started-standalone.md
+++ b/versioned_docs/version-4.0.x/getting-started-standalone.md
@@ -5,7 +5,7 @@ sidebar_label: "Run Pulsar locally"
description: Get started with Apache Pulsar on your local machine.
---
-For local development and testing, you can run Pulsar in standalone mode on
your machine. The standalone mode runs all components inside a single Java
Virtual Machine (JVM) process.
+For local development and testing, you can run Pulsar in standalone mode on
your machine. The standalone mode runs all components of a Pulsar
[cluster](concepts-architecture-overview.md#clusters) inside a single Java
Virtual Machine (JVM) process.
:::tip
@@ -68,7 +68,7 @@ The following directories are created:
## Step 2: Start a Pulsar standalone cluster
-Run this command to start a standalone Pulsar cluster:
+Run this command to start a standalone Pulsar
[cluster](concepts-architecture-overview.md#clusters):
```bash
bin/pulsar standalone
@@ -78,7 +78,7 @@ When the Pulsar cluster starts, the following directories are
created:
| Directory | Description |
| --------- | ------------------------------------------ |
-| **data** | All data created by BookKeeper and RocksDB |
+| **data** | All data created by
[BookKeeper](concepts-architecture-overview.md#apache-bookkeeper) and RocksDB |
| **logs** | All server-side logs |
:::tip
@@ -90,7 +90,7 @@ When the Pulsar cluster starts, the following directories are
created:
## Step 3: Create a topic
-Pulsar stores messages in topics. It's a good practice to explicitly create
topics before using them, even if Pulsar can automatically create topics when
they are referenced.
+Pulsar stores messages in [topics](concepts-messaging.md#topics). It's a good
practice to explicitly create topics before using them, even if Pulsar can
automatically create topics when they are referenced.
To create a new topic, run this command:
@@ -100,7 +100,7 @@ bin/pulsar-admin topics create
persistent://public/default/my-topic
## Step 4: Write messages to the topic
-You can use the `pulsar` command line tool to write messages to a topic. This
is useful for experimentation, but in practice you'll use the Producer API in
your application code, or Pulsar IO connectors for pulling data in from other
systems to Pulsar.
+You can use the `pulsar` command line tool to write messages to a topic. This
is useful for experimentation, but in practice you'll use the
[Producer](concepts-clients.md#producer) API in your application code, or
[Pulsar IO](io-overview.md) connectors for pulling data in from other systems
to Pulsar.
Run this command to produce a message:
@@ -110,7 +110,7 @@ bin/pulsar-client produce my-topic --messages 'Hello
Pulsar!'
## Step 5: Read messages from the topic
-Now that some messages have been written to the topic, run this command to
launch the consumer and read those messages back:
+Now that some messages have been written to the topic, run this command to
launch the [consumer](concepts-clients.md#consumer) and read those messages
back:
```bash
bin/pulsar-client consume my-topic -s 'my-subscription' -p Earliest -n 0
@@ -118,7 +118,7 @@ bin/pulsar-client consume my-topic -s 'my-subscription' -p
Earliest -n 0
Earliest means consuming from the earliest **unconsumed** message. `-n`
configures the number of messages to consume, 0 means to consume forever.
-As before, this is useful for experimenting with messages, but in practice
you'll use the Consumer API in your application code, or Pulsar IO connectors
for reading data from Pulsar to push to other systems.
+As before, this is useful for experimenting with messages, but in practice
you'll use the [Consumer](concepts-clients.md#consumer) API in your application
code, or [Pulsar IO](io-overview.md) connectors for reading data from Pulsar to
push to other systems.
You'll see the messages you produce in the previous step:
diff --git a/versioned_docs/version-4.2.x/concepts-architecture-overview.md
b/versioned_docs/version-4.2.x/concepts-architecture-overview.md
index 44433e88746..c9c042ff6da 100644
--- a/versioned_docs/version-4.2.x/concepts-architecture-overview.md
+++ b/versioned_docs/version-4.2.x/concepts-architecture-overview.md
@@ -5,11 +5,11 @@ sidebar_label: "Architecture"
description: Get a comprehensive understanding of the architecture of Apache
Pulsar
---
-At the highest level, a Pulsar instance is composed of one or more Pulsar
clusters. Clusters within an instance can [replicate](concepts-replication.md)
data amongst themselves.
+At the highest level, a Pulsar instance is composed of one or more Pulsar
[clusters](#clusters). Clusters within an instance can
[replicate](concepts-replication.md) data amongst themselves.
A Pulsar cluster consists of the following components:
-* One or more brokers handles and [load
balances](administration-load-balance.md) incoming messages from producers,
dispatches messages to consumers, communicates with the Pulsar metadata store
to handle various coordination tasks, stores messages in BookKeeper instances
(aka bookies), and coordinates cluster operations through the metadata store.
+* One or more [brokers](#brokers) handles and [load
balances](administration-load-balance.md) incoming messages from
[producers](concepts-clients.md#producer), dispatches messages to
[consumers](concepts-clients.md#consumer), communicates with the Pulsar
[metadata store](#metadata-store) to handle various coordination tasks, stores
messages in [BookKeeper](#apache-bookkeeper) instances (aka bookies), and
coordinates cluster operations through the metadata store.
* A BookKeeper cluster consisting of one or more bookies handles [persistent
storage](#persistent-storage) of messages.
* A metadata store cluster (ZooKeeper, etcd, or other supported backend)
handles coordination tasks and cluster-specific metadata storage.
@@ -38,7 +38,7 @@ A Pulsar instance consists of one or more Pulsar *clusters*.
Clusters, in turn,
* One or more Pulsar [brokers](#brokers)
* A ZooKeeper quorum used for cluster-level configuration and coordination
-* An ensemble of bookies used for [persistent storage](#persistent-storage) of
messages
+* An ensemble of [bookies](#apache-bookkeeper) used for [persistent
storage](#persistent-storage) of messages
Clusters can replicate among themselves using
[geo-replication](concepts-replication.md).
@@ -46,7 +46,7 @@ Clusters can replicate among themselves using
[geo-replication](concepts-replica
## Metadata store
-The Pulsar metadata store maintains all the metadata of a Pulsar cluster, such
as topic metadata, schema, broker load data, and so on. Pulsar supports
multiple metadata store backends to provide flexibility in deployment
architectures and operational requirements:
+The Pulsar metadata store maintains all the metadata of a Pulsar cluster, such
as [topic](concepts-messaging.md#topics) metadata,
[schema](schema-overview.md), broker load data, and so on. Pulsar supports
multiple metadata store backends to provide flexibility in deployment
architectures and operational requirements:
### Supported Metadata Store Backends
@@ -79,24 +79,24 @@ The Pulsar metadata store can be deployed on a separate
cluster or integrated wi
In a Pulsar instance:
-* A configuration store quorum stores configuration for tenants, namespaces,
and other entities that need to be globally consistent.
-* Each cluster has its own local ZooKeeper ensemble that stores
cluster-specific configuration and coordination such as which brokers are
responsible for which topics as well as ownership metadata, broker load
reports, BookKeeper ledger metadata, and more.
+* A configuration store quorum stores configuration for
[tenants](concepts-multi-tenancy.md),
[namespaces](concepts-messaging.md#namespaces), and other entities that need to
be globally consistent.
+* Each cluster has its own local ZooKeeper ensemble that stores
cluster-specific configuration and coordination such as which brokers are
responsible for which [topics](concepts-messaging.md#topics) as well as
ownership metadata, broker load reports, BookKeeper ledger metadata, and more.
## Configuration store
-The configuration store is a ZooKeeper quorum that is used for
configuration-specific tasks and it maintains all the configurations of a
Pulsar instance, such as clusters, tenants, namespaces, partitioned
topic-related configurations, and so on. A Pulsar instance can have a single
local cluster, multiple local clusters, or multiple cross-region clusters.
Consequently, the configuration store can share the configurations across
multiple clusters under a Pulsar instance. The configuration [...]
+The configuration store is a ZooKeeper quorum that is used for
configuration-specific tasks and it maintains all the configurations of a
Pulsar instance, such as clusters, [tenants](concepts-multi-tenancy.md),
[namespaces](concepts-messaging.md#namespaces), partitioned topic-related
configurations, and so on. A Pulsar instance can have a single local cluster,
multiple local clusters, or multiple cross-region clusters. Consequently, the
configuration store can share the configurations acr [...]
## Persistent storage
-Pulsar provides guaranteed message delivery for applications. If a message
successfully reaches a Pulsar broker, it will be delivered to its intended
target.
+Pulsar provides guaranteed message delivery for applications. If a message
successfully reaches a Pulsar [broker](#brokers), it will be delivered to its
intended target.
-This guarantee requires that non-acknowledged messages are stored durably
until they can be delivered to and acknowledged by consumers. This mode of
messaging is commonly called *persistent messaging*. In Pulsar, N copies of all
messages are stored and synced on disk, for example, 4 copies across two
servers with mirrored [RAID](https://en.wikipedia.org/wiki/RAID) volumes on
each server.
+This guarantee requires that non-acknowledged messages are stored durably
until they can be delivered to and acknowledged by
[consumers](concepts-clients.md#consumer). This mode of messaging is commonly
called *persistent messaging*. In Pulsar, N copies of all messages are stored
and synced on disk, for example, 4 copies across two servers with mirrored
[RAID](https://en.wikipedia.org/wiki/RAID) volumes on each server.
### Apache BookKeeper
Pulsar uses a system called [Apache BookKeeper](http://bookkeeper.apache.org/)
for persistent message storage. BookKeeper is a distributed [write-ahead
log](https://en.wikipedia.org/wiki/Write-ahead_logging) (WAL) system that
provides several crucial advantages for Pulsar:
-* It enables Pulsar to utilize many independent logs, called
[ledgers](#ledgers). Multiple ledgers can be created for topics over time.
+* It enables Pulsar to utilize many independent logs, called
[ledgers](#ledgers). Multiple ledgers can be created for
[topics](concepts-messaging.md#topics) over time.
* It offers very efficient storage for sequential data that handles entry
replication.
* It guarantees read consistency of ledgers in the presence of various system
failures.
* It offers even distribution of I/O across bookies.
@@ -180,7 +180,7 @@ Some important things to know about the Pulsar proxy:
Service discovery is a mechanism that enables connecting
[clients](concepts-clients.md) to use just a single URL to interact with an
entire Pulsar instance.
-You can use your own service discovery system if you'd like. If you use your
own system, there is just one requirement: when a client performs an HTTP
request to an endpoint, such as `http://pulsar.us-west.example.com:8080`, the
client needs to be redirected to *some* active broker in the desired cluster,
whether via DNS, an HTTP or IP redirect, or some other means.
+You can use your own service discovery system if you'd like. If you use your
own system, there is just one requirement: when a client performs an HTTP
request to an endpoint, such as `http://pulsar.us-west.example.com:8080`, the
client needs to be redirected to *some* active [broker](#brokers) in the
desired cluster, whether via DNS, an HTTP or IP redirect, or some other means.
The diagram below illustrates Pulsar service discovery:
@@ -196,7 +196,7 @@ client = Client('pulsar://pulsar-cluster.acme.com:6650')
:::note
-In Pulsar, each topic is handled by only one broker. Initial requests from a
client to read, update or delete a topic are sent to a broker that may not be
the topic owner. If the broker cannot handle the request for this topic, it
redirects the request to the appropriate broker.
+In Pulsar, each [topic](concepts-messaging.md#topics) is handled by only one
[broker](#brokers). Initial requests from a client to read, update or delete a
topic are sent to a broker that may not be the topic owner. If the broker
cannot handle the request for this topic, it redirects the request to the
appropriate broker.
:::
diff --git a/versioned_docs/version-4.2.x/getting-started-docker.md
b/versioned_docs/version-4.2.x/getting-started-docker.md
index 708c2720aff..510c0b3d396 100644
--- a/versioned_docs/version-4.2.x/getting-started-docker.md
+++ b/versioned_docs/version-4.2.x/getting-started-docker.md
@@ -62,11 +62,11 @@ bin/pulsar standalone --advertised-address localhost
:::tip
-These examples set `--advertised-address localhost` to preserve the previous
local Docker behavior. A client can connect to `localhost:6650` on the host
machine, and the broker will also advertise `localhost` back to the client as
the address to use for subsequent connections.
+These examples set `--advertised-address localhost` to preserve the previous
local Docker behavior. A client can connect to `localhost:6650` on the host
machine, and the [broker](concepts-architecture-overview.md#brokers) will also
advertise `localhost` back to the client as the address to use for subsequent
connections.
If you omit this option, Pulsar uses the container's FQDN by default. That
works when the advertised hostname is resolvable and reachable from your
clients, such as from other containers on the same network or from remote
hosts, but it can break host-machine clients if that FQDN is not reachable from
outside the container.
-By default, Pulsar uses RocksDB as the metadata store, which is recommended
for standalone instances.
+By default, Pulsar uses RocksDB as the [metadata
store](concepts-architecture-overview.md#metadata-store), which is recommended
for standalone instances.
If you encounter issues with RocksDB or need compatibility with existing
ZooKeeper-based installations, you can use ZooKeeper as the metadata store by
adding:
@@ -144,7 +144,7 @@ After starting Pulsar successfully, you can see
`INFO`-level log messages like t
:::tip
* To perform a health check, you can use the `bin/pulsar-admin brokers
healthcheck` command. For more information, see [Pulsar admin
docs](/reference/#/@pulsar:version_reference@/pulsar-admin/).
-* When you start a local standalone cluster, a `public/default` namespace is
created automatically. The namespace is used for development purposes. All
Pulsar topics are managed within namespaces. For more information, see
[Topics](concepts-messaging.md#topics).
+* When you start a local standalone cluster, a `public/default`
[namespace](concepts-messaging.md#namespaces) is created automatically. The
namespace is used for development purposes. All Pulsar topics are managed
within namespaces. For more information, see
[Topics](concepts-messaging.md#topics).
:::
@@ -166,7 +166,7 @@ pip install pulsar-client
### Consume a message
-Create a consumer and subscribe to the topic:
+Create a [consumer](concepts-clients.md#consumer) and
[subscribe](concepts-messaging.md#subscriptions) to the
[topic](concepts-messaging.md#topics):
```python
import pulsar
@@ -184,7 +184,7 @@ client.close()
### Produce a message
-Start a producer to send some test messages:
+Start a [producer](concepts-clients.md#producer) to send some test messages:
```python
import pulsar
diff --git a/versioned_docs/version-4.2.x/getting-started-home.md
b/versioned_docs/version-4.2.x/getting-started-home.md
index 8cb765ab76a..b50b86c73de 100644
--- a/versioned_docs/version-4.2.x/getting-started-home.md
+++ b/versioned_docs/version-4.2.x/getting-started-home.md
@@ -8,5 +8,7 @@ Getting up and running with Pulsar is simple. Download it,
install it, and try i
You have three options. Click any of these links to begin your Pulsar journey!
* [Run a standalone Pulsar cluster locally](getting-started-standalone.md) -
Run a single instance of Pulsar in standalone mode on a single machine.
-* [Run a standalone Pulsar cluster in Docker](getting-started-docker.md) - Run
one or more instances of Pulsar in a Docker container. If you want to quickly
set up a small Pulsar cluster on your local laptop, go to [Run a Pulsar cluster
with Docker Compose](getting-started-docker-compose.md).
+* [Run a standalone Pulsar cluster in Docker](getting-started-docker.md) - Run
one or more instances of Pulsar in a Docker container. If you want to quickly
set up a small Pulsar [cluster](concepts-architecture-overview.md#clusters) on
your local laptop, go to [Run a Pulsar cluster with Docker
Compose](getting-started-docker-compose.md).
* [Run a standalone Pulsar cluster in Kubernetes](getting-started-helm.md) -
Run one or more instances of Pulsar in Kubernetes using a Helm chart.
+
+If you are new to Pulsar, you may also want to read the [Concepts and
Architecture](concepts-architecture-overview.md) guide and the
[Messaging](concepts-messaging.md) concepts (covering
[topics](concepts-messaging.md#topics),
[subscriptions](concepts-messaging.md#subscriptions),
[producers](concepts-clients.md#producer), and
[consumers](concepts-clients.md#consumer)) before diving in.
diff --git a/versioned_docs/version-4.2.x/getting-started-standalone.md
b/versioned_docs/version-4.2.x/getting-started-standalone.md
index c3a1db6b65e..66e29c89c51 100644
--- a/versioned_docs/version-4.2.x/getting-started-standalone.md
+++ b/versioned_docs/version-4.2.x/getting-started-standalone.md
@@ -5,7 +5,7 @@ sidebar_label: "Run Pulsar locally"
description: Get started with Apache Pulsar on your local machine.
---
-For local development and testing, you can run Pulsar in standalone mode on
your machine. The standalone mode runs all components inside a single Java
Virtual Machine (JVM) process.
+For local development and testing, you can run Pulsar in standalone mode on
your machine. The standalone mode runs all components of a Pulsar
[cluster](concepts-architecture-overview.md#clusters) inside a single Java
Virtual Machine (JVM) process.
:::tip
@@ -68,7 +68,7 @@ The following directories are created:
## Step 2: Start a Pulsar standalone cluster
-Run this command to start a standalone Pulsar cluster:
+Run this command to start a standalone Pulsar
[cluster](concepts-architecture-overview.md#clusters):
```bash
bin/pulsar standalone
@@ -78,7 +78,7 @@ When the Pulsar cluster starts, the following directories are
created:
| Directory | Description |
| --------- | ------------------------------------------ |
-| **data** | All data created by BookKeeper and RocksDB |
+| **data** | All data created by
[BookKeeper](concepts-architecture-overview.md#apache-bookkeeper) and RocksDB |
| **logs** | All server-side logs |
:::tip
@@ -90,7 +90,7 @@ When the Pulsar cluster starts, the following directories are
created:
## Step 3: Create a topic
-Pulsar stores messages in topics. It's a good practice to explicitly create
topics before using them, even if Pulsar can automatically create topics when
they are referenced.
+Pulsar stores messages in [topics](concepts-messaging.md#topics). It's a good
practice to explicitly create topics before using them, even if Pulsar can
automatically create topics when they are referenced.
To create a new topic, run this command:
@@ -100,7 +100,7 @@ bin/pulsar-admin topics create
persistent://public/default/my-topic
## Step 4: Write messages to the topic
-You can use the `pulsar` command line tool to write messages to a topic. This
is useful for experimentation, but in practice you'll use the Producer API in
your application code, or Pulsar IO connectors for pulling data in from other
systems to Pulsar.
+You can use the `pulsar` command line tool to write messages to a topic. This
is useful for experimentation, but in practice you'll use the
[Producer](concepts-clients.md#producer) API in your application code, or
[Pulsar IO](io-overview.md) connectors for pulling data in from other systems
to Pulsar.
Run this command to produce a message:
@@ -110,7 +110,7 @@ bin/pulsar-client produce my-topic --messages 'Hello
Pulsar!'
## Step 5: Read messages from the topic
-Now that some messages have been written to the topic, run this command to
launch the consumer and read those messages back:
+Now that some messages have been written to the topic, run this command to
launch the [consumer](concepts-clients.md#consumer) and read those messages
back:
```bash
bin/pulsar-client consume my-topic -s 'my-subscription' -p Earliest -n 0
@@ -118,7 +118,7 @@ bin/pulsar-client consume my-topic -s 'my-subscription' -p
Earliest -n 0
Earliest means consuming from the earliest **unconsumed** message. `-n`
configures the number of messages to consume, 0 means to consume forever.
-As before, this is useful for experimenting with messages, but in practice
you'll use the Consumer API in your application code, or Pulsar IO connectors
for reading data from Pulsar to push to other systems.
+As before, this is useful for experimenting with messages, but in practice
you'll use the [Consumer](concepts-clients.md#consumer) API in your application
code, or [Pulsar IO](io-overview.md) connectors for reading data from Pulsar to
push to other systems.
You'll see the messages you produce in the previous step:
