際際滷

際際滷Share a Scribd company logo

Redis si Resque

Download as PPT, PDF
Florin Oltean
Florin Oltean

Redis and Resque presentation at Cluj.rb File with Demo script: https://gist.github.com/florin555/5012229

1 of 48
Download to read offline
Redis si Resque pentru applicatii Rails concurente Florin Oltean Cluj.rb 2013-02-21
Despre mine Lucrez la ZenCash sincronizare cu servicii externe monitorizarea aplicatiei
Cuprins Redis Resque Cum folosim Redis si Resque in ZenCash
Redis si Resque
Redis key-value data store networked in-memory optional durability open-source (BSD license)
Calitati usor de folosit documentatie simpla si usor de inteles rapid (fiind in memorie)
Cum se foloseste redis-cli din Ruby: Redis gem
Tipuri de date Data structures server Tipul de baza: String Structuri de date: Lists Hashes Sets Sorted sets
comenzile sunt atomice ex: incr, decr lpush, lpop setnx
DEMO
Expire putem sa setam un expire pe orice cheie e important ca acea cheie sa existe
DEMO
Publish-Subscribe subscribe la mai multe cozi publish => primesc toti cei subscribed
DEMO
Tranzactii toate instructiunile sunt executate in ordine nu se ruleaza instructiuni primite de la alti clienti atomicitate: totul sau nimic
DEMO
Namespaces Gem redis-namespace
DEMO
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)
DEMO
Persistenta Fiind in memorie, toate datele se pierd daca moare procesul pana de curent (sau crapa sistemul de operare)
Persistenta Solutii: RDB point-in-time snapshots AOF (Append Only File)
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
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
Ar trebui folosite amandoua metodele pentru persistenta RDB mai bun decat AOF pentru disaster recovery pentru ca este mai compact
Resque
Resque cozi de lucru inspirat de DelayedJob foloseste Redis
Structura Resque librarie Ruby creare, interogare si procesare de joburi Rake task pentru pornirea de workeri aplicatie Sinatra pentru monitorizare cozi, joburi, workeri, errori
Workeri pot rula pe masini diferite nu au probleme de memory bloat / "leaks" arhitectura parent - child (fork)
Cozi sunt persistente complexitate O(1) push si pop atomic pot fi inspectate stocheaza joburile ca si packete JSON
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"]
Interfata web informatii despre workeri cozile folosite continutul cozilor statistici (ex. numar de job-uri procesate) urmarirea erorilor
Resque
Redis si Resque in ZenCash in ZenCash
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
In ZenCash folosim Redis pentru cozi de lucru (Resque) stocare temporara sincronizare procese
Resque comunicare cu third-party API trimitere de email taxare clienti joburi pentru monitorizare aplicatie generare statistici lansare sincronizare periodic procesare rezultate sincronizare
Stocare temporara
Sync Status Sincronizarea unei facturi Invoice Customer parsare adresa (daca e nevoie)
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
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
Monitorizare aplicatie Salvarea periodica a unor parametri Bounded Queue: coada cu dimensiune limitata implementata folosind Redis
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
Exemplu folosire RedisLock
Rate limitation Unele servicii au API usage limits Tinem o evidenta a requesturilor facute pentru un anumit user in ultimul minut
Referinte http://redis.io https://github.com/defunkt/resque
Contact @florin555 florin555@gmail.com
?

More Related Content

Redis si Resque

  • 1. Redis si Resque pentru applicatii Rails concurente Florin Oltean Cluj.rb 2013-02-21
  • 2. Despre mine Lucrez la ZenCash sincronizare cu servicii externe monitorizarea aplicatiei
  • 3. Cuprins Redis Resque Cum folosim Redis si Resque in ZenCash
  • 5. Redis key-value data store networked in-memory optional durability open-source (BSD license)
  • 6. Calitati usor de folosit documentatie simpla si usor de inteles rapid (fiind in memorie)
  • 7. Cum se foloseste redis-cli din Ruby: Redis gem
  • 8. Tipuri de date Data structures server Tipul de baza: String Structuri de date: Lists Hashes Sets Sorted sets
  • 9. comenzile sunt atomice ex: incr, decr lpush, lpop setnx
  • 10. DEMO
  • 11. Expire putem sa setam un expire pe orice cheie e important ca acea cheie sa existe
  • 12. DEMO
  • 13. Publish-Subscribe subscribe la mai multe cozi publish => primesc toti cei subscribed
  • 14. DEMO
  • 15. Tranzactii toate instructiunile sunt executate in ordine nu se ruleaza instructiuni primite de la alti clienti atomicitate: totul sau nimic
  • 16. DEMO
  • 18. DEMO
  • 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)
  • 20. DEMO
  • 21. Persistenta Fiind in memorie, toate datele se pierd daca moare procesul pana de curent (sau crapa sistemul de operare)
  • 22. Persistenta Solutii: RDB point-in-time snapshots AOF (Append Only File)
  • 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
  • 34. Redis si Resque in ZenCash in ZenCash
  • 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
  • 39. Sync Status Sincronizarea unei facturi Invoice Customer parsare adresa (daca e nevoie)
  • 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
  • 44. Exemplu folosire RedisLock
  • 45. Rate limitation Unele servicii au API usage limits Tinem o evidenta a requesturilor facute pentru un anumit user in ultimul minut
  • 46. Referinte http://redis.io https://github.com/defunkt/resque
  • 47. Contact @florin555 florin555@gmail.com
  • 48. ?

Editor's Notes

  • #6: - nu exista tabele sau relatii - server redis - totul e tinut in memorie -- spatiul bazei de date e limitat de RAM / swap
  • #25: 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