Entwerfen Sie ein skalierbares Echtzeit-Benachrichtigungssystem

Entwurf: Skalierbares Echtzeit-Benachrichtigungssystem 1. GESAMTARCHITEKTUR Das System besteht aus mehreren unterschiedlichen Schichten, die zusammenarbeiten, um Ereignisse aufzunehmen, sie weiterzuleiten und sie mit minimaler Latenz an verbundene Clients zu pushen. Client-Schicht: Mobile und Web-Clients unterhalten persistente WebSocket-Verbindungen zu einer Flotte von Connection Gateway-Servern. Jeder Client authentifiziert sich beim Verbindungsaufbau und registriert seine Benutzer-ID beim Gateway. API-Gateway / Load Balancer: Ein Layer-7-Load-Balancer (z. B. AWS ALB oder NGINX) sitzt vor den Connection Gateways. Er leitet neue WebSocket-Upgrade-Anfragen mithilfe von konsistentem Hashing auf der Benutzer-ID weiter, sodass Wiederverbindungen tendenziell auf demselben Gateway-Knoten landen, was den Zustandswechsel reduziert. Er stellt auch einen REST-Endpunkt für interne Dienste zur Veröffentlichung von Ereignissen bereit. Ereignisveröffentlichungsdienst: Interne Plattformdienste (wie Service-, Kommentar- oder Freundschaftsdienst) veröffentlichen Ereignisse in einem zentralen Nachrichtenbroker. Sie rufen eine dünne Publishing-API auf, die die Nutzlast validiert, sie mit Metadaten (Zeitstempel, Benachrichtigungs-ID) anreichert und in den Broker schreibt. Nachrichtenbroker (Kafka): Ereignisse werden in Kafka-Topics geschrieben, die nach Benutzer-ID partitioniert sind. Dies gewährleistet eine geordnete Zustellung pro Benutzer und ermöglicht die horizontale Skalierung von Konsumenten. Kafkas dauerhafter Log bietet auch die Wiederholungsfähigkeit, die für mindestens einmalige Zustellungsgarantien erforderlich ist. Notification Fanout Service: Ein Pool von zustandslosen Consumer-Workern liest von Kafka. Für jedes Ereignis ruft der Worker die Abonnementpräferenzen des Zielbenutzers in einem schnellen Cache (Redis) ab, ermittelt, welche Benutzer die Benachrichtigung erhalten sollen, und leitet die Nachricht dann an das richtige Connection Gateway weiter. Bei Ereignissen mit hoher Reichweite (z. B. ein Beitrag eines Prominenten) wird ein separater asynchroner Fanout-Job ausgelöst, um den Hot Path nicht zu blockieren. Connection Gateway (WebSocket-Server): Dies sind zustandsbehaftete Server, die die offenen WebSocket-Verbindungen unterhalten. Jedes Gateway speichert eine In-Memory-Map von Benutzer-ID zu Verbindungs-Handle. Wenn eine weitergeleitete Benachrichtigung eintrifft (über einen internen Pub/Sub-Kanal wie Redis Pub/Sub oder einen direkten gRPC-Aufruf), pusht das Gateway sie über die entsprechende WebSocket-Verbindung. Wenn der Benutzer nicht verbunden ist, verwirft das Gateway den Push und verlässt sich für die spätere Zustellung auf die Persistenzschicht. Presence & Routing Service: Ein Redis-Cluster speichert eine Zuordnung von Benutzer-ID zu Gateway-Knoten-ID mit einer kurzen TTL, die durch Heartbeats aktualisiert wird. Der Fanout Service fragt dies ab, um zu wissen, an welches Gateway eine Benachrichtigung weitergeleitet werden soll. Wenn kein Eintrag vorhanden ist, ist der Benutzer offline. Benachrichtigungsspeicher (Cassandra): Alle generierten Benachrichtigungen werden in Cassandra gespeichert, indiziert nach Benutzer-ID und sortiert nach Zeitstempel. Dies dient zwei Zwecken: Es versorgt die Benachrichtigungs-Inbox-UI mit Daten (Benutzer können frühere Benachrichtigungen durchscrollen) und ermöglicht die mindestens einmalige Zustellung – wenn ein Benutzer online kommt, ruft der Client ungelesene Benachrichtigungen aus diesem Speicher ab. Zustellungsbestätigung: Clients senden nach Erhalt einer Benachrichtigung eine ACK-Nachricht über das WebSocket. Das Gateway schreibt dieses ACK in Kafka, und ein Consumer markiert die Benachrichtigung in Cassandra als zugestellt. Nicht bestätigte Benachrichtigungen, die älter als ein Schwellenwert sind, werden zur erneuten Zustellung in die Warteschlange gestellt. 2. TECHNOLOGIENAUSWAHL UND BEGRÜNDUNG WebSockets über Long Polling oder SSE: WebSockets bieten Full-Duplex-Verbindungen mit geringem Overhead und geringer Latenz. Long Polling verschwendet Serverressourcen durch wiederholte HTTP-Handshakes und erhöht die Latenz. Server-Sent Events (SSE) sind unidirektional und weniger geeignet für den ACK-Fluss. Bei 1 Million gleichzeitigen Verbindungen sind WebSockets die ressourceneffizienteste Wahl. Jede Verbindung verbraucht etwa 10–50 KB Speicher, sodass 1 Million Verbindungen über eine mittelgroße Gateway-Flotte realisierbar sind. Kafka über RabbitMQ: Kafka wird wegen seines hohen Durchsatzes (Millionen von Nachrichten pro Sekunde), seiner dauerhaften Log-Speicherung, seiner Consumer-Gruppen-Semantik und der Möglichkeit, Nachrichten erneut abzuspielen, gewählt. RabbitMQ ist ein guter Broker für Task-Queues, aber sein Nachrichtenmodell ist weniger geeignet für die hier benötigten Fanout- und Replay-Muster. Kafkas Partitionierung nach Benutzer-ID parallelisiert auch den Konsum auf natürliche Weise. Bei 10.000 Benachrichtigungen pro Sekunde bewältigt Kafka dies mit erheblichem Spielraum. Redis für Präsenz und Pub/Sub: Redis bietet Sub-Millisekunden-Lesevorgänge für die Präsenzabfrage (Benutzer-ID → Gateway-Knoten). Redis Pub/Sub oder Redis Streams können für den internen Kanal zwischen dem Fanout Service und den Connection Gateways verwendet werden und fügen dem Zustellpfad minimale Latenz hinzu. Cassandra über MySQL/PostgreSQL: Der Benachrichtigungsverlauf ist eine schreibintensive Zeitreihen-Workload mit hoher Kardinalität (eine Partition pro Benutzer). Cassandras Wide-Column-Modell, seine abstimmbare Konsistenz und seine lineare horizontale Skalierbarkeit machen es ideal. Eine relationale Datenbank würde eine komplexe Sharding-Strategie erfordern und mit dem Schreibdurchsatz kämpfen. Cassandras eventual consistency ist hier akzeptabel, da der Benachrichtigungsverlauf kein transaktionaler Datensatz ist. Zustandslose Fanout-Worker: Die Beibehaltung der Zustandslose der Fanout-Worker ermöglicht deren horizontale Skalierung durch einfaches Hinzufügen weiterer Kafka-Consumer-Instanzen innerhalb der Consumer-Gruppe. 3. WIE DAS DESIGN JEDE ANFORDERUNG ERFÜLLT Skalierbarkeit (1 Mio. gleichzeitige Benutzer, 10.000 Benachrichtigungen/Sekunde): Die Connection Gateways sind horizontal skalierbar. Ein einzelner moderner Server kann 50.000–100.000 WebSocket-Verbindungen verwalten, sodass 10–20 Gateway-Knoten 1 Million Benutzer bedienen. Der Load Balancer verteilt neue Verbindungen. Kafka-Partitionen skalieren die Fanout-Worker. Cassandra skaliert Schreibvorgänge linear mit der Anzahl der Knoten. Redis Cluster shardet die Präsenzdaten. Keine einzelne Komponente ist ein Engpass. Latenz (P99 < 200 ms): Der kritische Pfad ist: Ereignis veröffentlicht → Kafka-Schreibvorgang (~5 ms) → Fanout-Worker verbraucht und ruft Präsenz in Redis ab (~5 ms) → leitet über Redis Pub/Sub oder gRPC an Gateway weiter (~5 ms) → Gateway pusht über WebSocket (~10 ms Netzwerk). Die Gesamtlatenz liegt im Medianfall weit unter 50 ms. Das P99-Budget von 200 ms berücksichtigt die Kafka-Consumer-Verzögerung unter Spitzenlast und Netzwerk-Jitter. Die einfache Logik des Fanout-Workers und die zwischengespeicherten Redis-Abfragen stellen sicher, dass der Hot Path schnell bleibt. Zuverlässigkeit (mindestens einmalige Zustellung): Benachrichtigungen werden vor oder gleichzeitig mit dem Push-Versuch in Cassandra gespeichert. Wenn der WebSocket-Push fehlschlägt oder der Client nicht ACKt, bleibt die Benachrichtigung in Cassandra im ungelesenen Zustand. Beim Wiederverbinden ruft der Client ungelesene Benachrichtigungen ab. Das Commit des Kafka-Consumer-Offsets erfolgt erst, nachdem der Fanout-Worker die Nachricht erfolgreich weitergeleitet hat, sodass kein Ereignis stillschweigend verloren geht. Dies gewährleistet eine Ende-zu-Ende-Semantik für mindestens einmalige Zustellung. Verfügbarkeit (99,95 % Uptime): Alle Komponenten werden in mehreren Verfügbarkeitszonen bereitgestellt. Der Load Balancer, die Kafka-Broker, die Redis-Cluster-Knoten, die Cassandra-Knoten und die Fanout-Worker laufen alle mit N+1- oder N+2-Redundanz. Ausfälle von Gateway-Knoten führen dazu, dass sich Clients wieder verbinden (WebSocket-Wiederverbindungslogik mit exponentiellem Backoff) und innerhalb von Sekunden auf einem gesunden Knoten landen. Die Replikationsfaktor von 3 bei Kafka stellt sicher, dass Broker-Ausfälle keinen Datenverlust verursachen. Cassandras Replikationsfaktor von 3 mit Quorum-Lese-/Schreibvorgängen toleriert Knotenausfälle. Diese Architektur erreicht problemlos eine Uptime von 99,95 %. 4. KOMPROMISSE Komplexität vs. Einfachheit: Dieses Design hat viele bewegliche Teile – Kafka, Redis, Cassandra, WebSocket-Gateways, Fanout-Worker, Präsenzdienst. Dies ist erheblich komplexer zu betreiben als ein einfaches Polling-System oder eine einzelne Broker-Einrichtung. Der Kompromiss ist durch die Skalierungsanforderungen gerechtfertigt, erfordert jedoch eine ausgereifte DevOps-Praxis, gute Beobachtbarkeit (verteilte Tracing, Metriken pro Komponente) und Bereitschaftsdienst-Expertise. Mindestens einmal vs. Genau einmal: Eine genau einmalige Zustellung würde verteilte Transaktionen über Kafka, Cassandra und das Gateway erfordern, was die Latenz und Komplexität erheblich erhöht. Stattdessen wird mindestens einmal gewählt, was bedeutet, dass ein Benutzer gelegentlich eine doppelte Benachrichtigung sehen könnte. Dies wird auf Client-Seite durch Deduplizierung anhand der Benachrichtigungs-ID gehandhabt. Für eine Social-Media-Benachrichtigung (ein Like oder Kommentar) ist eine Duplikat eine geringfügige UX-Beeinträchtigung, kein kritischer Fehler – ein akzeptabler Kompromiss. Zustandsbehaftete Gateways: Die WebSocket-Gateways sind zustandsbehaftet (sie halten Live-Verbindungen). Dies macht Rollout-Deployments und die Wiederherstellung nach Fehlern etwas komplexer als bei einem vollständig zustandslosen Dienst. Clients müssen eine Wiederverbindungslogik implementieren. Der Kompromiss besteht darin, dass zustandsbehaftete Gateways für Echtzeit-Pushs notwendig sind; es gibt keine Möglichkeit, einen Client ohne eine persistente Verbindung zu pushen. Fanout zur Lese- vs. Schreibzeit: Dieses Design fächert zur Schreibzeit auf (der Fanout-Worker pusht sofort an das Gateway jedes Empfängers). Für Benutzer mit Millionen von Followern schafft dies ein Hot-Path-Problem (ein Beitrag eines Prominenten löst Millionen von Fanout-Operationen aus). Die Abhilfe besteht darin, eine separate High-Fanout-Job-Warteschlange für Konten mit einer Follower-Schwelle zu verwenden und diese asynchron zu verarbeiten. Der Kompromiss besteht darin, dass Benutzer mit vielen Followern möglicherweise eine etwas höhere Benachrichtigungs-Latenz erfahren, was im Allgemeinen akzeptabel ist. Redis Pub/Sub-Zuverlässigkeit: Redis Pub/Sub speichert keine Nachrichten. Wenn ein Gateway kurzzeitig von Redis getrennt ist, wenn eine Nachricht veröffentlicht wird, verpasst es diese Nachricht. Dies wird durch die Cassandra-Persistenzschicht gemildert – der Client ruft die Benachrichtigung beim Wiederverbinden ab –, bedeutet aber, dass der Echtzeit-Push best-effort ist, wobei der persistente Speicher als Sicherheitsnetz dient. Die Verwendung von Redis Streams anstelle von Pub/Sub würde Persistenz auf Kosten einer etwas höheren Komplexität hinzufügen. Kosten: Der Betrieb von Kafka, Redis Cluster, Cassandra und einer großen WebSocket-Gateway-Flotte ist teuer. Eine kleinere Plattform könnte einen verwalteten Dienst wie AWS SNS/SQS oder Firebase Cloud Messaging nutzen, um den Betriebsaufwand zu reduzieren. Bei der beschriebenen Skalierung (1 Million gleichzeitige Benutzer) rechtfertigt die Kontrolle und Leistung eines benutzerdefinierten Stacks die Kosten.

Zusammenfassung auf hoher Ebene Ich schlage eine horizontal skalierbare Echtzeit-Benachrichtigungsplattform mit geringer Latenz vor, die aufgebaut ist auf: (1) Edge-/Gateway-Infrastruktur zur Annahme von Ereignissen und Client-Verbindungen, (2) ein dauerhaftes Pub/Sub-Backbone für das Routing von Ereignissen an interessierte Abonnenten, (3) Verbindungsmanager / WebSocket-Worker, die Live-Client-Verbindungen aufrechterhalten und Fan-out durchführen, (4) ein schneller Präsenzspeicher und ein dauerhafter Benachrichtigungsspeicher für Zuverlässigkeit und Offline-Zustellung. Das System verwendet Partitionierung und Replikation, um Durchsatz- und Verfügbarkeitsziele zu erreichen, mit End-to-End-Instrumentierung, Backpressure und Idempotenz, um eine mindestens einmalige Zustellung und geringe Latenz zu gewährleisten. 1) Gesamtarchitektur (Komponenten und Anfragefluss) Kernkomponenten - API-Gateway / Ingress: Nimmt Ereignisveröffentlichungen (von internen Diensten) und Client-Verbindungs-Upgrades entgegen. Stellt REST/gRPC-Endpunkte für Ereignisveröffentlicher bereit und behandelt Authentifizierung und Ratenbegrenzung. Bereitgestellt hinter globalen LBs und regionalen Endpunkten. - Verbindungsschicht (WebSocket / GRPC-Streams): Eine Flotte zustandsloser Verbindungsserver (WebSocket/HTTP2 oder gRPC), die persistente Verbindungen zu Clients aufrechterhalten. Sie führen leichtgewichtiges Routing und Bestätigungsverarbeitung durch und leiten Abonnementänderungen an den Präsenzspeicher weiter. - Präsenz- & Routing-Speicher: Ein Low-Latency-Schlüssel-Wert-Speicher (Redis-Cluster), der verfolgt, welcher Verbindungsserver welche Online-Benutzer gerade hostet und welche Themen sie abonnieren. Wird verwendet, um Benachrichtigungen an den richtigen Verbindungsarbeiter weiterzuleiten. - Pub/Sub-Backbone: Ein dauerhafter, partitionierter Nachrichtenbus (Kafka oder Apache Pulsar) zur Verteilung von Ereignissen von Veröffentlichen an Benachrichtigungsarbeiter. Themen sind nach logischen Schlüsseln (Benutzer-ID, Themen-ID) partitioniert, um eine geordnete Verarbeitung pro Schlüssel und skalierbaren Durchsatz zu gewährleisten. - Benachrichtigungsdienst / Worker-Pool: Konsumenten des Pub/Sub-Themas, die Anreicherung, Filterung und Zustellungsrouting durchführen. Worker fragen den Präsenzspeicher ab, um Zielverbindungsserver zu finden, und pushen Zustellungsaufgaben in schnelle Zustellungswege. - Zustellungsschicht / Fan-out-Engine: Die Verbindungsserver empfangen Zustellungsanfragen (direkt oder über schnelles RPC) und pushen Benachrichtigungen über die persistente Verbindung an den Client. Sie behandeln Flow Control pro Verbindung, Batching und ACKs von Clients. - Dauerhafter Benachrichtigungsspeicher (NoSQL): Ein schreiboptimierter, replizierter Speicher (z. B. Cassandra / DynamoDB) zum Speichern von Benachrichtigungen für Offline-Benutzer, Wiederholungsversuche und Audits. Speichert Benachrichtigungsnutzlasten, Zustellungsversuche, Zeitstempel, TTLs. - Deduplizierungs- & Idempotenzspeicher: Kleiner Schlüssel-Wert-Speicher (Redis oder RocksDB) zum Aufzeichnen kürzlicher Nachrichten-IDs zur Deduplizierung, wenn mindestens einmalige Semantiken Duplikate verursachen. - Überwachungs- & Steuerungsebene: Metriken, Tracing, SLO/Alarmierung, Circuit Breaker und Drosselung. Typische Abläufe - Veröffentlichungsablauf (Ereignisproduzent -> Benutzer): 1) Der Veröffentlicher sendet ein Ereignis an das API-Gateway (REST/gRPC). 2) Das Gateway schreibt die Nachricht in das Pub/Sub-Thema (partitioniert nach Zielthema/Benutzer-ID). 3) Benachrichtigungsarbeiter verbrauchen Ereignisse, reichern sie an und lösen Abonnementlisten auf (oder fragen die Abonnementdatenbank ab), konsultieren den Präsenzspeicher, um Online-Empfänger zu finden, und pushen für jeden Online-Empfänger an die entsprechenden Verbindungsserver. 4) Verbindungsserver pushen über WebSocket/gRPC-Stream an den Client und warten auf eine leichte ACK. 5) Wenn der Benutzer offline ist (Präsenzverlust), wird in den dauerhaften Benachrichtigungsspeicher für den Offline-Abruf geschrieben. - Abonnementablauf: Clients senden Abonnement-/Abbestellnachrichten über ihre persistente Verbindung. Der Verbindungsserver aktualisiert den Präsenzspeicher atomar, sodass der Worker-Routing schnell aktualisierte Abonnements sieht. - Wiederherstellung & Wiedergabe: Dauerhafter Pub/Sub und Benachrichtigungsspeicher ermöglichen die Wiedergabe verpasster Ereignisse; Verbindungsserver registrieren die Präsenz bei der Wiederverbindung neu. 2) Technologieauswahl und Begründung - Client-Verbindung: WebSockets oder HTTP/2 (gRPC) Streams - Wahl: WebSockets für breite Client-Kompatibilität (Mobil/Web). Erwägen Sie HTTP/2 gRPC-Streams für interne/mobile Apps, die dies unterstützen. Beide halten persistente TCP/TLS-Verbindungen aufrecht, um eine Latenz von <200 ms zu erreichen. - Grund: Polling ist zu langsam und ineffizient. Long Polling erhöht die Latenz und den Ressourcenverbrauch. WebSockets bieten Push, niedrige RTT und die Möglichkeit, Binärnachrichten mit geringem Overhead zu liefern. - Pub/Sub-Backbone: Apache Kafka oder Apache Pulsar - Wahl: Kafka (verwaltet wie Confluent Cloud oder selbst gehostet) oder Pulsar, wenn Multi-Tenancy und Geo-Replikationsanforderungen dominieren. - Grund: Beide bieten partitionierte, dauerhafte Nachrichten mit hohem Durchsatz. Kafka verfügt über ausgereifte Tools, starken Durchsatz, vorhersagbare Latenz und Unterstützung für Exactly-Once-Semantik in Produzenten. Die Partitionierung ermöglicht eine einfache Skalierung auf 10.000 Nachrichten/s. Pulsar bietet integrierte Geo-Replikation, falls Multi-Region erforderlich ist. - Präsenzspeicher & Routing: Redis Cluster (im Speicher) mit Replikation - Grund: Lese-/Schreibvorgänge unter 1 ms, um Benutzer -> Verbindungsserver, Abonnements und Verbindungsmetadaten zuzuordnen. Redis unterstützt Clustering, Persistenz (AOF/RDB) und schnelle Lookups, die erforderlich sind, um Ereignisse innerhalb des 200-ms-Budgets zu routen. - Persistenter Benachrichtigungsspeicher: Cassandra / DynamoDB (NoSQL) - Wahl: Cassandra oder DynamoDB-ähnlicher Schlüssel-Wert-Speicher. - Grund: Hoher Schreibdurchsatz, lineare Skalierbarkeit und konfigurierbare TTLs, ideal für die Speicherung vieler Schreibvorgänge pro Sekunde und die Bedienung von Offline-Lesevorgängen. SQL-Systeme haben Schwierigkeiten bei dieser Schreibskala und der Komplexität der horizontalen Sharding. - Verbindungsserver & Worker-Kommunikation: gRPC/internes RPC + protobuf - Grund: Binäre Nachrichten mit geringem Overhead, Backpressure-Unterstützung, starke Typisierung und hohe Leistung. - Load Balancing & Routing: L4 (TCP) Load Balancer für WebSockets + L7 LB für REST-APIs. Verwenden Sie Sticky Routing über Consistent Hashing oder Session Affinity, um Wiederverbindungen an dieselbe Region zu leiten. - Client-Nutzlastformat: Kompakte Binärdaten (protobuf/flatbuffers) für kleinere Nutzlasten und schnellere Serialisierung. 3) Wie das Design nicht-funktionale Anforderungen erfüllt - Skalierbarkeit (1 Mio. gleichzeitige Benutzer, 10.000 Benachrichtigungen/s Spitzenlast) - Zustandlose Verbindungsserver: Horizontale Skalierung; jeder Server verarbeitet N gleichzeitige WebSocket-Verbindungen. Mit modernen Maschinen (z. B. 100.000 Sockets pro Maschine mit richtiger Abstimmung) können einige Dutzend/Hunderte von Servern 1 Mio. gleichzeitige Sockets verarbeiten. Autoscaling-Gruppen + Container-Orchestrierung verwalten die Kapazität. - Partitionierter Pub/Sub (Kafka): Skalieren Sie Produzenten und Konsumenten durch Hinzufügen von Partitionen/Workern. Die Partitionierung nach Benutzer-ID oder Thema stellt eine gleichmäßige Lastverteilung sicher. 10.000 Nachrichten/s sind für entsprechend dimensionierte Kafka-Cluster (Dutzende von Brokern) bescheiden. - Sharded Präsenzspeicher: Redis Cluster sharded den Benutzerraum, sodass Lookups O(1) bleiben und skalieren. - Partitionierter dauerhafter Speicher: Cassandra skaliert linear durch Hinzufügen von Knoten für Schreib- und Lesevorgänge. - Latenz (99 % innerhalb von 200 ms) - Persistente Verbindungen eliminieren den Overhead des TCP-Handshakes. Nach der Einrichtung ist der Push von der Ereignisveröffentlichung zum Client: API-Gateway -> Kafka-Anhängung (sub-ms-10s ms je nach Abstimmung) -> Worker-Verbrauch -> Präsenz-Lookup (sub-ms) -> RPC zum Verbindungsserver -> Push über WebSocket (sub-ms bis wenige ms). Mit sorgfältiger Platzierung (Worker und Verbindungsserver in derselben Region/AZ bereitstellen) bleibt die Netzwerklatenz gering. Verwenden Sie Batching, das auf nahezu sofortige Zustellung abgestimmt ist (vermeiden Sie Batching-Verzögerungen), und stimmen Sie die Kafka-Konsumentenkonfiguration (niedrige linger.ms) ab, um die End-to-End-Latenz niedrig zu halten. - Edge/regionale Bereitstellung: Platzieren Sie Verbindungsserver in Kundennähe (Regionsebene), damit die Last-Mile-Latenz minimiert wird. - Verwenden Sie Binärserialisierung und kleine Nutzlasten, um Serialisierungs-/Netzwerkzeit zu reduzieren. - Zuverlässigkeit (mindestens einmalige Zustellung) - Dauerhafte Schreibvorgänge: Veröffentlicher schreiben Ereignisse nach Kafka (dauerhaft), Worker verfolgen Offsets; Nachrichten bleiben dauerhaft, bis sie vom Konsumenten verarbeitet und bestätigt wurden. - Mindestens einmal: Wenn die Zustellung fehlschlägt (Absturz des Verbindungsservers, Netzwerk), kann der Worker neu einreihen oder wiederholen, da der Pub/Sub Nachrichten behält und der Worker Offsets nur nach erfolgreicher Einreihung/Bestätigung committet. Clients bestätigen den Empfang, aber ACKs bestätigen nur die Annahme durch den Client; serverseitige Persistenz ermöglicht Wiederholungsversuche. - Deduplizierung: Da mindestens einmalige Zustellung Duplikate erzeugen kann, fügen Sie eindeutige Nachrichten-IDs und clientseitige Deduplizierung oder serverseitige Deduplizierung mit Caches für kürzliche IDs hinzu, um Duplikate zu unterdrücken. - Dauerhafter Benachrichtigungsspeicher: Wenn der Benutzer offline ist oder eine dauerhafte Bestätigung erforderlich ist, schreiben Sie die Benachrichtigung in Cassandra, bevor Sie das Ereignis bestätigen, damit sie später zugestellt werden kann. - Verfügbarkeit (99,95 % Uptime) - Multi-AZ- und Multi-Region-Bereitstellung: Kritische Komponenten replizieren. Verwenden Sie Kafka mit Replikationsfaktor >2, Redis mit Master-Replica und Failover, Cassandra mit mehreren Replikaten und abstimmbarer Konsistenz. - Zustandlose Frontends & Autoscaling: Wenn ein Verbindungsserver ausfällt, verbinden sich Clients mit dem nächsten verfügbaren Server neu. Verwenden Sie Health Checks und schnelles Failover. - Graceful Degradation: Wenn die Zustellungsüberlastung auftritt, nehmen Sie Ereignisse entgegen und speichern Sie sie zur späteren Zustellung, anstatt sie fallen zu lassen. Drosselung und Backpressure schützen das System. - Beobachtbarkeit & Automatisierung: Automatisches Neustarten, Circuit Breaker und Runbooks für den Betreiber-Eingriff. SLOs und Alarmierung sind auf 99,95 % Verfügbarkeit abgestimmt. 4) Betriebliche Details und Optimierungen - Partitionierungsschlüssel & Routing: Partitionieren Sie Pub/Sub nach Benutzer-ID für benutzerspezifische Nachrichten und nach Themen-ID für Themen-Broadcasts. Für Fanouts an viele Benutzer (z. B. ein Beitrag, der von Tausenden geliked wurde) führen Sie einen hierarchischen Fanout durch: 1) Empfänger ermitteln; 2) Empfänger nach Verbindungsserver gruppieren; 3) gruppierte Zustellungsnachricht an jeden Verbindungsserver senden, um NRPC-Aufrufe zu vermeiden. - Fan-out-Strategien - Fan-out beim Schreiben (Push): Bevorzugt für Echtzeit-Online-Zustellung – Worker pushen nur an Online-Verbindungen, die über den Präsenzspeicher gefunden wurden. - Fan-out beim Lesen (Pull): Verwenden Sie dies für große Offline-Fanouts oder für Benutzer, die selten online sind; Benachrichtigung speichern und vom Client abrufen lassen, wenn er online ist. - Batching und Coalescing: Für ähnliche Ereignisse mit hohem Volumen mehrere Ereignisse zu einer kompakten Benachrichtigung zusammenfassen (z. B. „3 Personen haben Ihren Beitrag geliked“), um die Last zu reduzieren und die Benutzererfahrung zu verbessern. - Backpressure und Glättung: Wenn Verbindungsserver oder Clients keine Nachrichten empfangen können, wenden Sie Backpressure an: Konsumenten verlangsamen, in den dauerhaften Speicher puffern und wiederholen. Implementieren Sie Ratenbegrenzungen pro Client. - Client-ACK-Modell: Verwenden Sie eine leichte ACK für erfolgreichen Empfang. Wenn die ACK nicht innerhalb des Timeouts empfangen wird, wiederholen Sie die Zustellung. Behalten Sie Zähler für Zustellungsversuche bei und senden Sie sie nach N Versuchen an den Dead-Letter-Store. - Sicherheit und Datenschutz: End-to-End-Authentifizierung am Gateway, Überprüfung der Berechtigung des Veröffentlichen zum Veröffentlichen; Transport verschlüsseln (TLS) und Nutzlasten bereinigen. 5) Kompromisse und Diskussion - Komplexität vs. Einfachheit - Kompromiss: Ein Kafka-basiertes Multi-Komponenten-System ist betrieblich komplexer als ein einfacher Push-Server, aber für Skalierung und Zuverlässigkeit notwendig. Die Betriebskosten und die technische Komplexität steigen (Verwaltung von Kafka, Redis-Cluster, Cassandra), bieten aber Dauerhaftigkeit, Wiedergabe und Fanout-Kontrolle. - Mindestens einmal vs. Genau einmal - Wahl: Mindestens einmalige Zustellung mit Deduplizierung wird gewählt. End-to-End-Genau-einmal ist sehr teuer (Koordination über Dienste und Clients hinweg) und oft unnötig für Benachrichtigungen, bei denen Duplikate tolerierbar sind. Deduplizierungs-Caches und clientseitige Idempotenz bieten praktische Abhilfen. - WebSockets vs. HTTP/2 gRPC - Kompromiss: WebSockets maximieren die Kompatibilität, erfordern aber mehr LB- und Verbindungs-Tuning. gRPC bietet bessere Flusskontrolle und Typsicherheit für Clients, die es unterstützen. Die Unterstützung beider erhöht die Komplexität, bietet aber die beste Abdeckung. - Echtzeit-Push vs. Speichern zuerst - Push zuerst wird für Online-Benutzer bevorzugt, um die Latenz zu erfüllen. Das Speichern zuerst (erst in der Datenbank speichern) erhöht jedoch die Schreiblatenz bei gleichzeitiger Erhöhung der Dauerhaftigkeit. Wir schlagen eine Balance vor: Schnell nach Kafka (dauerhaft) schreiben, optional in Cassandra speichern, abhängig von der Zuverlässigkeitsrichtlinie. - Redis-Präsenz-Eventualkonsistenz - Die Präsenz kann in Randfällen leicht veraltet sein; ein kleines Fenster von falschen Negativen/Positiven könnte eine einzelne verpasste Benachrichtigung verursachen, die aus dem dauerhaften Benachrichtigungsspeicher wiederhergestellt wird. Dieses Design bevorzugt Low-Latency-Präsenz-Lookups gegenüber streng synchronen globalen Präsenz-Werten. 6) Kapazitätsplanung & Zahlen (Grobe Schätzung) - 1 Mio. gleichzeitige Benutzer: Wenn jeder Verbindungsserver ~10.000 gleichzeitige WebSockets verarbeitet, werden ~100 Verbindungsserver benötigt. Sicherheitsfaktor (2x) für Spitzen hinzufügen -> ~200 Instanzen über Regionen hinweg. - 10.000 Benachrichtigungen/s: Kafka-Cluster mit 10–50 Partitionen ist ausreichend, abhängig von der Nachrichtengröße und Replikation; Ziel-Broker-Anzahl ca. 5–10 mit Replikationsfaktor 3. Konsumentengruppen skalieren horizontal. - Speicher: Bei 10.000 Benachrichtigungen/s, ~864 Mio. Benachrichtigungen pro Tag (wenn jede Nachricht gespeichert wird) – TTLs und Aggregation verwenden, um den Speicher zu reduzieren. Cassandra-Knoten entsprechend dimensionieren. 7) Fehlerfälle und Abhilfemaßnahmen - Absturz des Verbindungsservers: Clients verbinden sich mit anderen Servern neu; Präsenzspeicher wird bei Wiederverbindung aktualisiert. Gepufferte Nachrichten im Worker werden wiederholt. Verwenden Sie Sticky-Wiederverbindungsstrategien, um Zustandswechsel zu reduzieren. - Kafka-Broker-Ausfall: Partitionsreplikation stellt sicher, dass keine Daten verloren gehen, wenn der Replikationsfaktor >=3 und ISR konfiguriert ist. Überwachen Sie unter-replizierte Partitionen. - Redis-Failover: Verwenden Sie Redis Cluster mit Replikaten und automatisiertem Failover (Sentinel oder verwaltete Dienste). Präsenz nach einem großen Failover aus den Verbindungsservern neu aufbauen. - Große Fanouts (virale Ereignisse): Verwenden Sie hierarchischen Fanout und Batching; lagern Sie an Hintergrund-Worker aus und speichern Sie Benachrichtigungen zur späteren Zustellung, wenn die Echtzeit-Zustellung die Latenz überschreiten würde. Schlussfolgerung Dieses Design verwendet persistente Verbindungen (WebSockets/gRPC), ein dauerhaftes partitioniertes Pub/Sub (Kafka/Pulsar), einen Low-Latency-Präsenzspeicher (Redis) und einen skalierbaren NoSQL-Speicher (Cassandra/DynamoDB), um die Ziele von 1 Mio. gleichzeitigen Verbindungen, 10.000 Benachrichtigungen/s, <200 ms 99 % Latenz, mindestens einmalige Zuverlässigkeit und 99,95 % Verfügbarkeit zu erfüllen. Die Hauptkompromisse sind erhöhte betriebliche Komplexität und die Handhabung von Duplikaten. Mit sorgfältiger Partitionierung, Replikation, Überwachung und Abstimmung der einzelnen Komponenten (Konsumentenkonfigurationen, Batching, Backpressure) wird diese Architektur skalieren und die Low-Latency-Echtzeit-Benachrichtigungen liefern, die die Plattform benötigt.