Zhihuang Chen | Inginer software, Core-Services

Provocarile apar in mod natural odata cu cresterea rapida a Pinterest. In calitate de Pinner, este posibil sa fi observat unele cazuri in care datele dvs. nu par „corecte” si este posibil sa fi avut o experienta negativa din cauza asta. De exemplu: „Numarul de pini” din profilul dvs. arata numarul incorect de pini, asa cum se arata in imaginea din stanga.

Array

Aceste scenarii de integritate referentiala le numim „incoerente ale datelor”, deoarece datele stocate intr-un backend nu se potrivesc cu datele stocate intr-un alt backend. Dupa cum puteti vedea, aceste inconsecvente influenteaza in mod direct experienta Pinners, deoarece le aratam continut invechit. De asemenea, aceste neconcordante contribuie foarte mult la costurile de intretinere ale echipei noastre. Daca un Pinner a constatat ca datele lor sunt gresite, ar putea raporta acest lucru echipei noastre de operatiuni.

Array

Atunci cand echipa de operatiuni nu poate rezolva aceste probleme folosind operatiuni regulate, ne-ar crea bilete de erori. Pentru a imbunatati experienta utilizatorului, precum si pentru a reduce activitatea de intretinere a echipei, speram sa construim un instrument care detecteaza si remediaza automat aceste neconcordante.

Acest proiect se concentreaza pe abordarea neconcordantelor dintre cele trei modele de baza ale noastre: Pinners, table si Pins.

Folosim MySQL ca magazin principal de date pentru stocarea continutului creat de Pinners.

Array

Pentru a stoca miliarde de Pin-uri, placi si alte date pentru sute de milioane de Pinners, multe instante de baze de date MySQL formeaza un cluster MySQL, care este impartit in cioburi logice pentru a gestiona si servi datele mai eficient. Toate datele sunt impartite pe aceste fragmente.

Mai jos este o relatie simplificata intre aceste trei modele stocate in MySQL:

Din pacate, datorita procesarii asincrone a datelor in fluxuri multiple, inconsecventa datelor este introdusa inevitabil in magazinul nostru de date.

Bazele noastre de date sunt impartite si unele dintre scrieri sunt asincronizate, ceea ce inseamna ca uneori nu putem face actualizarea intr-o singura tranzactie.

De exemplu, atunci cand creati un Pin, acesta ar trebui sa fie inserat in tabelul Pins, in tabelul de relatii Pinner-Pin si in tabelul de relatii bord-Pin. In mod ideal, facem aceste trei actualizari intr-o singura tranzactie, dar uneori cele trei tabele pe care dorim sa le actualizam nu exista in acelasi fragment, sau cele trei actualizari sunt asincronizate. Inconsistenta se intampla daca scriem cu succes intr-un tabel, dar altele nu reusesc.

Arhitectura

Vrem sa rezolvam aceasta problema prin crearea unui instrument pentru detectarea automata si rezolvarea automata a neconcordantelor datelor. Cea mai importanta parte a acestui instrument consta din doua parti:

  1. Lucrarile de validare a existentei, afisate in caseta roz, sunt utilizate pentru a verifica existenta datelor in baza de date. Lucrarile de verificare a existentei vor fi declansate la fiecare scriere pe trei obiecte de baza (Pinners, table si Pin).
  2. Lucrarile de validare a statelor, afisate in caseta portocalie, sunt utilizate pentru a verifica acuratetea statisticilor. Una dintre statisticile care verifica joburile verifica statisticile utilizatorilor, care stocheaza numarul de Pinuri publice ale unui Pinner. Celelalte verifica statisticile bordului, care stocheaza numarul de Pinuri pe care le are un board.

Lucrarile de verificare a existentei sunt mai usoare decat verificarea statisticilor, deoarece trebuie sa interogheze numai daca datele sunt sau nu in tabel. Statisticile care verifica joburile implica mai multe calcule, deoarece trebuie sa extraga date exacte, deoarece validam un anumit numar. De exemplu, atunci cand verificam statisticile bordului, trebuie sa obtinem toti Pinii bordului pentru a calcula acest numar. Toate aceste joburi sunt joburi asincrone care utilizeaza Pinlater, care este un instrument de planificare si executare a lucrarilor interne Pinterest. In comparatie cu alte instrumente de planificare a lucrarilor pe care le avem, Pinlater este cel mai usor si ofera o viteza de dequeue reglabila, de mare viteza. Dincolo de aceasta, coada pentru a lasa latenta este destul de mica, aproape in timp real.

Asa cum se arata in diagrama de mai sus, intregul flux este:

  1. Acest instrument este declansat atunci cand serviciul nostru detecteaza operatiunea de scriere a obiectelor de baza si stocheaza o lucrare proxy cu unii parametri, cum ar fi ID-ul obiectului unic, tipul de operatie si parametri suplimentari.
  2. Apoi, acest job proxy va stoarce unul dintre joburile de verificare a existentei.
  3. Daca se creeaza un Pin, statisticile de bord ar trebui sa creasca cu unul. Daca un Pin este sters, statisticile de bord ar trebui sa scada cu unul. Adica, unele operatiuni ar putea influenta statisticile, asa ca s-ar putea sa dorim sa scoatem de asemenea locuri de munca in statistici.
  4. Odata ce aceste lucrari asincronizate au fost stinse si executate, logica lucrarilor va verifica bazele de date si cache-urile pentru a se asigura ca datele sunt consistente.
  5. Daca detecteaza vreo inconsecventa, va remedia inconsecventa si va readuce la coada lucrarea pentru a o verifica din nou pentru a va asigura ca este consecventa.

Executarea postului amanata si limitata

Un lucru demn de remarcat este ca lucrarile sunt intarziate pentru a fi executate. De ce? In primul rand, unele lucrari sunt puse in asteptare inainte ca actualizarea sa aiba loc, deoarece vrem sa ne asiguram ca aceste joburi sunt puse in coada chiar daca actualizarea a esuat din cauza problemelor bazei de date sau a esecului retelei. Prin urmare, joburile trebuie sa astepte executarea actualizarii. In al doilea rand, dupa actualizarea bazei de date, ar putea exista unele lucrari asincronice de facut, cum ar fi curatarea cache-ului sau stergerea Pinilor daca este o stergere a placii. De asemenea, slujbele diferite pot avea un timp diferit.

O alta parte importanta este executia limitata a statisticilor. Deci, mai intai, ce este asta? Dupa cum am spus mai devreme, statisticile de bord vor fi modificate daca se creeaza sau se sterge un Pin, astfel, fiecare creare sau stergere a Pinului va declansa o posibila coada de verificare a lucrarii o data. Si daca ati sters o placa care contine 100 de pini, sarcina statisticilor placii pentru acest board_id va fi stoarca de 100 de ori. Aceasta este o risipa de resurse de calcul si aduce o sarcina suplimentara asupra serviciilor noastre, deoarece fiecare lucrare va interoga date online. Pentru a rezolva aceasta problema, folosim memcache pentru a stoca ID-urile pe care le-am strans si verificam daca ID-ul se afla in cache sau nu. Daca se afla in memoria cache, ceea ce inseamna ca exista deja o lucrare pusa pe coada, nu este nevoie sa o punem din nou in coada. Cand jobul de verificare a statisticilor este stors si executat, acesta va sterge intrarea in cache, astfel incat data viitoare sa poata fi stors din nou.

Nu am primit bilete de asistenta pentru clienti de sase luni, deoarece neconcordantele au fost remediate automat. De asemenea, toate noile inconsecvente introduse in sistemul nostru au fost remediate in 24 de ore.

Multumim lui Kapil Bajaj, Qi Li si restului echipei Core Services de la Pinterest!

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR