Hallo! Ich bin kürzlich auf eine ziemlich interessante Beschreibung der Architektur von Pusher Channels gestoßen und habe beschlossen, sie für Sie zu übersetzen. Meiner Meinung nach hat der Autor Ansätze zum Aufbau einer hoch geladenen und skalierbaren Architektur sehr leicht beschrieben. Der Artikel wird höchstwahrscheinlich sowohl für Anfänger als auch für Spezialisten aus verwandten Bereichen nützlich sein.
Im Pusher-Büro haben wir einen kleinen Schalter mit einer ständig wachsenden Anzahl. Es zeigt die Anzahl der zugestellten Nachrichten für die gesamte Existenz von Pusher-Kanälen. Am Freitag um 22:20 UTC stieg die Zahl um eine Kategorie und erreichte 10.000.000.000.000. Es hat 13 Nullen - 10 Billionen.
Sie könnten denken, dass die Gesamtzahl der Nachrichten eine nutzlose, aufgedunsene Metrik ist. Diese Zahl ist jedoch ein Schlüsselindikator für den Erfolg von Pusher Channels, unserem Echtzeit-Kommunikationsprodukt. Erstens spiegelt dieser Zähler das Vertrauen wider, das uns die Benutzer entgegenbringen. Zweitens misst es die Skalierbarkeit unseres Systems. Um die Anzahl zu erhöhen, müssen wir bei Pusher sicherstellen, dass Benutzer dem Senden von Nachrichten an unseren Dienst vertrauen, und wir müssen sicherstellen, dass unser System diese Nachrichten verarbeiten kann. Aber was sollen wir 10 Billionen Nachrichten übermitteln? Mal sehen.
Über Pusher-Kanäle werden pro Sekunde etwa 200.000 Nachrichten gesendet, zu Spitzenzeiten Millionen. Zum Beispiel, als die New York Times den Dienst nutzte, um ihre Leser über den Fortschritt der US-Präsidentschaftswahlen auf dem Laufenden zu halten.
Betrachten wir Pusher Channels zunächst als eine große Black Box, durch die all diese Nachrichten gehen:
Pusher Channels ist ein Publish-Subscribe-System. Clients abonnieren Kanäle (z. B. "btc-usd" oder "private-user-jim"), während andere Clients Nachrichten an sie senden. Wenn eine Million Menschen den Kanal „btc-usd“ abonniert haben und jemand die tatsächlichen Kosten für Bitcoin dorthin sendet, müssen Pusher Channels eine Million Nachrichten übermitteln. Wir machen das in wenigen Millisekunden.
Ein Server kann nicht so viele Nachrichten in so kurzer Zeit übermitteln. Daher verwenden wir drei bewährte Techniken: Fan-Out, Sharding und Load Balancing. Mal sehen, was in der Black Box ist.
Millionen von Abonnenten sind auf ungefähr 170 leistungsstarke Edgeserver verteilt, von denen jeder ungefähr 20.000 Verbindungen enthält. Jeder dieser Server merkt sich die Liste der Kanäle, die für seine Kunden interessant sind, und abonniert sie im zentralen Redis-Dienst . Selbst wenn 2000 Clients an „btc-usd“ auf dem Edgeserver interessiert sind, muss er es nur einmal abonnieren. Wenn also eine neue Nachricht im Kanal eintrifft, sendet Redis 170 Nachrichten an Edgeserver, die bereits 20.000 Nachrichten an ihre Abonnenten senden. Dieser Ansatz wird als Fan-Out bezeichnet.
Aber nur Fan-Out reicht uns nicht, denn es gibt immer noch eine zentrale Redis-Komponente, über die alle, die Nachrichten senden, gehen. Diese Zentralisierung begrenzt die Anzahl der pro Sekunde gesendeten Nachrichten. Um diese Einschränkung zu umgehen, besteht der zentrale Redis-Dienst aus vielen Redis-Shards. Jeder Kanal wird wiederum durch Hashing seines Namens an den Redis-Shard angehängt. Wenn der Kunde eine Nachricht senden möchte, geht er zum Restdienst. Letzterer hasht den Kanalnamen und bestimmt anhand des Ergebnisses den erforderlichen Redis-Shard, an den die Nachricht gesendet werden soll. Dieser Ansatz wird als Sharding bezeichnet.
Es hört sich so an, als würden wir die Zentralisierung nur von einem Redis-Dienst auf einen Ruhedienst verlagern. Dies ist jedoch nicht der Fall, da der Rest-Service selbst aus etwa 90 Servern besteht, die dieselbe Arbeit ausführen: Sie empfangen Veröffentlichungsanforderungen, berechnen Redis-Shards und senden Nachrichten an sie. Wenn ein Publisher eine Nachricht senden möchte, geht er zu einem der vielen Rest-Server. Dieser Ansatz wird als Lastausgleich bezeichnet.
Zusammen bilden Fan-Out, Sharding und Load Balancing eine zentrale Komponente des Systems. Diese Eigenschaft ist der Schlüssel zum Erreichen einer horizontalen Skalierbarkeit, mit der Millionen von Nachrichten pro Sekunde gesendet werden können.
Wir haben die zentralen Komponenten des Pusher Channels-Dienstes untersucht, aber es gibt auch andere Teile, wie z. B. Metriken (wie erhalten wir diese Zahl von 10 Billionen), Webhooks (wie informieren wir Kunden über interessante Ereignisse), Autorisierung (Einschränkung des Zugriffs auf Kanäle), Daten zu Aktiv Benutzer, Ratenbegrenzung (wie stellen wir sicher, dass unsere Kunden genau so viele Ressourcen verwenden, wie sie bezahlt haben, und dass sie andere Kunden nicht stören). All diese zusätzlichen Funktionen sollten implementiert werden, ohne die Bandbreite, die Nachrichtenübermittlungszeit und die Verfügbarkeit unseres gesamten Dienstes zu beeinträchtigen.