Was ist Apache Pulsar?

Apache PULSAR ist eine cloudnative Open Source-Plattform für verteiltes Messaging und Streaming. Während Apache Kafka lange Zeit der Standard für Echtzeit-Event-Streaming und Datenverarbeitung war, hat sich Apache Pulsar im letzten Jahrzehnt als leistungsstarke Alternative herauskristallisiert.

Da Unternehmen mit immer komplexeren IT- und Datenumgebungen konfrontiert sind, verlassen sie sich auf Messaging- und Streaming-Plattformen, um für einen schnellen, zuverlässigen Datenaustausch zwischen Anwendungen, Systemen und Diensten zu sorgen. Da Datenanalysen in Echtzeit zu einer entscheidenden Triebkraft für verwertbare Erkenntnisse werden, hat die Beschleunigung der Geschwindigkeit des Datenstreamings und der Datenverarbeitung oberste Priorität. Laut IDC-Daten von 2025 geben die befragten Unternehmen an, dass 63 % der Anwendungsfälle Daten innerhalb von Minuten verarbeiten müssen, um nützlich zu sein.

Pulsar kombiniert die Funktionen traditioneller Messaging-Systeme mit denen von Publish/Subscribe-Systemen und eignet sich damit hervorragend für Anwendungsfälle wie Microservices, Instant Messaging und Datenintegration. Eine Vielzahl von Funktionen und Vorteilen ermöglichen die Vielseitigkeit von PULSAR®, einschließlich Geo-Replikation, Mehrmandantenfähigkeit und Tiered Storage.

Ursprünglich bei Yahoo entwickelt und 2016 von der Apache Software Foundation als Open-Source-Lösung zur Verfügung gestellt, verwaltet Apache Pulsar heute Hunderte von Milliarden Ereignissen pro Tag in großen Unternehmen.

Das Verständnis der Bedeutung von Apache Pulsar beginnt mit einer klaren Vorstellung von der Funktionsweise von Messaging- und Event-Streaming-Plattformen.

Eine Nachricht ist ein Datenpaket, das Anwendungen für andere Anwendungen erstellen. Diese Pakete werden in der Reihenfolge verwendet, in der sie übertragen werden, bis die konsumierende Anwendung sie verarbeitet.

Messaging-Systeme erleichtern den Austausch dieser Nachrichten. Herkömmliche Messagingsysteme sind Middleware-Lösungen (auch nachrichtenorientierte Middleware oder MOM genannt). Diese Lösungen unterstützen in der Regel zwei Nachrichtenverteilungsmuster: Point-to-Point-Messaging und Publish/Subscribe-Messaging.

Bei Punkt-zu-Punkt-Nachrichten sendet eine Anwendung (der sogenannte Absender) eine Nachricht an eine sogenannte Nachrichtenwarteschlange, in der die Nachricht gespeichert wird. Anschließend empfängt eine andere Anwendung (der Empfänger oder Konsument) die Nachricht aus der Warteschlange und verarbeitet sie. Jede Nachricht sollte nur einmal konsumiert werden.

Beim Publish/Subscribe-Messaging oder Pub/Sub-Messaging wird die Anwendung, die die Nachricht produziert, als Herausgeber bezeichnet. Die Anwendungen, die es verwenden, werden als Abonnenten bezeichnet. Jede Nachricht wird in einer Kategorie veröffentlicht, die als Thema bezeichnet wird, und jede Anwendung, die dieses Thema abonniert, erhält eine Kopie aller Nachrichten, die dort veröffentlicht werden.

Partitionen und partitionierte Themen können die Nachrichtenverarbeitung beschleunigen. Für partitionierte Themen veröffentlichte Nachrichten werden auf mehrere Broker verteilt.

Pub/Sub-Nachrichten sind für die Broadcast-ähnliche „One-to-Many“-Kommunikation konzipiert. Beim Punkt-zu-Punkt-Messaging werden – wie der Name schon sagt – Informationen zwischen einem einzelnen Absender und einem einzigen Empfänger ausgetauscht.

Unter den traditionellen Messaging-Systemen wird RabbitMQ, eine Open-Source-Plattform, oft als das beliebteste genannt.

Eine Event-Streaming-Plattform erfasst Echtzeitdaten von Anwendungen, Datenbanken und IoT-Geräten. Anschließend werden die Daten zur sofortigen Verarbeitung, Analyse oder Speicherung an verschiedene Ziele transportiert.

Event-Streaming-Plattformen, die für ihre Skalierbarkeit bekannt sind, können Datenströme in Themen ordnen und für einen bestimmten Zeitraum speichern. Im Gegensatz zu herkömmlichen Messaging-Systemen können Event-Streaming-Plattformen jedoch nicht garantieren, dass die Nachrichten zugestellt werden, und auch nicht nachverfolgen, welche Verbraucher die Nachrichten erhalten haben. Sie beruhen eher auf Pub/Sub-Nachrichten als auf einer Punkt-zu-Punkt-Nachrichtenverteilung und bieten weniger Flexibilität bei der Weiterleitung von Nachrichten.

Unter den Event-Streaming-Plattformen ist Apache Kafka die am häufigsten verwendete.

Apache Pulsar kombiniert die Funktionen von Plattformen wie RabbitMQ und Apache Kafka in einer einzigen Lösung. Es kann Ereignisse streamen und Nachrichten an mehrere Verbraucher wie Kafka übermitteln. es unterstützt Warteschlangen und kann Nachrichten an einzelne Verbraucher wie RabbitMQ senden.

Aber Pulsar ist mehr als nur die Summe seiner Vorgänger. Yahoo entwickelte die Plattform zunächst für die eigenen Bedürfnisse, sodass von Anfang an bestimmte Wettbewerbsvorteile eingebaut wurden. In den darauffolgenden Jahren haben weitere Verbesserungen Pulsar zu einer leistungsstarken Messaging- und Streaming-Plattform gemacht.

Zu den überzeugendsten Funktionen von Apache Pulsar gehören heute:

• Mandantenfähigkeit
• Georeplikation
• Mehrschichtige Architektur
• Mehrschichtiger Speicher
• E/A-Anschlüsse
• Flexible Abonnements

Die Mandantenfähigkeit war eine der ursprünglichen Funktionen, die Apache Pulsar von anderen Plattformen unterschied. In einer mandantenfähigen Softwarearchitektur bedient eine einzelne Instanz einer Softwareanwendung (und der ihr zugrunde liegenden Datenbank und Hardware) mehrere Mandanten (oder Benutzerkonten). Zu den Vorteilen der Mandantenfähigkeit gehören eine vereinfachte Systemeinrichtung, Konfiguration, Wartung und Anwendungs-Bereitstellung sowie Kosteneinsparungen.

In Apache Pulsar können verschiedene Teams das Nachrichtensystem sicher teilen. Jeder Tenant verfügt über eigene Authentifizierung, Autorisierungen und Richtlinien. Tenants können weiter in sogenannte Namespaces (logische Gruppierungen von Themen) unterteilt werden. Diese Aufteilung erleichtert die Unterstützung verschiedener Umgebungen – wie Entwicklung, Staging und Produktion – innerhalb eines Single-Tenant.

Das Replizieren von Nachrichten an Remotestandorte ist wichtig, um die Notfallwiederherstellung zu unterstützen oder den Betrieb von Anwendungen auf globaler Ebene zu ermöglichen. Im Gegensatz zu anderen Plattformen erfordert Pulsar keine komplexen Konfigurationen oder Add-Ons, um diese Funktion zu ermöglichen.

Mit der Geo-Replikation können sich Anwendungen mit dem lokalen Pulsar-Cluster verbinden und trotzdem an Cluster auf der ganzen Welt senden. Wenn ein Produzent eine Nachricht zu einem Topic in einem replizierten Namespace veröffentlicht, wird diese Nachricht automatisch an den konfigurierten Remote-Standort oder die konfigurierten Remote-Standorte repliziert.

Die Pulsar-Architektur trennt Nachrichtenübermittlungskomponenten (Nachrichtenbroker) und Nachrichtenspeicherschichten. Die Nachrichten werden von Apache BookKeeper gespeichert, einem bekannten Marktführer für permanente Protokollspeicherlösungen.

Um die Leistung zu steigern, verteilt BookKeeper die Daten auf mehrere Server, die so genannten Bookies. (Metadaten für BookKeeper-Ledger werden in Apache ZooKeeper gespeichert.) Bookies können bei Bedarf hinzugefügt werden, was zu einer horizontalen Skalierbarkeit führt, die sich für die Verarbeitung großer Datenmengen eignet. Diese Architektur ermöglicht es Pulsar eine geringe Latenz zu bieten und gleichzeitig große Datenmengen in kurzer Zeit zu übertragen – was als hoher Durchsatz bekannt ist.

Die Architektur von PULSAR® wird auch als cloudnative Architektur betrachtet. Sowohl PULSAR als auch Cloud Computing trennen Rechenleistung von Speicher. Darüber hinaus kann Pulsar auf Kubernetes bereitgestellt werden, einer Open-Source-Plattform für die Container-Orchestrierung, die ein Baustein einer modernen Cloud-Infrastruktur ist.

Apache Pulsar bietet auch mehrstufigen Speicher. Diese Funktion ermöglicht es, ältere Backlog-Daten von Apache BookKeeper in eine kostengünstigere, langfristige Speicherung zu verschieben, während Pulsar-Kunden weiterhin auf das Backlog zugreifen können.

Pulsar Tiered Storage nutzt Apache jclouds (ein Open Source Toolkit für die Java Plattform), um langfristige Speicher durch Lösungen wie AWS S3 (Amazon S3), GCS (Google Cloud Speicher), Azure und Aliyun zu unterstützen.

Apache Pulsar kann dank Pulsar IO-Konnektoren problemlos mit externen Systemen verwendet werden. Diese Konnektoren dienen als Brücken zwischen Pulsar und anderen Systemen, wie Stream-Processing-Engines, Datenpipeline-APIs und anderen Messaging-Plattformen.

Pulsar-Anschlüsse gibt es in zwei Ausführungen: Quelle und Senke. Quellkonnektoren übertragen Daten von externen Systemen an Pulsar, während Senkkonnektoren das Gegenteil tun und Daten von Pulsar an externe Systeme übertragen. Zu den häufig verwendeten Pulsar-Konnektoren gehören MySQL, MongoDB, Cassandra, RabbitMQ, Kafka, Flume und Redis.

Apache Pulsar unterstützt vier verschiedene Abonnementtypen¹, um Benutzern bei der Konfiguration von Nachrichtenmustern zu helfen:

• Exclusive: Nur ein Verbraucher darf Nachrichten über das Abonnement empfangen.
  
  
• Failover: Wenn die Nachrichtenübertragung an einen bestimmten primären Consumer fehlschlägt, werden Nachrichten zur Verarbeitung an einen Standby-Verbraucher gesendet.
  
  
• Shared: Nachrichten werden in einem „Round-Robin“-Verfahren zugestellt, wobei mehrere Verbraucher Nachrichten erhalten, aber jede Nachricht an einen Verbraucher zugestellt wird.
  
  
• Key shares: Nachrichten werden einem Nachrichtenschlüssel zugewiesen, der hilft, zusammengehörige Nachrichten zuzuordnen. Nachrichten mit demselben Schlüssel werden in einer bestimmten Reihenfolge an Verbraucher gesendet.

Weitere bemerkenswerte Pulsar-Funktionen sind:

Broker-Lastverteilung: Pulsar überwacht die CPU-, Speicher- und Netzwerknutzung der Pulsar-Broker und verschiebt Workload nach Bedarf, um das Gleichgewicht zu optimieren und eine Überlastung einzelner Broker zu vermeiden.

Schema-Registrierung: Die Schema-Registrierung von Pulsar ermöglicht es Pulsar-Kunden, Datenschemata pro Thema hochzuladen, um sicherzustellen, dass Hersteller und Verbraucher kompatible Nachrichtenformate verwenden.

Clientbibliotheken: Clientbibliotheken sind vorkonfigurierte Funktionen und Verfahren, die die Interaktion zwischen Anwendungen und APIs, Datenbanken und Diensten vereinfachen. Pulsar unterstützt programmiersprachenspezifische Bibliotheken (einschließlich Bibliotheken für Java, C++, Python und Node.js) und sprachunabhängige Bibliotheken (REST und WebSocket).

Aufbewahrung von Nachrichten: Herkömmliche Systeme löschen Nachrichten, sobald sie konsumiert wurden. Pulsar ermöglicht es Benutzern, Aufbewahrungsrichtlinien festzulegen, um Nachrichten auch nach deren Konsum zu speichern – eine Funktion, die ereignisgesteuerte Architekturmodelle unterstützen kann.

Die folgenden Anwendungsfall der Apache Software Foundation veranschaulichen die Dienstprogramm und die Vielseitigkeit von Pulsar.²