Redis si Resque

transcript

Redis si Resquepentru applicatii Rails concurente

Florin OlteanCluj.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

• 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

Expire

• putem sa setam un “expire” pe orice cheie

• e important ca acea cheie sa existe

Publish-Subscribe

• subscribe la mai multe cozi

• publish => primesc toti cei subscribed

Tranzactii

• toate instructiunile sunt executate in ordine

• nu se ruleaza instructiuni primite de la alti clienti

• atomicitate: totul sau nimic

Namespaces

• Gem redis-namespace

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)

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

• 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)

• 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 Resquein ZenCashin 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

• comunicare cu third-party API

• trimitere de email

• taxare clienti

• joburi pentru

• monitorizare aplicatie

• generare statistici

• lansare sincronizare periodic

• procesare rezultate sincronizare

Resque

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

Redis si Resque

Technology