Inhaltsverzeechnes[Verstoppen][Show]
WhatsApp ass e soziale Messagerie Programm deen d'Benotzer erlaabt Messagen mateneen auszetauschen.
Hutt Dir jeemools geduecht wéi WhatsApp funktionnéiert?
Wat sinn d'Konzepter déi seng Kreatioun an Operatioun ënnersträichen?
Dësen Artikel wäert iwwer d'Grondlage vu WhatsApp goen System Design.
Mir wäerten och duerch WhatsApp d'allgemeng Architektur goen, déi benotzt kënne fir all Zort Chat Software ze bauen.
Also, ouni weider Ado, loosst eis de Systemdesign vu WhatsApp kucken!
1. Schlëssel Ufuerderunge
WhatsApp ass eng héich skalierbar Technologie déi vu ville Leit op der ganzer Welt benotzt gëtt. Als Resultat sollt et gutt entworf sinn fir praktesch ëmmer zouverlässeg a funktionnéierend ze sinn.
Als Resultat ass d'Bestëmmung vun de kritesche Bedierfnesser vum System kritesch.
Dëst sinn d'Mindestfuerderunge fir de WhatsApp Messenger:
- Kapabel fir een-op-een Interaktiounen ze erliichteren.
- Message Unerkennung a lescht gesinn sinn souwuel méiglech (geschéckt, geliwwert, a gelies).
- Erlaabt end-to-end Verschlësselung a Medien Ënnerstëtzung (Biller / Videoen).
Loosst eis erausfannen wéi vill Kapazitéit eisen néidege Service erfuerdert.
2. Schätzung Kapazitéit
Eist Zil ass et eng Plattform ze kreéieren déi fäeg ass eng grouss Quantitéit vum Traffic ze handhaben. Ugeholl datt 10 Milliarden SMS pro Dag geschéckt ginn. Mir hunn:
- All Dag ginn 10 Milliarden SMS vun enger Milliard Leit geschéckt.
- Beim Spëtzeverkéier (pro Sekonn) ware 700,000 Leit aktiv (6X Moyenne)
- Wärend der Spëtzeverbrauch gi 40 Millioune Messagen pro Sekonn iwwerdroen.
- D'Duerchschnëttslängt vun engem Message ass 160 Zeechen: 10B * 160 = 1.6TB vun Daten gëtt all Dag generéiert.
- Huelt zéng Joer Service als Beispill: 10 * 1.6B * 365 PB
- Déi ganz Applikatioun besteet aus Mikroservicer, déi all eng spezialiséiert Aufgab ausféieren. Gitt un datt d'Schécken vun engem Message 20 Millisekonnen dauert an datt et 100 gläichzäiteg Verbindunge pro Server sinn. Als Resultat ass déi erwaart Zuel vun Chat-Server néideg = (Chat Messagen pro Sekonn Latency) / concurrent Verbindungen pro Server = 40M * 20ms / 100 = 8000 Serveren.
3. Héich-Niveau Architektur
Dëse System ass op zwee Kär Servicer gebaut. Chat Service an Iwwergangsservice, zum Beispill. Den Chat Service handhabt all de Traffic deen duerch d'Online Messagen vun de Benotzer generéiert gëtt. Gläichzäiteg geréiert den temporäre Service de Traffic wann de Benotzer offline ass.
Wann de Benotzer online ass, ass de Chat Service zoustänneg fir Messagen ze liwweren.
Et gëtt iwwerpréift ob den Empfänger vum Message online ass oder net; wann den Empfänger online ass, liwwert dëse Service de Message direkt; wann den Empfänger net online ass, schéckt den Iwwergangsservice de Message un hinnen wann se online zréckkommen.
Den Iwwergangsdéngscht hält e getrennte Späichergebitt fir temporär zougänglech Donnéeën ze halen bis den offline Benotzer sech nei verbënnt.
Design High-Level APIs
Dëse Service huet zwee héich-Niveau funktionéierend APIen fir Messagen ze schécken an ze liesen. De System kann mat der REST Architektur implementéiert ginn.
Parameteren fir Messagen ze schécken
Dës API gëtt benotzt fir Messagen tëscht zwee Benotzer ze vermëttelen.
Parameteren vun Gespréich
Dës API gëtt benotzt fir threaded Chats ze weisen. Betruecht dëst dat éischt wat Dir gesitt wann Dir WhatsApp opmaacht. Mir wëllen nëmmen e puer Messagen fir ee Benotzer an enger eenzeger API Ufro kréien. Fir dëst ze handhaben, sinn d'Offset- a Messagezuelparameter gebraucht.
Wat sinn d'Funktioune vun Features wéi lescht gesinn, Single Tick, an Double Tick?
Déi wichteg Roll am Asaz vun dëse Servicer ass den Unerkennungsservice. Dës Fonctiounen goufen entwéckelt well dëse Service weider d'UnerkennungsÄntwerten generéiert an z'iwwerpréiwen.
- Eenzel Tick: Wann e Message vum Benotzer A de Benotzer B erreecht, schéckt de Server en eenzegen Tick fir unzeerkennen datt de Message iwwerdroe gouf.
- Duebel Tick: Nodeems de Message vum Server un de Benotzer B duerch déi richteg Verbindung geschéckt gouf, wäert de Benotzer B d'Empfang vun der Noriicht un de Server unerkennen. De Server gëtt dann de Benotzer A eng aner Unerkennung. Als Resultat erschéngt en Duplikat Tick.
- Blo Tick: De Benotzer B schéckt eng aner Unerkennung un de Server nodeems de Message iwwerpréift gouf. De Server schéckt dann de Benotzer A eng zousätzlech Unerkennungsmeldung. E bloe Kräiz erschéngt duerno um Benotzer A sengem Écran.
- Lescht gesinn: Den Häerzschlagmechanismus ass ganz verantwortlech fir déi lescht gesinn Feature. All 5 Sekonnen gëtt en Häerzschlag op de Server iwwerdroen, deen de leschte Status vun all Benotzer verfollegt an enger Tabell déi einfach vun all anere Benotzer zougänglech ass.
4. Design Schlëssel Fonctiounen
Personaliséiert Interaktioun
Dëst ass en noutwendegen Deel vum Chat Service. E Benotzer kann einfach Messagen un en anere Benotzer mat dësem Service schécken. Loosst eis kucken wéi dëst funktionnéiert:
Unzehuelen Jay wëll mat Aayush ze kommunizéieren. De Jay ass mat engem Chat-Server verbonne mat deem hien de Message kritt. Jay kritt Bestätegung vum Chat-Server datt de Message geschéckt gouf. Den Chat-Server freet elo Informatioun vum Dategeschäft iwwer den Chat-Server mat deem Aayush verbonnen ass. Dem Jay säin Chatserver iwwerdréit elo de Message un den Aayush säin Chatserver, an den Aayush kritt de Message iwwer e Pushmechanismus. Aayush schéckt elo eng Unerkennung un dem Jay säin Chatserver, deen dem Jay informéiert datt de Message geliwwert gouf. Wann Aayush de Message nach eng Kéier gelies huet, gouf eng frësch Unerkennung datt de Message gelies gouf dem Jay geliwwert.
Status vun Benotzer Aktivitéit
Déi leschte Kéier wou eng Persoun aktiv war ass eng regulär Feature vun Instant Messenger.
E System fir eng Verbindung tëscht dem Client an dem Server z'erhalen ass an dësem Diagramm duergestallt. Web Sockets goufen benotzt fir eng bidirektional Verbindung tëscht dem Server an dem Client opzebauen. Dës Verbindunge schécken Häerzschlag, déi benotzt gi fir den Aktivitéitsstatus vum Benotzer ze iwwerwaachen.
End-to-End Privatsphär
End-to-End Verschlësselung ass eng Schlëssel Feature déi garantéiert datt nëmmen déi konverséierend Benotzer d'Kommunikatioune liesen. En ëffentleche Schlëssel gëtt tëscht all de Benotzer involvéiert an der Kommunikatioun gedeelt an ass kritesch fir End-to-End Verschlësselung z'erhalen. Gitt un datt et zwee Benotzer um Kanal sinn, Jay, an Aayush, déi matenee kommunizéieren.
De Jay huet dem Aayush säin ëffentleche Schlëssel, an den Aayush huet dem Jay säin ëffentleche Schlëssel souwéi hiren net gedeelt private Schlëssel. Als Resultat, wann de Jay de Message iwwerdréit, verschlësselt hien et mam Aayush sengem ëffentleche Schlëssel, deen nëmme mat dem Aayush säi private Schlëssel dekodéiert ka ginn.
Ähnlech wäert de Jay nëmmen dem Aayush seng Kommunikatioun dekodéieren. Als Resultat kënnen nëmmen de Jay an den Aaysuh d'Kommunikatioun vuneneen gesinn, an de Server funktionnéiert just als Paart am ganze Prozess.
5. Flaschenhals
All System ass ufälleg fir Feelfunktioun. Fir esou e grousse Volumen vum Traffic ze managen, muss de Service zu all Moment operationell a Feelertolerant bleiwen fir Flaschenhals ze vermeiden. Well eise Service ganz op Chat an Transient Serveren ofhängeg ass, musse mir all d'Problemer léisen, déi aus hirer Operatioun entstinn.
Feeler vum Chat Server: Dëst ass d'Häerz vun eisem System. Wann d'Benotzer online sinn, ass et verantwortlech fir d'Gestioun an d'Liwwerung vu Messagen. Als Resultat hält dëse System Linke mat senge Benotzer.
Als Resultat, wann dëse Service klappt, wäert déi ganz Architektur leiden. Et ginn zwou Approche fir den Echec vum Chat-Server ze managen. Eng Method ass d'TCP-Verbindungen op en anere Server ze verschécken, während eng aner ass et d'Benotzer z'erméiglechen, automatesch Verbindungen am Fall vun engem Verbindungsverloscht unzefänken.
Ausgefall vun Transient Stockage: En anere Komponent ufälleg fir Ausfall, dee schlussendlech de ganze Service beschiedegt kann ass transient Lagerung. Messagen ënnerwee fir offline Benotzer gi verluer wann dëse Service klappt.
Mir kënne Messageverloscht verhënneren andeems Dir déi temporär Späichere vun all Benotzer replizéiert. Als Resultat kann d'Replika benotzt ginn fir d'Funktiounen ze veraarbecht wann de Benotzer online zréckkënnt. Wann den ursprénglechen Server zougänglech gëtt, ginn souwuel d'Original wéi och d'Replica Instanzen vun der Iwwergangslagerung vum Benotzer an engem eenzege Buttek kombinéiert.
6. Optimisatiounstechniken
Latenz: Fir eng nahtlos a verbessert Clientserfarung ze liwweren, muss de Messenger-Service Echtzäit sinn. Als Resultat muss d'Latenz reduzéiert ginn andeems en Deel vun den dacks zougänglechen Donnéeën cache. Mir kënnen d'Benotzeraktivitéitsstatus a rezent Gespréicher an der Erënnerung cache mat engem verdeelte Cache wéi Redis.
Disponibilitéit: Mir brauchen eise Service fir déi meescht Zäit verfügbar ze sinn. Eise System muss Feeler-tolerant sinn, also kënne mir e puer Kopien vun temporäre Messagen halen, sou datt all Message, déi verluer geet, séier aus sengen Duplikate recuperéiert ka ginn. Als Resultat kann d'Disponibilitéit vum System net a Gefor gesat ginn.
Konklusioun
Eise System ënnerstëtzt elo nëmmen e puer Fäegkeeten, awer mir kënnen et ganz einfach ausbaue fir Gruppechats derbäi ze ginn fir Messagen un e puer Individuen ze verdeelen. Dir kënnt och Video- an Telefonrufffäegkeeten ubidden. Dëse System kann och esou entwéckelt ginn datt d'Benotzer Statusupdates oder narrativ publizéieren an géigesäiteg liesen.
Ech hu schwéier geschafft fir Iech en héijen Iwwerbléck vum WhatsApp System Design ze ginn. Ech hoffen Dir hutt et genoss a wäert et gutt benotzen.
Hannerlooss eng Äntwert