ABONAMENTE VIDEO REDACȚIA
RO
EN
Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 12
Abonament PDF

Sisteme cu perfomanță/fiabilitate ridicată bazate pe “data grids” în Java

Attila-Mihaly Balazs
Software Panther @ Synapp.io



PROGRAMARE

O provocare importantă când construim un produs de succes este să ne asigurăm că produsul utilizează resursele hardware disponibile într-un mod eficient. Acest lucru înseamnă de obicei clustering (mai puțin pentru probleme foarte simple) pentru că seturile noastre de date au depășit calculatoarele individuale ca mărime și necesități de procesare. Cu toate acestea clustering-ul aduce o serie de noi probleme: împărțirea procesării între noduri, orchestrarea procesului și - foarte important - garanția că nu vom pierde datele / progresul dacă un subset de noduri devine indisponibill - o posibilitate care crește dramatic în momentul în care adăugăm mai multe noduri la cluster-ul nostru.

"Data grids" sunt o categorie de software middleware, care ajută la rezolvarea problemelor enumerate mai sus. În acest articol voi prezenta o implementare rudimentară de bursă electronică care - în ciuda simplității sale - are robustețea și performanța cerută de la sisteme reale grație librăriei pe care se bazează.

Bazele data grid-urilor

Data grid-urile furnizează trei servicii principale:

  • Una sau mai multe structuri de date de tip cheie-valoare (asemănător interfeței Map din Java). Datele din aceste structuri sunt replicate pentru o fiabilitate ridicată.
  • În același timp permit definirea unui set de reguli pentru plasarea a datelor (de exemplu: trebuie ținute N copii pentru fiecare element, dintre care K trebuie să fie pe un anumit set de noduri - pentru asigurarea replicării geografice de exemplu) care măresc performanța (datele folosite împreună pot fi plasate pe același nod) și asigură garanții în cazul în care un subset de noduri devin indisponibile (fail-over între data-center-uri de exemplu).
  • Un serviciu de execuție care poate rula task-uri pe noduri. Aceste servicii de obicei sunt parametrizate folosind cheile din structurile (Map-urile) cheie-valoare pentru a se asigura că codul rulează pe mașina unde se află datele care urmează să le proceseze pentru evitarea transportul datelor prin rețea în mod repetat.
  • Posibilitatea de a fi notificat despre evenimentele din structurile cheie-valoare (adăugarea / eliminarea / actualizarea datelor)

Deși nu este o cerință ca un sistem săfie considerat "data-grid", de obicei aceste librării pun la dispoziție o interfață configurabilă care să persiste datele în sisteme externe - baze de date / fișiere simple / etc. - ca să fie păstrate în timpul repornirii complete a sistemului (data-grid-urile stochează datele exclusiv în memoria volatilă). De asemenea, ele implementează de obicei suport pentru operații tranzacționale pe structurile de date.

Biblioteca, prezentată în acest articol - Infinispan - foloseşte o tehnică numită hash-uri consistente pentru a oferi următoarea configurație posibilă în timpul rulării: folosind N noduri, vrem să păstrăm fiecare bucată de date pe exact K dintre ele (K≤N - de obicei 2 sau 3). Dacă sunt adăugate sau eliminate din cluster noduri, datele sunt redistribuite în așa fel încât proprietatea să fie menținută. Această redistribuție se întâmplă în mod transparent din punct de vedere funcțional (proprietățile non-funcționale a sistemului - cum ar fi latența - se schimbă în timpul procesului de redistribuție). Puteți vedea o ilustrare a conceptului în graficul alăturat:

Aici avem fiecare bucată de date (D1, D2 și D3) replicat în trei noduri, ceea ce înseamnă că oricare două noduri pot eșua în orice moment și datele vor fi disponibile în continuare. Un alt efect util al acestui mecanism de replicare este utilizarea optimă a resurselor în comparație cu oglindirea (mirroring) simplă:

De exemplu, să presupunem că avem N noduri, fiecare cu 12 GB de memorie. Dacă am păstra o copie identică a setului de date pe fiecare nod, dimensiunea maximă a datelor ar fi de 12 GB (dar am avea N copii, însemnând ca sistemul tolerează eșuarea a N-1 noduri). Dacă decidem că K exemplare a datelor (unul primar și K-1 copii) sunt suficiente pentru a satisface cerințele noastre de fiabilitate și folosim un sistem bazat pe hash consistent (ca și cel oferit de Infinispan), avem un maxim teoretic pentru dimensiunea datelor de (N*12GB.)/K. De exemplu, pentru N = 10 și K = 3 obținem o dimensiune maximă de40 GB (în comparație cu 12GB pentru cazul cu replicare completă).

O scurtă istorie a Infinispan-ului

Infinispan este un proiect din cadrul meta-proiectului JBoss susținut de RedHat. Este un data-grid extrem de configurabil cu un set extins de facilități. Este succesorul produsului JBoss Cache cu multe caracteristici interesante:

  • scalabilitate înaltă,
  • suport pentru a rula ca server dedicat sau încorporat (embedded) în proces,
  • suport pentru operații tranzacționale,
  • replicare configurabilă între noduri și între centre de date,
  • posibilitatea de accesarea datelor prin interfețe standard, cum ar fi REST, protocolul memcached, WebSockets sau printr-un protocol binar numit Hotrod

Folosirea Infinispan-ului este simplă - doar adăugăm dependența de Maven în POM și putem începe să o utilizăm. Se bazează pe JGroups, o soluție de messaging fiabil pur Java, ceea ce înseamnă că nu există un cod nativ care trebuie compilat / instalat. Infinispan este disponibil sub licența LGPL 2.1 , ceea ce înseamnă că poate fi utilizat în orice proiect (comercial sau open-source). De asemenea, este disponibil suport comercial pentru el de la RedHat sub denumirea "Red Hat JBoss Data Grid".

Descrierea proiectului

Acest proiect modelează "inima" unei burse electronice: motorul de potrivire (matching engine). Ea face acest lucru cu o performanță similară cu sistemele reale (peste 500 de evenimente pe secundă, în timp ce cea mai populară bursă de Bitcoin - MtGox - are în medie mai puțin de o tranzacție pe secundă). Fiind construit cu Infinispan, fiecare operațiune este replicată într-un nod secundar, ceea ce înseamnă că pierderea unui nod arbitrar poate fi tolerată fără pierdere date. De fapt, în codul sursă există un test care simulează chiar acest scenariu - pornește și oprește noduri în mod aleator în timp ce rulează motorul de potrivire.

Sursă pentru întregul sistem este disponibil pe GitHub sub licența liberă Apache 2. Structura sistemului poate fi văzută în schema de mai jos:

Clientul foloseşte datele capturate de la bursa Bitcoin MtGox pentru a crea comenzi (intenții de tranzacționare - cumpărare / vindere - la un anumit preț dat sau mai bun - așa-numitele "limit or better order"). Comenzile sunt transmise printr-o interfață HTTP / REST (implementat folosind Jersey) la unul din nodurile. Se demonstrează astfel interoperabilitatea cu alte sisteme non-Java, prin folosirea protocoalelor standard.

După ce o comandă este transmisă nodul corespunzător, acesta este plasat în cartea de comenzi (orderbook - lista ordonată a tuturor comenzilor), algoritmul de potrivire este rulat și toate tranzacțiile rezultate sunt stocate. Toate acestea se întâmplă într-un mod tranzacțional, ceea ce înseamnă că nu se stochează rezultate parțiale / inconsistente. Clientul comunică cu un singur nod la un moment dat și comută la nodul următor (fail-over) dacă se observă o eroare. Nu este implementat în acest proiect, dar putem adăuga cu ușurință o conexiune care primește date în timp real despre tranzacții folosind de exemplu protocolul WebSockets.

Cărțile de comenzi (orderbook) sunt serializate și deserializate într-un mod eficient pentru a fi sincronizate între nodurile primare și secundare utilizând faciliatatea de replicare delta din Infinispan prin care numai modificările (delta) sunt trimise print rețea . Acest lucru ne permite să păstrăm obiecte mari pentru o anumită cheie fără a sacrifica eficiența în timpul replicării. Practic putem separa problema modelării datelor (ce subset de date trebuie păstrate împreună) de problema plasării datelor.

Testul final repornește în mod aleator nodurile la fiecare câteva minute, fără ca acesta lucru să schimbe corectitudinea rezultatului.

Concluzii

Data-grid-urile sunt o soluție excelentă pentru sisteme care necesită performanță și fiabilitate ridicată. Proiectul prezentat în acest articol procesează cu un ordin de mărime mai multe date decât necesar în sistemele reale și poate fi integrat cu schimbări de cod minime. Face acest lucru într-un mod eficient, tolerând repornirea oricărui nod în timpul rulării.

LANSAREA NUMĂRULUI 149

Marți, 26 Octombrie, ora 18:00

sediul Cognizant

Facebook Meetup StreamEvent YouTube

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects