Redis si Resque

551 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
551
On SlideShare
0
From Embeds
0
Number of Embeds
159
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • - 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
  • Redis si Resque

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

    ×