Here is a glossary of terms related to Apache Pulsar:
Pulsar is a distributed messaging system originally created by Yahoo but now under the stewardship of the Apache Software Foundation.
A topic that is served by multiple Pulsar brokers, which enables higher throughput.
A grouping mechanism for related topics.
An administrative unit for allocating capacity and enforcing an authentication/authorization scheme.
Pulsar readers are message processors much like Pulsar consumers but with two crucial differences:
- you can specify where on a topic readers begin processing messages (consumers always begin with the latest available unacked message);
- readers don't retain data or acknowledge messages.
The subscription position for a consumer.
A message sent to a Pulsar broker by a consumer that a message has been successfully processed. An acknowledgement (ack) is Pulsar's way of knowing that the message can be deleted from the system; if no acknowledgement, then the message will be retained until it's processed.
Negative Acknowledgment (nack)
When an application fails to process a particular message, it can send a "negative ack" to Pulsar to signal that the message should be replayed at a later timer. (By default, failed messages are replayed after a 1 minute delay). Be aware that negative acknowledgment on ordered subscription types, such as Exclusive, Failover and Key_Shared, can cause failed messages to arrive consumers out of the original order.
A message that has been delivered to a consumer for processing but not yet confirmed as processed by the consumer.
A lightweight Pulsar broker in which all components run in a single Java Virtual Machine (JVM) process. Standalone clusters can be run on a single machine and are useful for development purposes.
A group of Pulsar clusters that act together as a single unit.
Replication of messages across Pulsar clusters, potentially in different datacenters or geographical regions.
Pulsar's configuration store (previously known as configuration store) is a ZooKeeper quorum that is used for configuration-specific tasks. A multi-cluster Pulsar installation requires just one configuration store across all clusters.
A service provided by Pulsar brokers that enables connecting clients to automatically determine which Pulsar cluster is responsible for a topic (and thus where message traffic for the topic needs to be routed).
A stateless component of Pulsar clusters that runs two other components: an HTTP server exposing a REST interface for administration and topic lookup and a dispatcher that handles all message transfers. Pulsar clusters typically consist of multiple brokers.
An asynchronous TCP server used for all data transfers in-and-out a Pulsar broker. The Pulsar dispatcher uses a custom binary protocol for all communications.
Apache BookKeeper is a scalable, low-latency persistent log storage service that Pulsar uses to store data.
Bookie is the name of an individual BookKeeper server. It is effectively the storage server of Pulsar.
Pulsar Functions are lightweight functions that can consume messages from Pulsar topics, apply custom processing logic, and, if desired, publish results to topics.