19. Pipelining
• la comunicare prin TCP, round-trip time
mare comparat cu durata unei instructiuni
• ~1ms prin loopback
• ~100 ms prin Internet
• Solutie: sa folosim pipelining
• Pentru si mai multa viteza: comanda eval
pentru a rula Lua scripts (doar din v2.6)
23. Persistenta
• RDB point-in-time snapshots
• util pentru backup
• fork => fisier scris de procesul fiu
• copy-on-write
• poate bloca procesul pana la 1 secunda
• cele mai recente date se pot pierde
24. Persistenta
• AOF (Append Only File)
• foloseste write(2) si fsync(2)
• fsync: no / every second / every query
• fisier mai mare decat RDB
• scade putin performanta
• rescris automat cand creste prea mult
• tot folosind fork
25. • Ar trebui folosite amandoua metodele
pentru persistenta
• RDB mai bun decat AOF pentru disaster
recovery pentru ca este mai compact
27. Resque
• cozi de lucru
• inspirat de DelayedJob
• foloseste Redis
28. Structura Resque
• librarie Ruby
• creare, interogare si procesare de joburi
• Rake task pentru pornirea de workeri
• aplicatie Sinatra pentru monitorizare
• cozi, joburi, workeri, errori
29. Workeri
• pot rula pe masini diferite
• nu au probleme de memory bloat / "leaks"
• arhitectura parent - child (fork)
30. Cozi
• sunt persistente
• complexitate O(1)
• push si pop atomic
• pot fi inspectate
• stocheaza joburile ca si packete JSON
31. De tinut cont
• sa avem grija la ce trimitem ca parametri
• id in loc de obiect intreg
• avantaj: obiect up-to-date
• dezavantaj: poate inca nu se vad schimbarile
• schimbare symbol in string (JSON)
• [:a, :b] se transforma in ["a", "b"]
32. Interfata web
• informatii despre workeri
• cozile folosite
• continutul cozilor
• statistici (ex. numar de job-uri procesate)
• urmarirea erorilor
35. ZenCash
• Te ajuta sa fii platit mai repede
• Integrare cu 8 aplicatii de facturare
• import: Invoices, Payments, Customers
• Sincronizare:
• o data pe ora
• on-demand
36. • In ZenCash folosim Redis pentru
• cozi de lucru (Resque)
• stocare temporara
• sincronizare procese
37. Resque
• comunicare cu third-party API
• trimitere de email
• taxare clienti
• joburi pentru
• monitorizare aplicatie
• generare statistici
• lansare sincronizare periodic
• procesare rezultate sincronizare
40. DB-less SyncApp
• pentru un sync pot fi necesare mai multe
request-uri (ex. paginare)
• se faceau serializari / deserializari in plus
• am renuntat la MySQL
41. Temporary file store
• scenariu:
• un proces face download de PDF
• alt proces face upload pe S3
• procesele trebuie sa fie pe aceeasi masina
ca sa poata accesa fisierul de pe disc
• solutie: stocarea fisierului in Redis
42. Monitorizare aplicatie
• Salvarea periodica a unor parametri
• Bounded Queue:
• coada cu dimensiune limitata
implementata folosind Redis
43. Sincronizare procese
• Redis Lock
• poate fi folosit pentru a ne asigura ca un
singur proces executa o bucata de cod
pentru o anumita resursa
• ex: procesare rezultate sincronizare
- nu exista tabele sau relatii - server redis - totul e tinut in memorie -- spatiul bazei de date e limitat de RAM / swap
Rescriere AOF - fiul scrie din memorie un AOF - parintele functioneaza in continuare la fel + adauga intr-un buffer commenzile noi - fiul trimite parintelui un semnal cand a terminat - parintele scrie din buffer - redenumeste atomic fisierul