🥇FAQ iwwer Architektur an Aarbecht op VKontakte

D'Geschicht vun der Schafung vu VKontakte ass op Wikipedia, et gouf vum Pavel selwer erzielt. Et schéngt, datt jiddereen hir schonn kennt. Iwwer d'Intern, d'Architektur an d'Struktur vum Site op HighLoad ++ Pavel sot mir zréck am Joer 2010. Vill Servere sinn zënterhier gelaf, also wäerte mir d'Informatioun aktualiséieren: mir wäerte se dissektéieren, d'Innen eraushuelen, waacht et a kucken de VK Apparat aus enger technescher Siicht.

Alexey Akulovich (AterCattus) Backend Entwéckler am VKontakte Team. Den Transkript vun dësem Bericht ass eng kollektiv Äntwert op dacks gestallte Froen iwwer de Fonctionnement vun der Plattform, Infrastruktur, Serveren an Interaktioun tëscht hinnen, awer net iwwer Entwécklung, nämlech iwwer Eisen. Separat, iwwer Datenbanken a wat VK amplaz huet, iwwer Logbicher sammelen an de ganze Projet als Ganzt iwwerwaachen. Detailer ënner dem Schnëtt.

Zënter méi wéi véier Joer hunn ech mech mat all méiglechen Aufgaben am Zesummenhang mam Backend beschäftegt.

Eroplueden, späicheren, veraarbechten, verdeelen Medien: Video, Live Streaming, Audio, Fotoen, Dokumenter.
Infrastruktur, Plattform, Entwéckler Iwwerwachung, Logbicher, regional Cache, CDN, propriétaire RPC Protokoll.
Integratioun mat externe Servicer: Push Notifikatiounen, extern Link Parsing, RSS Feed.
Hëlleft Kollegen mat verschiddene Froen, d'Äntwerten op déi erfuerderen Tauchen an onbekannte Code.

Während dëser Zäit hat ech eng Hand a ville Komponente vum Site. Ech wëll dës Erfahrung deelen.

Allgemeng Architektur

Alles, wéi gewinnt, fänkt mat engem Server oder Grupp vu Serveren un, déi Ufroen akzeptéieren.

Front Server

De Frontserver akzeptéiert Ufroen iwwer HTTPS, RTMP an WSS.

Majo - dëst sinn Ufroe fir d'Haapt- a mobil Webversioune vum Site: vk.com an m.vk.com, an aner offiziell an inoffiziell Clientë vun eiser API: mobil Clienten, Messenger. Mir hunn eng Réceptioun RTMP-Trafic fir Live Sendungen mat getrennten Frontserveren a WSS-Verbindunge fir Streaming API.

Fir HTTPS an WSS op Serveren ass et wäert nginx. Fir RTMP Sendungen hu mir viru kuerzem op eis eege Léisung gewiesselt kive, awer et ass iwwer den Ëmfang vum Bericht. Fir Feeler Toleranz, Reklammen dës Serveren gemeinsam IP Adressen an Akt an Gruppen, sou datt wann et e Problem op ee vun de Serveren, Benotzer Ufroen sinn net verluer. Fir HTTPS a WSS verschlësselen déiselwecht Server den Traffic fir en Deel vun der CPU-Laascht op sech selwer ze huelen.

Mir schwätzen net weider iwwer WSS an RTMP, awer nëmmen iwwer Standard HTTPS Ufroen, déi normalerweis mat engem Webprojet verbonne sinn.

Backend

Hannert der viischter sinn normalerweis Backend Serveren. Si veraarbecht Ufroen déi de Frontserver vu Clienten kritt.

dëser kPHP Serveren, op deem den HTTP-Daemon leeft, well HTTPS scho entschlësselt ass. kPHP ass e Server deen op leeft prefork Modeller: fänkt e Meeschterprozess un, eng Rëtsch Kannerprozesser, passt lauschteren Sockets un hinnen a si veraarbecht hir Ufroen. An dësem Fall ginn d'Prozesser net tëscht all Ufro vum Benotzer nei gestart, awer einfach hiren Zoustand op den ursprénglechen Null-Wäertzoustand zréckgesat - Ufro no Ufro, anstatt nei ze starten.

Lastverdeelung

All eis Backends sinn net e grousse Pool vu Maschinnen déi all Ufro kënne veraarbecht. Mir hinnen an separat Gruppen opgedeelt: allgemeng, Handy, API, Video, Inszenéierung ... De Problem op eng separat Grupp vu Maschinnen wäert net all aner Afloss. Am Fall vu Probleemer mam Video wäert de Benotzer dee Musek lauschtert net emol iwwer d'Problemer wëssen. Wéi eng Backend fir d'Ufro ze schécken ass entscheet vum nginx op der viischter no der Configuratioun.

Metresch Sammlung a Rebalancing

Fir ze verstoen wéivill Autoen mir an all Grupp mussen hunn, mir vertrauen net op QPS. D'Backends sinn ënnerschiddlech, si hunn verschidden Ufroen, all Ufro huet eng aner Komplexitéit fir QPS ze berechnen. Dofir hu mir mir bedreiwen mam Konzept vun Laascht op de Server als Ganzt - op der CPU an perf.

Mir hunn Dausende vun esou Serveren. All kierperleche Server leeft eng kPHP Grupp fir all d'Kären ze recycléieren (well kPHP eenzeg thread ass).

Inhalt Server

CS oder Content Server ass eng Späichere. CS ass e Server deen Dateien späichert an och eropgeluede Dateie veraarbecht an all Zorte vu Synchron-Hannergrond Aufgaben déi den Haaptwebfrontend him zouginn.

Mir hunn Zéngdausende vu kierperleche Serveren déi Dateien späicheren. D'Benotzer hu gär Dateien eropzelueden, a mir späicheren se gären an deelen se. Verschidde vun dëse Serveren sinn duerch speziell PU zougemaach / pp Serveren.

pu/pp

Wann Dir de Reseau Tab am VK opgemaach hutt, hutt Dir pu / pp gesinn.

Wat ass pu/pp? Wa mir een Server nom aneren zoumaachen, da ginn et zwou Méiglechkeeten fir e Fichier op de Server ze lueden deen zougemaach gouf: direkt duerch http://cs100500.userapi.com/path oder iwwer Mëttelserver - http://pu.vk.com/c100500/path.

Pu ass den historeschen Numm fir Foto eropzelueden, an pp ass Foto Proxy. Dat ass, ee Server ass fir Fotoen eropzelueden, an en aneren ass fir Eroplueden. Elo ginn net nëmme Fotoe gelueden, mee den Numm ass erhale bleiwen.

Dës Serveren HTTPS Sessiounen ofschléissende Prozessor Laascht aus der Stockage ze läschen. Och, well Benotzerdateien op dëse Servere veraarbecht ginn, wat manner sensibel Informatioun op dëse Maschinnen gespäichert ass, wat besser. Zum Beispill, HTTPS Verschlësselungsschlësselen.

Well d'Maschinnen vun eisen anere Maschinnen zougemaach sinn, kënne mir eis et leeschten, hinnen net "wäiss" extern IPen ze ginn, an ginn "grau". Op dës Manéier hu mir op den IP-Pool gespuert a garantéiert d'Maschinnen vum Zougang vu baussen ze schützen - et gëtt einfach keng IP fir anzegoen.

Widderstandsfäegkeet iwwer gedeelt IPen. Wat d'Feeltoleranz ugeet, funktionnéiert de Schema d'selwecht - verschidde physesch Serveren hunn eng gemeinsam kierperlech IP, an d'Hardware virun hinnen wielt wou d'Ufro schécken. Ech wäert méi spéit iwwer aner Optiounen schwätzen.

De kontroverse Punkt ass dat an dësem Fall de Client hält manner Verbindungen. Wann et déiselwecht IP fir verschidde Maschinnen gëtt - mat deemselwechte Host: pu.vk.com oder pp.vk.com, huet de Client Browser eng Limit op d'Zuel vun de simultan Ufroen un engem Host. Awer an der Zäit vum ubiquitären HTTP / 2 gleewen ech datt dëst net méi sou relevant ass.

De offensichtleche Nodeel vum Schema ass datt et muss Pompel all Verkéier, déi op d'Späichere geet, duerch en anere Server. Well mir Pompel Verkéier duerch Maschinnen, mir kënnen nach net schwéier Verkéier Pompel, Zum Beispill, Video, déi selwecht Schema benotzt. Mir iwwerdroen et direkt - eng separat direkt Verbindung fir separat Späichere speziell fir Video. Mir iwwerdroen méi hell Inhalter duerch e Proxy.

Net viru laanger Zäit krute mir eng verbessert Versioun vum Proxy. Elo wäert ech Iech soen wéi se vun normalen ënnerscheeden a firwat dat néideg ass.

Sonn

Am September 2017 huet Oracle, dat virdru Sun kaaft hat, eng grouss Zuel vu Sonn Mataarbechter entlooss. Mir kënne soen datt de Moment d'Firma opgehalen huet ze existéieren. Bei der Auswiel vun engem Numm fir den neie System hunn eis Administrateuren décidéiert fir d'Erënnerung vun dëser Firma ze bezuelen an hunn den neie System Sun genannt. Ënnert eis nenne mir hir einfach "Sonn".

pp hat e puer Problemer. Eng IP pro Grupp - ineffektive Cache. Verschidde kierperlech Serveren deelen eng gemeinsam IP Adress, an et gëtt kee Wee fir ze kontrolléieren op wéi ee Server d'Ufro geet. Dofir, wann verschidde Benotzer fir déi selwecht Datei kommen, dann, wann et e Cache op dëse Serveren ass, endt d'Datei am Cache vun all Server. Dëst ass e ganz ineffiziente Schema, awer näischt konnt gemaach ginn.

Dofir - mir kënnen net Inhalt zerstéieren, well mir kënnen net e spezifesche Server fir dës Grupp auswielen - si hunn eng gemeinsam IP. Och fir e puer intern Grënn hu mir et war net méiglech esou Serveren an Regiounen ze installéieren. Si stoungen nëmmen zu St.

Mat de Sonnen hu mir de Selektiounssystem geännert. Elo hu mir Anycast Routing: dynamesch Routing, Anycast, Self-Check Daemon. All Server huet seng eege individuell IP, awer e gemeinsame Subnet. Alles ass sou konfiguréiert datt wann ee Server klappt, de Traffic automatesch iwwer déi aner Servere vun der selwechter Grupp verbreet gëtt. Elo ass et méiglech e spezifesche Server ze wielen, kee redundante Caching, an Zouverlässegkeet war net betraff.

Gewiicht Ënnerstëtzung. Elo kënne mir leeschten, Maschinnen vun ënnerschiddlecher Kraaft ze installéieren wéi néideg, an och, am Fall vun temporäre Probleemer, d'Gewiichter vun den Aarbechts "Sonn" änneren fir d'Laascht op hinnen ze reduzéieren, sou datt se "rouen" an erëm ufänken ze schaffen.

Sharding duerch Inhalt ID. Eng witzeg Saach iwwer Sharding: Mir schneiden normalerweis Inhalt sou datt verschidde Benotzer op déiselwecht Datei duerch déiselwecht "Sonn" goen, fir datt se e gemeinsame Cache hunn.

Mir hunn viru kuerzem d'App "Clover" gestart. Dëst ass en Online Quiz an enger Live Sendung, wou de Host Froen stellt an d'Benotzer an Echtzäit äntweren, Optiounen auswielen. D'App huet en Chat wou d'Benotzer kënne chatten. Kann gläichzäiteg mat der Sendung verbannen méi wéi 100 dausend Leit. Si schreiwen all Messagen déi un all Participanten geschéckt ginn, an en Avatar kënnt mat der Noriicht. Wann 100 dausend Leit fir een Avatar an enger "Sonn" kommen, da kann et heiansdo hannert enger Wollek rullen.

Fir Bursts vun Ufroe fir déiselwecht Datei ze widderstoen, ass et fir eng gewëssen Zort Inhalt datt mir en domm Schema ausschalten, deen Dateien iwwer all verfügbare "Sonn" an der Regioun verbreet.

Sonn vu bannen

Reverse Proxy op nginx, Cache entweder am RAM oder op schnelle Optane / NVMe Disks. Beispill: http://sun4-2.userapi.com/c100500/path - e Link op d'"Sonn", déi an der véierter Regioun läit, der zweeter Servergrupp. Et mécht d'Weedatei zou, déi kierperlech um Server 100500 läit.

Cover

Mir addéieren e méi Node un eisem architektonesche Schema - d'Caching-Ëmfeld.

Drënner ass de Layoutdiagramm regional Cache, et sinn ongeféier 20 vun hinnen. Dëst sinn d'Plaze wou Cache an "Sonn" sinn, déi de Traffic duerch sech selwer kache kënnen.

Dëst ass Caching vu Multimedia Inhalt; keng Benotzerdaten ginn hei gespäichert - just Musek, Video, Fotoen.

Fir d'Regioun vum Benotzer ze bestëmmen, mir mir sammelen BGP Reseau Präfix an de Regiounen ugekënnegt. Am Fall vu Réckfall musse mir och d'Geoip-Datebank analyséieren wa mir d'IP net duerch Präfixe fanne kënnen. Mir bestëmmen d'Regioun duerch d'IP vum Benotzer. Am Code kënne mir een oder méi Regiounen vum Benotzer kucken - déi Punkten, op déi hien geographesch am nootste ass.

Wéi heescht et schaffen?

Mir zielen d'Popularitéit vun Dateien no Regioun. Et gëtt eng Zuel vun de regionalen Cache wou de Benotzer lokaliséiert ass, an e Dateiidentifizéierer - mir huelen dëst Pair an erhéijen d'Bewäertung mat all Download.

Zur selwechter Zäit kommen Dämonen - Servicer a Regiounen - vun Zäit zu Zäit op d'API a soen: "Ech sinn esou e Cache, gitt mir eng Lëscht vun de populäersten Dateien a menger Regioun déi nach net op mir sinn. " D'API liwwert eng Rëtsch Dateien no Bewäertung zortéiert, den Daemon luet se erof, hëlt se an d'Regiounen a liwwert d'Dateien vun do aus. Dëst ass de fundamentalen Ënnerscheed tëscht pu/pp a Sun aus Cache: Si ginn de Fichier direkt duerch sech selwer, och wann dës Datei net am Cache ass, an de Cache lued d'Fichier fir d'éischt u sech selwer erof, a fänkt se dann zréck.

An dësem Fall kréien mir Inhalt méi no bei de Benotzer an d'Netzbelaaschtung ausbreeden. Zum Beispill, nëmmen aus dem Moskauer Cache verdeele mir méi wéi 1 Tbit / s während Spëtzestonnen.

Awer et gi Probleemer - Cache Serveren sinn net Gummistécker. Fir super populär Inhalt, heiansdo gëtt et net genuch Netzwierk fir e separaten Server. Eis Cache-Server sinn 40-50 Gbit/s, awer et gëtt Inhalter, deen esou e Kanal komplett verstoppt. Mir plënneren op d'Ëmsetzung vun der Späichere vu méi wéi enger Kopie vu populäre Dateien an der Regioun. Ech hoffen, datt mer dat bis Enn des Joers ëmsetzen.

Mir hunn déi allgemeng Architektur gekuckt.

Front Serveren déi Demanden akzeptéieren.
Backends datt Prozess Ufroen.
Stockage déi vun zwou Zorte vu Proxy zougemaach ginn.
Regional Cache.

Wat fehlt an dësem Diagramm? Natierlech sinn d'Datenbanken an deenen mir Daten späicheren.

Datenbanken oder Motoren

Mir nennen se net Datenbanken, awer Motoren - Motoren, well mir praktesch keng Datenbanken am allgemeng akzeptéierten Sënn hunn.

Dëst ass eng noutwendeg Moossnam. Dëst ass geschitt well am 2008-2009, wéi VK en explosive Wuesstum an der Popularitéit hat, huet de Projet ganz op MySQL a Memcache geschafft an et goufe Problemer. MySQL huet gär Dateien ofbriechen a korrupt, duerno géif et net erholen, a Memcache huet sech no an no an der Leeschtung ofgebaut a muss nei gestart ginn.

Et stellt sech eraus datt den ëmmer méi populäre Projet eng persistent Späichere hat, déi Daten korrupt, an e Cache, dee verlangsamt. An esou Konditiounen ass et schwéier e wuessende Projet z'entwéckelen. Et gouf decidéiert, déi kritesch Saachen, op déi de Projet konzentréiert ass, op eisen eegene Vëloen ëmzeschreiwen ze probéieren.

D'Léisung war erfollegräich. Et war eng Geleeënheet dëst ze maachen, wéi och eng extrem Noutwennegkeet, well aner Weeër fir ze skaléieren gouf et deemools net. Et goufe keng Rëtsch Datenbanken, NoSQL gouf et nach net, et waren nëmmen MySQL, Memcache, PostrgreSQL - an dat ass et.

Universal Operatioun. D'Entwécklung gouf vun eisem Team vun C Entwéckler gefouert an alles gouf op eng konsequent Manéier gemaach. Onofhängeg vum Motor, si haten all ongeféier datselwecht Dateiformat op Disk geschriwwe, déiselwecht Startparameter, veraarbecht Signaler op déiselwecht Manéier, a behuelen ongeféier d'selwecht am Fall vu Randsituatiounen a Probleemer. Mat dem Wuesstum vun de Motoren ass et bequem fir Administrateuren de System ze bedreiwen - et gëtt keen Zoo dee muss erhale ginn, a si mussen nei léieren wéi all nei Drëtt-Partei-Datebank ze bedreiwen, wat et méiglech gemaach huet séier a bequem ze erhéijen hir Zuel.

Zorte vu Motore

D'Equipe huet e puer Motoren geschriwwen. Hei sinn nëmmen e puer vun hinnen: Frënd, Hiweiser, Bild, ipdb, Bréiwer, Lëschten, Logbicher, memcached, meowdb, Neiegkeeten, Nostradamus, Foto, Playlists, pmemcached, Sandkëscht, Sich, Späicheren, Likes, Aufgaben, ...

Fir all Aufgab, déi eng spezifesch Datestruktur erfuerdert oder atypesch Ufroe veraarbecht, schreift d'C Team en neie Motor. Firwat net.

Mir hunn eng separat Motor memcached, deen ähnlech wéi e regelméissegen ass, awer mat enger Rëtsch vu Goodies, an deen net verlangsamt. Net ClickHouse, awer et funktionnéiert och. Getrennt verfügbar pmemcached Ass bestänneg memcached, déi och Daten op Disk späichere kann, ausserdeem, wéi passt an RAM, fir keng Daten beim Neistarten ze verléieren. Et gi verschidde Motore fir eenzel Aufgaben: Schlaangen, Lëschten, Sets - alles wat eise Projet erfuerdert.

Cluster

Aus enger Code Perspektiv ass et net néideg u Motoren oder Datenbanken als Prozesser, Entitéiten oder Instanzen ze denken. De Code funktionnéiert speziell mat Cluster, mat Gruppe vu Motoren - eng Zort pro Stärekoup. Loosst d'soen datt et e memcached Stärekoup ass - et ass just eng Grupp vu Maschinnen.

De Code brauch guer net déi kierperlech Plaz, Gréisst oder Zuel vun de Serveren ze wëssen. Hie geet an de Cluster mat engem bestëmmten Identifizéierer.

Fir dëst ze funktionnéieren, musst Dir eng méi Entitéit addéieren déi tëscht dem Code an de Motoren läit - Proxy.

RPC Proxy

Proxy konnektéieren Bus, op deem bal de ganze Site leeft. Zur selwechter Zäit hu mir kee Service Entdeckung - amplaz gëtt et eng Configuratioun fir dëse Proxy, deen d'Plaz vun alle Stärekéip an all Schiermer vun dësem Stärekoup kennt. Dëst ass wat d'Administrateuren maachen.

Programméierer egal wéi vill, wou a wat et kascht - si ginn just an de Cluster. Dëst erlaabt eis vill. Wann Dir eng Ufro kritt, redirectéiert de Proxy d'Ufro, wësse wou - et bestëmmt dat selwer.

An dësem Fall ass Proxy e Schutzpunkt géint Servicefehler. Wann e puer Motor verlangsamt oder crasht, da versteet de Proxy dat a reagéiert deementspriechend op d'Client Säit. Dëst erlaabt Iech den Timeout ze läschen - de Code waart net op de Motor fir ze reagéieren, awer versteet datt et net funktionnéiert a muss iergendwéi anescht behuelen. De Code muss op d'Tatsaach virbereet ginn datt d'Datebanken net ëmmer funktionnéieren.

Spezifesch Ëmsetzungen

Heiansdo wëlle mir nach wierklech eng Aart vun net-Standardléisung als Motor hunn. Zur selwechter Zäit gouf decidéiert net eise fäerdege rpc-Proxy ze benotzen, speziell fir eis Motoren erstallt, awer e separaten Proxy fir d'Aufgab ze maachen.

Fir MySQL, déi mir nach ëmmer hei an do hunn, benotze mir db-Proxy, a fir ClickHouse - Kittenhaus.

Et funktionnéiert allgemeng sou. Et gëtt e bestëmmte Server, et leeft kPHP, Go, Python - am Allgemengen, all Code deen eise RPC Protokoll benotze kann. De Code leeft lokal op engem RPC Proxy - all Server wou de Code läit leeft säin eegene lokale Proxy. Op Ufro versteet de Proxy wouhie goen.

Wann ee Motor op en anere wëll goen, och wann et en Noper ass, geet et duerch e Proxy, well de Noper an engem aneren Datenzenter ass. De Motor sollt net drop vertrauen, d'Plaz vun eppes anescht wéi selwer ze kennen - dat ass eis Standardléisung. Mee natierlech ginn et Ausnahmen :)

E Beispill vun engem TL-Schema no deem all Motore funktionnéieren.

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

Dëst ass e binäre Protokoll, deen am nootsten Analog ass protobuf. De Schema beschreift fakultativ Felder, komplex Aarte - Extensiounen vun agebaute Skalaren, a Ufroen. Alles funktionnéiert no dësem Protokoll.

RPC iwwer TL iwwer TCP / UDP ... UDP?

Mir hunn e RPC Protokoll fir Motor Ufroen auszeféieren déi uewen um TL Schema leeft. Dëst funktionnéiert alles iwwer eng TCP / UDP Verbindung. TCP ass verständlech, awer firwat brauche mir UDP dacks?

UDP hëlleft vermeiden de Problem vun enger grousser Zuel vu Verbindungen tëscht Serveren. Wann all Server e RPC Proxy huet an allgemeng kann et op all Motor goen, da ginn et Zéngdausende vun TCP Verbindungen pro Server. Et gëtt eng Laascht, awer et ass nëtzlos. Am Fall vun UDP gëtt dëse Problem net.

Kee redundante TCP Handschlag. Dëst ass en typesche Problem: wann en neie Motor oder en neie Server lancéiert gëtt, gi vill TCP Verbindungen op eemol etabléiert. Fir kleng liicht Ufroen, Zum Beispill, UDP Notzlaascht, all Kommunikatioun tëscht dem Code an de Motor ass zwee UDP Pakete: een flitt an eng Richtung, déi zweet an déi aner. Eng Ronn Rees - an de Code krut eng Äntwert vum Motor ouni Handschlag.

Jo, alles funktionnéiert just mat engem ganz klenge Prozentsaz vu Paketverloscht. De Protokoll huet Ënnerstëtzung fir Retransmits an Timeouts, awer wa mir vill verléieren, kréie mir bal TCP, wat net profitabel ass. Mir fueren net UDP iwwer Ozeanen.

Mir hunn Dausende vun esou Serveren, an de Schema ass d'selwecht: e Pack vu Motoren ass op all kierperlechen Server installéiert. Si si meeschtens Single-threaded fir sou séier wéi méiglech ze lafen ouni ze blockéieren, a sinn als Single-threaded Léisunge geschnidden. Zur selwechter Zäit hu mir näischt méi zouverléisseg wéi dës Motoren, a vill Opmierksamkeet gëtt op persistent Datelagerung bezuelt.

Persistent Datelagerung

Motore schreiwen binlogs. E Binlog ass e Fichier um Enn vun deem en Event fir eng Ännerung vum Staat oder Daten dobäigesat gëtt. A verschiddene Léisunge gëtt et anescht genannt: binäre Log, WALL, AOF, mä de Prinzip ass déi selwecht.

Fir ze verhënneren, datt de Motor de ganze Binlog fir vill Jore beim Restart erëm liest, schreiwen d'Motoren Snapshots - aktuellen Zoustand. Wann néideg, liesen se fir d'éischt dovun, an dann fäerdeg aus dem Binlog ze liesen. All Binlogs ginn am selwechte binäre Format geschriwwe - laut dem TL Schema, sou datt d'Administrateuren se mat hiren Tools gläich verwalten kënnen. Et gëtt keen esou Besoin fir Snapshots. Et gëtt en allgemenge Header, deen uginn, wiem säi Snapshot Int ass, Magie vum Motor, a wéi ee Kierper fir jiddereen net wichteg ass. Dëst ass e Problem mam Motor deen de Snapshot opgeholl huet.

Ech wäert séier de Prinzip vun der Operatioun beschreiwen. Et gëtt e Server op deem de Motor leeft. Hien mécht en neien eidelen Binlog fir ze schreiwen a schreift en Event fir ze änneren.

Irgendwann entscheet hien entweder selwer e Snapshot ze maachen, oder hien kritt e Signal. De Server erstellt eng nei Datei, schreift de ganzen Zoustand an et, fügt déi aktuell Binloggréisst - Offset - un d'Enn vun der Datei an a schreift weider. En neie Binlog gëtt net erstallt.

Irgendwann, wann de Motor nei gestart gëtt, gëtt et souwuel e Binlog wéi och e Schnappschëss op der Disk. De Motor liest de ganze Snapshot an erhéicht säin Zoustand zu engem gewësse Punkt.

Liest d'Positioun déi war an der Zäit wou de Snapshot erstallt gouf an d'Gréisst vum Binlog.

Liest d'Enn vum Binlog fir den aktuellen Zoustand ze kréien a schreift weider Eventer. Dëst ass en einfache Schema; all eis Motore schaffen no deem.

Daten Replikatioun

Als Resultat, Datereplikatioun an eisem Ausso baséiert - mir schreiwen am Binlog keng Säit Ännerungen, mä nämlech änneren Ufroen. Ganz ähnlech wéi wat iwwer d'Netz kënnt, nëmme liicht geännert.

Datselwecht Schema gëtt net nëmme fir Replikatioun benotzt, awer och fir Backups ze kreéieren. Mir hunn e Motor - e Schreifmeeschter deen op de Binlog schreift. Op all aner Plaz wou d'Administrateuren et ageriicht hunn, gëtt dëse Binlog kopéiert, an dat ass et - mir hunn e Backup.

Wann néideg liesen replicaFir d'CPU Liesbelaaschtung ze reduzéieren, gëtt de Liesmotor einfach gestart, deen d'Enn vum Binlog liest an dës Befehle lokal ausféiert.

D'Laag hei ass ganz kleng, an et ass méiglech erauszefannen wéi vill d'Replique hannert dem Meeschter läit.

Daten Sharing am RPC Proxy

Wéi funktionnéiert d'Sharding? Wéi versteet de Proxy op wéi eng Cluster Shard ze schécken? De Code seet net: "Schéckt fir 15 Stécker!" - nee, dëst gëtt vum Proxy gemaach.

Déi einfachst Schema ass firstint - déi éischt Nummer an der Demande.

get(photo100_500) => 100 % N.

Dëst ass e Beispill fir en einfachen memcached Textprotokoll, awer natierlech kënnen Ufroen komplex a strukturéiert sinn. D'Beispill hëlt déi éischt Nummer an der Ufro an de Rescht wann se gedeelt duerch d'Clustergréisst.

Dëst ass nëtzlech wa mir Datenlokal vun enger eenzeger Entitéit wëllen hunn. Loosst eis soen datt 100 e Benotzer- oder Grupp-ID ass, a mir wëllen datt all d'Donnéeë vun enger Entitéit op engem Shard fir komplex Ufroen sinn.

Wa mir egal sinn wéi Ufroen iwwer de Cluster verbreet sinn, gëtt et eng aner Optioun - de ganze Schnëtt zerstéieren.

hash(photo100_500) => 3539886280 % N

Mir kréien och den Hash, de Rescht vun der Divisioun an d'Shardnummer.

Béid vun dësen Optiounen funktionnéieren nëmme wa mir op d'Tatsaach bereet sinn datt wa mir d'Gréisst vum Stärekoup erhéijen, mir et opdeelen oder e puer Mol erhéijen. Zum Beispill hu mir 16 Stécker, mir hunn net genuch, mir wëllen méi - mir kënne sécher 32 kréien ouni Ënnerbriechung. Wa mir net Multiple erhéijen wëllen, gëtt et Ausdauer, well mir kënnen net alles präzis opdeelen ouni Verloschter. Dës Optiounen sinn nëtzlech, awer net ëmmer.

Wa mir brauchen eng arbiträr Zuel vun Serveren derbäi oder ewechzehuelen, mir benotzen Konsequent hashing op de Ring a la Ketama. Awer gläichzäiteg verléieren mir d'Lokalitéit vun den Donnéeën komplett; Mir mussen d'Ufro un de Cluster fusionéieren, sou datt all Stéck seng eege kleng Äntwert zréckkënnt, an dann d'Äntwerten op de Proxy fusionéieren.

Et gi super spezifesch Ufroen. Et gesäit esou aus: RPC Proxy kritt d'Ufro, bestëmmt op wéi ee Stärekoup ze goen a bestëmmt d'Shard. Da ginn et entweder schrëftlech Meeschter, oder, wann de Stärekoup Replica Ënnerstëtzung huet, schéckt et zu enger Replikatioun op Nofro. De Proxy mécht dat alles.

Logbicher

Mir schreiwen Logbicher op verschidde Manéieren. Déi offensichtlechst an einfachst ass schreiwen Logbicher op memcache.

ring-buffer: prefix.idx = line

Et gëtt e Schlëssel Präfix - den Numm vum Logbuch, eng Linn, an et gëtt d'Gréisst vun dësem Log - d'Zuel vun de Linnen. Mir huelen eng zoufälleg Zuel vun 0 op d'Zuel vun den Zeilen minus 1. De Schlëssel am memcache ass e Präfix, dat mat dëser zoufälleger Zuel verbonnen ass. Mir späicheren d'Logbuchlinn an déi aktuell Zäit zum Wäert.

Wann et néideg ass Logbicher ze liesen, maache mir Multi Get all Schlësselen, no Zäit zortéiert, an domat eng Produktioun Log an real Zäit kréien. De Schema gëtt benotzt wann Dir eppes an der Produktioun an Echtzäit muss debuggen, ouni eppes ze briechen, ouni ze stoppen oder de Verkéier op aner Maschinnen z'erméiglechen, awer dëse Log dauert net laang.

Fir zouverlässeg Lagerung vu Logbicher hu mir e Motor Logbicher-Moteur. Dat ass genee firwat et erstallt gouf a vill an enger grousser Zuel vu Stärekéip benotzt gëtt. De gréisste Cluster, deen ech weess, späichert 600 TB vu gepackte Logbicher.

De Motor ass ganz al, et gi Cluster déi scho 6-7 Joer al sinn. Et gi Probleemer mat deem, déi mir probéieren ze léisen, zum Beispill, hu mir ugefaang ClickHouse aktiv ze benotzen fir Logbicher ze späicheren.

Sammelt Logbicher am ClickHouse

Dëst Diagramm weist wéi mir an eise Motore goen.

Et gëtt Code dee lokal iwwer RPC op de RPC-Proxy geet, an et versteet wou de Motor geet. Wa mir Logbicher an ClickHouse wëllen schreiwen, musse mir zwee Deeler an dësem Schema änneren:

ersetzen e puer Motor mat ClickHouse;
ersetzen de RPC Proxy, deen net Zougang zu ClickHouse kann, mat enger Léisung déi kann, an iwwer RPC.

De Motor ass einfach - mir ersetzen et mat engem Server oder e Stärekoup Server mat ClickHouse.

A fir op ClickHouse ze goen, hu mir dat gemaach KittenHouse. Wa mir direkt vum KittenHouse op ClickHouse goen, geet et net ëm. Och ouni Ufroe füügt et aus HTTP-Verbindunge vun enger grousser Zuel vu Maschinnen. Fir de Schema ze schaffen, op engem Server mat ClickHouse lokal ëmgedréint Proxy gëtt erhéicht, déi esou geschriwwe gëtt datt et déi erfuerderlech Volumen vu Verbindunge widderstoen kann. Et kann och Daten a sech selwer relativ zouverlässeg bufferen.

Heiansdo wëlle mir de RPC Schema net an net-Standardléisungen ëmsetzen, zum Beispill an nginx. Dofir huet KittenHouse d'Fäegkeet Logbicher iwwer UDP ze kréien.

Wann de Sender an den Empfänger vun de Logbicher op der selwechter Maschinn funktionnéieren, dann ass d'Wahrscheinlechkeet fir en UDP Paket am lokalen Host ze verléieren zimlech niddereg. Als Kompromiss tëscht der Bedierfnes fir RPC an enger Drëtt Partei Léisung an Zouverlässegkeet ëmzesetzen, benotze mir einfach UDP Sendung. Mir wäerten spéider op dëse Schema zréckkommen.

Iwwerwaachung

Mir hunn zwou Zorte vu Logbicher: déi gesammelt vun Administrateuren op hire Serveren an déi vun Entwéckler aus Code geschriwwe ginn. Si entspriechen zwou Zorte vu Metriken: System a Produit.

System Metriken

Et funktionnéiert op all eise Serveren Netdaten, déi Statistike sammelt a schéckt se un Graphite Carbon. Dofir gëtt ClickHouse als Späichersystem benotzt, an net zum Beispill Whisper. Wann néideg, kënnt Dir direkt aus ClickHouse liesen, oder benotzen grafana fir Metriken, Grafiken a Berichter. Als Entwéckler hu mir genuch Zougang zu Netdata a Grafana.

Produit Metriken

Fir d'Bequemlechkeet hu mir vill Saachen geschriwwen. Zum Beispill gëtt et eng Rei vu ordinäre Funktiounen, déi Iech erlaben Counts, UniqueCounts Wäerter an Statistiken ze schreiwen, déi iergendwou méi wäit geschéckt ginn.

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

Duerno kënne mir d'Sortéierungs- a Gruppéierungsfilter benotzen an alles maachen wat mir aus Statistike wëllen - Grafike bauen, Watchdogs konfiguréieren.

Mir schreiwen ganz vill Metriken d'Zuel vun den Eventer ass vu 600 Milliarden op 1 Billioun pro Dag. Mir wëllen se awer behalen op d'mannst e puer JoerTrends a Metriken ze verstoen. Alles zesummen ze setzen ass e grousse Problem dee mir nach net geléist hunn. Ech soen Iech wéi et an de leschte Joren fonctionnéiert.

Mir hunn Funktiounen déi dës Metriken schreiwen zu lokal memcachefir d'Zuel vun den Entréen ze reduzéieren. Eemol an enger kuerzer Zäit lokal lancéiert Statistiken-Daemon sammelt all records. Als nächst fusionéiert den Dämon d'Metriken an zwou Schichten vu Serveren Logbicher-Sammler, déi Statistike vun enger Rëtsch vun eise Maschinnen aggregéiert, fir datt d'Schicht hannert hinnen net stierft.

Wann néideg, kënne mir direkt un Logbicher-Sammler schreiwen.

Mee Schreiwen vum Code direkt un Sammler, Ëmgank stas-daemom, ass eng schlecht scalable Léisung well et d'Laascht op de Sammler erhéicht. D'Léisung ass gëeegent nëmme wa mir aus iergendengem Grond de memcache-Statistik-Daemon op der Maschinn net kënnen erhéijen, oder et ass erofgefall a mir sinn direkt gaang.

Als nächst fusionéiere Logbicher-Sammler Statistiken an meow DB - dëst ass eis Datebank, déi och Metriken späichere kann.

Da kënne mir binär "near-SQL" Selektiounen aus dem Code maachen.

Experiment

Am Summer 2018 hu mir en internen Hackathon, an d'Iddi ass opkomm fir de rouden Deel vum Diagramm ze ersetzen mat eppes wat Metriken am ClickHouse späichere konnten. Mir hunn Logbicher op ClickHouse - firwat probéiert et net?

Mir haten e Schema dat Logbicher duerch KittenHouse geschriwwen huet.

Mir hunn decidéiert füügt en aneren "* Haus" zum Diagramm, déi genee d'Metriken am Format kréien wéi eise Code se iwwer UDP schreift. Da mécht dëst * Haus se an Inserts, wéi Logbicher, déi KittenHouse versteet. Hien kann dës Logbicher perfekt op ClickHouse liwweren, wat se fäeg ass ze liesen.

De Schema mat memcache, Statistik-Daemon a Logbicher-Sammler Datebank gëtt mat dësem ersat.

Et gëtt e Verschécken vum Code hei, dee lokal am StatsHouse geschriwwe gëtt.
StatsHouse schreift UDP Metriken, scho an SQL Inserts ëmgewandelt, op KittenHouse a Chargen.
KittenHouse schéckt se op ClickHouse.
Wa mir se wëllen liesen, da liese mir se ëmgoen StatsHouse - direkt vum ClickHouse mat normale SQL.

Ass et nach ëmmer en Experiment, mee mir gefällt wéi et sech erauskënnt. Wa mir d'Problemer mam Schema fixéieren, da wäerte mir vläicht komplett dorop wiesselen. Perséinlech hoffen ech.

De Schema spuert net Eisen. Manner Server si gebraucht, lokal Statistiken-Dämonen a Logbicher-Sammler sinn net gebraucht, awer ClickHouse erfuerdert e méi grousse Server wéi déi am aktuellen Schema. Manner Servere si gebraucht, awer si musse méi deier a méi mächteg sinn.

Deploy

Als éischt kucke mer d'PHP Deployment. Mir entwéckelen an Go: benotzen GitLab и TeamCity fir Asaz. Entwécklungszweige ginn an d'Meeschterzweig fusionéiert, vum Master fir Tester gi se an d'Staging fusionéiert, a vun der Inszenéierung an d'Produktioun.

Virun Deployment ginn déi aktuell Produktiounszweige an déi virdrun geholl, an diff Dateien ginn an hinnen ugesinn - Ännerungen: erstallt, geläscht, geännert. Dës Ännerung gëtt am Binlog vun engem speziellen Copyfast-Moteur opgeholl, dee séier Ännerungen op eiser ganzer Serverflott replizéiere kann. Wat hei benotzt gëtt ass net direkt kopéieren, awer Klatsch Replikatioun, wann een Server Ännerungen un seng noosten Noperen schéckt, déi un hir Noperen, etc. Dëst erlaabt Iech de Code an Zénger an Eenheeten vu Sekonnen iwwer d'ganz Flott ze aktualiséieren. Wann d'Ännerung d'lokal Replica erreecht, applizéiert se dës Flecken op seng lokal Dateisystem. Rollback gëtt och no dem selwechte Schema duerchgefouert.

Mir installéieren och kPHP vill an et huet och seng eege Entwécklung op Go no dem Diagramm uewendriwwer. Zënter dëser HTTP Server binär, da kënne mir net diff produzéieren - d'Verëffentlechungsbinär weegt Honnerte vu MB. Dofir gëtt et eng aner Optioun hei - d'Versioun ass geschriwwe ginn binlog copyfast. Mat all Build vergréissert et, a während der Rollback erhéicht et och. Versioun op Server replizéiert. Lokal Copyfasts gesinn datt eng nei Versioun an de Binlog erakomm ass, an duerch déiselwecht Klatschreplikatioun huelen se déi lescht Versioun vum Binär fir sech selwer, ouni eise Masterserver ze midd, awer suergfälteg d'Laascht iwwer d'Netz ze verdeelen. Wat duerno graceful relancéiert fir déi nei Versioun.

Fir eis Motoren, déi och am Fong Binär sinn, ass de Schema ganz ähnlech:

git Meeschtesch Branche;
binär an .deb;
d'Versioun gëtt op binlog copyfast geschriwwen;
replizéiert op Serveren;
de Server zitt eng frësch .dep;
dpkg -ech;
graceful relancéiert nei Versioun.

Den Ënnerscheed ass datt eis Binär an Archiven verpackt ass .deb, a wann se auspompelen dpkg -ech sinn op de System gesat. Firwat gëtt kPHP als Binär ofgesat, a Motore ginn als dpkg ofgesat? Et ass esou geschitt. Et funktionnéiert - beréiert et net.

Nëtzlech Adressen:

Bericht vum Anton Kiryushkin "Vkontakte System Administrateur. Wéi?" mat Detailer iwwer Copyfast a Klatsch.
Bericht vum Yuri Nasretdinov "Wéi VK Daten an CLickHouse vun Zéngdausende vu Serveren setzt".
Mäi Bericht "Architektur vun engem wuessende Projet mam Beispill vu VKontakte", mee aus enger Entwécklung Siicht, net Hardware.

Alexey Akulovich ass ee vun deenen, déi als Deel vum Programm Comité hëlleft PHP Russland den 17. Mee wäert de gréissten Event fir PHP Entwéckler an de leschte Zäiten ginn. Kuckt wat fir e coolen PC mir hunn, wat Spriecher (zwee vun hinnen entwéckelen PHP Kär!) - schéngt wéi eppes Dir net verpassen kann wann Dir PHP schreift.

Source: will.com

FAQ iwwer Architektur an Aarbecht vun VKontakte