Anonymitaet commented on code in PR #15809:
URL: https://github.com/apache/pulsar/pull/15809#discussion_r893165825


##########
site2/docs/architecture-overview.md:
##########
@@ -0,0 +1,143 @@
+---
+
+id: concepts-architecture-overview
+
+title: Architecture overview
+
+sidebar_label: Concepts
+
+---
+
+The following overview describes the components that make up a Pulsar cluster, 
from general to specific.  
+
+### Instance
+
+***
+
+A Pulsar instance is composed of one or more Pulsar clusters. Clusters within 
an instance can [replicate](concepts-replication.md) data amongst themselves.
+
+### Cluster
+
+***
+
+![Pulsar architecture diagram](/assets/pulsar-system-architecture.svg)
+
+In a Pulsar cluster:
+
+* One or more **brokers** handles and load balances incoming messages from 
**producers**, dispatches **messages** to **consumers**, communicates with the 
Pulsar **configuration store** to handle various coordination tasks, stores 
messages in BookKeeper instances (aka **bookies**), relies on a 
cluster-specific ZooKeeper cluster for certain tasks, and more.
+
+* A BookKeeper cluster consisting of one or more bookies handles [persistent 
storage](#persistent-storage) of messages.
+
+* A ZooKeeper cluster specific to that cluster handles coordination tasks 
between Pulsar clusters.
+
+An instance-wide ZooKeeper cluster called the Configuration Store handles 
coordination tasks involving multiple clusters, for example 
[geo-replication](concepts-replication.md).
+
+For a guide to managing Pulsar clusters, see the 
[clusters](admin-api-clusters.md) guide.
+
+### Producer
+
+***
+
+A producer is a process that attaches to a topic and publishes messages to a 
Pulsar [broker](reference-terminology.md#broker). The Pulsar broker processes 
the messages.
+
+Refer to the [producer](concepts-producer.md) topic for more information.
+
+### Topic
+
+***
+
+![Topic](/assets/producer-topic-consumer.svg)
+
+As in other pub-sub systems, topics in Pulsar are named channels for 
transmitting messages from producers to consumers. Topic names are URLs that 
have a well-defined structure:
+
+```http
+
+{persistent|non-persistent}://tenant/namespace/topic
+
+```
+
+| Topic name component | Description |
+|:--------------------|:-----------|
+| persistent / non-persistent | This identifies the type of topic. Pulsar 
supports two kind of topics: 
[persistent](concepts-architecture-overview.md#persistent-storage) and 
[non-persistent](#non-persistent-topics). The default is persistent, so if you 
do not specify a type, the topic is persistent. With persistent topics, all 
messages are durably persisted on disks (if the broker is not standalone, 
messages are durably persisted on multiple disks), whereas data for 
non-persistent topics is not persisted to storage disks.
+tenant             | The topic tenant within the instance. Tenants are 
essential to multi-tenancy in Pulsar, and spread across clusters.
+|`namespace`          | The administrative unit of the topic, which acts as a 
grouping mechanism for related topics. Most topic configuration is performed at 
the [namespace](#namespaces) level. Each tenant has one or multiple namespaces.
+|topic              | The final part of the name. Topic names have no special 
meaning in a Pulsar instance.
+
+![tenants](/assets/tenants.svg)
+
+Refer to [topic](concepts-topic.md) for more information.
+
+### Consumer
+
+***
+
+A consumer is a process that attaches to a topic via a subscription and then 
receives messages.
+
+A consumer sends a [flow permit 
request](developing-binary-protocol.md#flow-control) to a broker to get 
messages. There is a queue at the consumer side to receive messages pushed from 
the broker. You can configure the queue size with the 
[`receiverQueueSize`](client-libraries-java.md#configure-consumer) parameter. 
The default size is `1000`). Each time `consumer.receive()` is called, a 
message is dequeued from the buffer.  
+
+Refer to the [consumer](concepts-consumer.md) topic for more information.
+
+### Broker
+
+***
+
+The **Pulsar message broker** is a stateless component that's primarily 
responsible for running two other components:
+
+* An HTTP server that exposes an {@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.

Review Comment:
   is `{@inject: rest:REST:/} ` rendered correctly on your local preview?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to