Non-persistent messaging
- A basic conceptual overview of non-persistent topics
- A guide to the for managing non-persistent topics
By default, Pulsar persistently stores all unacknowledged messages on multiple BookKeeper bookies (storage nodes). Data for messages on persistent topics can thus survive broker restarts and subscriber failover.
Pulsar also, however, supports non-persistent topics, which are topics on which messages are never persisted to disk and live only in memory. When using non-persistent delivery, killing a Pulsar or disconnecting a subscriber to a topic means that all in-transit messages are lost on that (non-persistent) topic, meaning that clients may see message loss.
Non-persistent topics have names of this form (note the in the name):
In order to use non-persistent topics, you only need to differentiate them by name when interacting with them. This pulsar-client produce command, for example, would produce one message on a non-persistent topic in a standalone cluster:
$ bin/pulsar-client produce non-persistent://public/default/example-np-topic \
--messages "This message will be stored only in memory"
If you’d like to enable only non-persistent topics in a broker, you can set the parameter to and the enableNonPersistentTopics
parameter to true
.
Non-persistent topics can be managed using the pulsar-admin non-persistent command-line interface. With that interface you can perform actions like , get stats for a non-persistent topic, non-persistent topics under a namespace, and more.