Poti pastra interfata dintre client si tine sincrona pina la un anumit
punct, iar in spate faci tot asincron. Important e ca partea sincrona sa
o faci cit mai light in asa fel incit sa-ti permiti sa tii un numar
foarte mare de clienti cu un request sincron in asteptare fara ca tu sa
blochezi prea multe resurse facind asta. Ceva de genul :
[client] -(sincron)-> [php1] ...(asincron)...>[php2 ]
|................[cache]
Clientul face requesturi sincrone catre un php1 care trebuie sa fie cit
mai eficient in asa fel incit chiar si cu un numar mare de requesturi
active sa ai impact foarte mic. Backendul asta verifica daca ai sau nu
rezultatul intr-un cache (care poate fi un sistem dedicat, iclusiv ceva
nosql in-memory daca vrei) iar daca nu-l gaseste submiteaza mai departe
requestul intr-o coada pentru backendul2, "heavy". Dupa care sta, cu
clientul initial agatat. Intrucit nu faci alta procesare memofaga in
php1, ar trebui sa poti tine un numar relativ mare de requesturi active
simultan. Dpdv al clientului, este in continuare o procesare sincrona.
Din momentul asta, php1 face polls (operatie relativ ieftina) in coada
sa vada daca i s-a rezolvat requestul de catre un backend.
In fine, in php2 preiei requesturi din coada si le procesezi intr-un
ritm ales de tine (nu mai mult de N in paralel, cu N stabilit in functie
de ce resurse ai la dispozitie). Pe masura ce requesturile sint
rezolvate, le marchezi in coada ca procesata si le pui rezultatul ce va
fi preluat de php1 si dat clientului.
In felul asta, poti si jongla mai usor cu un numar variabil de
backenduri levell1 sau level2 ca sa poti adauga/scoate dinamic in
functie de nevoi. (adica poti adauga in perioade de virf mai multe php2
ca sa-ti proceseze mai repede din coada de procesare)
Coada si cacheul pot fi entitati diferite sau pot reprezenta aceeasi
entitate.
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug
