ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

Redis - Non solo cache

•
•
Luigi Fugaro
Luigi Fugaro

Webinar - https://redis.com/webinars-on-demand/redis-non-solo-cache/ Redis è il sistema di caching più utilizzato e conosciuto, sia a livello community, che in ambito enterprise. Tuttavia i suoi utilizzi non si limitano alla sola cache. In questo webinar, vedremo come disegnare architetture per sistemi di code, messaging e event-stream. Inoltre, parte della presentazione sarà dedicata ad una demo che evidenzia step-by-step come implementare Redis per le event-driven-architecture, prendendo spunto da un caso d'uso specifico.

1 of 39
Redis Non solo cache Luigi Fugaro - Solutions Architect @Redis Italia Settembre 2021
2 Alberto Fidanza Redis Italia Regional Sales Manager alberto.fidanza@redis.com Luigi Fugaro Solutions Architect luigi.fugaro@redis.com Stefano Fattore Sales Development Representative stefano.fattore@redis.com
• Redis, dalle origini ad oggi • Strategie di caching • Non solo cache • Demo • ... 3 Agenda
4 Redis, dalle origini ad oggi
In-Memory Multi-Model Database basato su Redis open source con funzionalità di livello Enterprise per architetture di livello Enterprise Open Source In-Memory Data Store supportare una varietà di strutture dati e modelli dati ottimizzati per casi d'uso di real-time e high-throughput 5 Profonde radici Open Source e siciliane
Sinceramente è una gran cosa 6 Redis, sinonimo di cache Da una ricerca di Docker Hub del 2020 5.4 milioni di lanci al giorno Da una ricerca di Datadog Inc. del 2020 Top 10 Kubernetes StatefulSets
7 Strategie di caching
Esistono vari Caching Patterns, tra cui: • Cache-aside (Lazy-loading) • Read-Through • Write-Through • Write-Behind (Write-Back) • Read-replica 8 Strategie di caching
Questo è il modo più comune per utilizzare Redis come cache. In questa strategia, l'applicazione esamina prima la cache per recuperare i dati. Se i dati non vengono trovati (cache miss), l'applicazione recupera i dati direttamente dal database sorgente. I dati vengono caricati nella cache solo quando necessario (motivo per cui il metodo viene indicato anche come caricamento pigro). Le applicazioni che effettuano molte letture possono trarre grandi vantaggi dall'implementazione del cache-aside. Cache-aside (Lazy-loading) 9 Strategie di caching
A differenza del Cache-aside, con questa strategia, l'applicazione esamina prima la cache per recuperare i dati. Se i dati non vengono trovati (cache miss), il cache provider recupera i dati direttamente dal database sorgente tramite moduli ad-hoc, come ad esempio RedisGears. Con questa strategia l’applicazione si interfaccia solo ed esclusivamente con il cache provider, beneficiando di aspetti quali pulizia e mantenimento del codice. Read-Through (Smart-loading) 10 Strategie di caching
In questa strategia, l’applicazione scrive simultaneamente i dati nella cache e nel database sorgente. Le scritture sono sincrone e sullo stesso thread applicativo, favorendo la coerenza dei dati tra la cache e il database sorgente. Questa strategia è molto adatta ad applicazioni che eseguono poche scritture ed è spesso impiegata insieme a quella del Read-Through. Write-Through 11 Strategie di caching
In questa strategia, i dati vengono prima scritti nella cache (ad esempio, Redis), quindi i dati vengono aggiornati in modo asincrono nel database sorgente. Questo approccio migliora le prestazioni di scrittura e facilita lo sviluppo dell'applicazione, poiché lo sviluppatore scrive solo da una parte (Redis). RedisGears fornisce funzionalità sia di write-through che write-behind. Write-Behind (Write-Back) 12 Strategie di caching
In un ambiente in cui si dispone di una grande quantità di dati storici (ad esempio un mainframe) o si richiede che ogni scrittura debba essere registrata sul database sorgente, i connettori Redis Enterprise Change Data Capture (CDC) permettono di acquisire singole modifiche ai dati e propagare copie esatte senza interrompere le operazioni in corso con una coerenza quasi in tempo reale. CDC permette di recuperare informazioni preziose sui dati che fino ad ora erano poco visibili o del tutto invisibili. Read-replica 13 Strategie di caching
14 Hashes Bitmaps Strings Bit field Streams Hyperloglog Sorted Sets Sets Geospatial Redis Core Redis Modules Linear Scalability HA Geo-Distribution Durability Backup & Restore Tiered-Memory Access Security Redis Enterprise Lists Multi-Tenant Data Structures BloomFilter Search Graph TimeSeries AI JSON Gears Strategie di caching
15 Non solo cache
L'architettura guidata dagli eventi (EDA) è un paradigma di architettura software che promuove la produzione, il rilevamento, il consumo e la reazione agli eventi. Un evento può essere definito come "un cambiamento significativo di stato". Questo modello architetturale può essere applicato dalla progettazione e implementazione di applicazioni e sistemi che trasmettono eventi tra componenti e servizi software indipendenti. Un sistema basato su eventi è generalmente costituito da emettitori di eventi (o agenti), consumatori di eventi (o sink) e canali di eventi. Principalmente esistono due modelli di riferimento per le architetture orientate agli eventi: • Message Processing • Stream Processing 16 Architettura orientata ad eventi (in inglese Event Driven)
Stream Processing Lo Stream Processing (anche detto modello event stream) consiste nel annotare gli eventi in un registro (stream). I consumer non effettuano la sottoscrizione a un flusso di eventi, ma possono leggere ogni parte del flusso e partecipare in qualsiasi momento. Nello stream processing più componenti possono reagire a più eventi nello stesso momento e fare operazioni su più flussi ed eventi. Message Processing Il Message Processing (anche detto modello pub/sub) consiste in un'infrastruttura di messaggistica che si basa su sottoscrizioni a un flusso di eventi. Con questo modello, al suo verificarsi o in seguito alla sua pubblicazione, l'evento viene inviato ai sottoscrittori che devono essere informati. 17 Architettura orientata ad eventi
Redis permette di scegliere diversi livelli di persistenza, a seconda del caso d’uso che si intende implementare. RDB (Redis Database) La persistenza RDB esegue snapshot ad intervalli di tempo predefiniti, di tutto ciò che è contenuto in quel momento in memoria. Questo tipo di approccio è molto utile come backup & recovery. AOF (Append Only File) La persistenza AOF registra ogni operazione di scrittura ricevuta dal server, che verrà riprodotta nuovamente all'avvio del server, ricostruendo il dataset originale. I comandi vengono registrati utilizzando lo stesso formato del protocollo Redis stesso, in modalità di sola aggiunta. RDB + AOF È possibile combinare sia AOF che RDB nella stessa istanza. Si noti che, in questo caso, al riavvio di Redis il file AOF verrà utilizzato per ricostruire il set di dati originale poiché è garantito che sarà il più completo. Inoltre, è possibile sfruttare RDB e AOF contemporaneamente, per ottimizzare i tempi di caricamento e le dimensioni del file AOF. Ad ogni snapshot RDB, il file AOF viene ottimizzato per ripartire dal momento successivo dello snapshot RDB. 18 Persistenza in Redis
I messaggi sono inviati attraverso il modello pub/sub nativo di Redis 19 Modello pub/sub Publisher Subscriber PUBLISH SUBSCRIBE Subscriber CHANNEL
Gli eventi o messaggi vengono inseriti in una struttura di dati simile ad un append only file che garantisce l’ordinamento dei degli eventi/messaggi in base al tempo. 20 Modello Streams Producer Consumer XADD XREAD Consumer Consumer XREAD XREAD
In alternativa è possibile usare le strutture dati core di Redis come LIST e SORTED SET 21 Sistema di code (in inglese Queues) Producer Consumer LPUSH RPOP Producer Consumer ZADD ZPOPMAX
22 Architettura orientata ad eventi… secondo Redis Producer Consumer 1 Consumer 2 Consumer 3 Consumer n Commands Producer: LPUSH <list name> <message> Consumer: RPOP <list name> <timeout> Producer Consumer 1 Consumer 2 Consumer 3 Consumer n Commands Producer: ZADD <sorted set name> <score> <message> Consumer: ZPOPMAX <sorted set name> <count> Reader: ZRANGEBYSCORE <sorted set name> <score range> WITHSCORES Publisher Subscriber a Subscriber b Subscriber c Subscriber x Commands Publisher: PUBLISH <channel name> <message> Subscriber: SUBSCRIBE <channel name> Consumer a Consumer x Producer 1 Producer 2 Producer 3 Producer n Consumer j Consumer n Consumer groups Consumers Commands Producer: XADD Consumer Group: XREAD Consumer Groups: XREADGROUP XACK
23 Demo https://github.com/foogaro/redis-workshop
24 La squadra
• Produrre risultati! • Produrre risultati eccellenti! • Più si producono risultati, meglio è! • Più risultati si producono, maggiori i profitti! 25 I requisiti
26 EUREKA!
27 L’algoritmo Math.random() A.I.
28 Legacy
Micro service Monolith 29 Il software
Micro service 30 Il software
Micro service 31 Architettura
Micro service 32 Architettura
Micro service 33 Architettura Publisher Subscriber Messages
Micro service 34 Architettura Producer Consumer Events
35 Riepilogo
• Non solo cache • Persistenza • Sistema di messaggi • Sistema a code • Stream di eventi https://redis.com/webinars-on-demand/redis-non-solo-cache/ 36 Riepilogo
37 Prossimo webinar
L’architettura di Redis • Redis in alta affidabilità • Redis failover • Redis fault tolerance 38 Prossimo webinar
Grazie!

More Related Content

Redis - Non solo cache

  • 1. Redis Non solo cache Luigi Fugaro - Solutions Architect @Redis Italia Settembre 2021
  • 2. 2 Alberto Fidanza Redis Italia Regional Sales Manager alberto.fidanza@redis.com Luigi Fugaro Solutions Architect luigi.fugaro@redis.com Stefano Fattore Sales Development Representative stefano.fattore@redis.com
  • 3. • Redis, dalle origini ad oggi • Strategie di caching • Non solo cache • Demo • ... 3 Agenda
  • 5. In-Memory Multi-Model Database basato su Redis open source con funzionalità di livello Enterprise per architetture di livello Enterprise Open Source In-Memory Data Store supportare una varietà di strutture dati e modelli dati ottimizzati per casi d'uso di real-time e high-throughput 5 Profonde radici Open Source e siciliane
  • 6. Sinceramente è una gran cosa 6 Redis, sinonimo di cache Da una ricerca di Docker Hub del 2020 5.4 milioni di lanci al giorno Da una ricerca di Datadog Inc. del 2020 Top 10 Kubernetes StatefulSets
  • 8. Esistono vari Caching Patterns, tra cui: • Cache-aside (Lazy-loading) • Read-Through • Write-Through • Write-Behind (Write-Back) • Read-replica 8 Strategie di caching
  • 9. Questo è il modo più comune per utilizzare Redis come cache. In questa strategia, l'applicazione esamina prima la cache per recuperare i dati. Se i dati non vengono trovati (cache miss), l'applicazione recupera i dati direttamente dal database sorgente. I dati vengono caricati nella cache solo quando necessario (motivo per cui il metodo viene indicato anche come caricamento pigro). Le applicazioni che effettuano molte letture possono trarre grandi vantaggi dall'implementazione del cache-aside. Cache-aside (Lazy-loading) 9 Strategie di caching
  • 10. A differenza del Cache-aside, con questa strategia, l'applicazione esamina prima la cache per recuperare i dati. Se i dati non vengono trovati (cache miss), il cache provider recupera i dati direttamente dal database sorgente tramite moduli ad-hoc, come ad esempio RedisGears. Con questa strategia l’applicazione si interfaccia solo ed esclusivamente con il cache provider, beneficiando di aspetti quali pulizia e mantenimento del codice. Read-Through (Smart-loading) 10 Strategie di caching
  • 11. In questa strategia, l’applicazione scrive simultaneamente i dati nella cache e nel database sorgente. Le scritture sono sincrone e sullo stesso thread applicativo, favorendo la coerenza dei dati tra la cache e il database sorgente. Questa strategia è molto adatta ad applicazioni che eseguono poche scritture ed è spesso impiegata insieme a quella del Read-Through. Write-Through 11 Strategie di caching
  • 12. In questa strategia, i dati vengono prima scritti nella cache (ad esempio, Redis), quindi i dati vengono aggiornati in modo asincrono nel database sorgente. Questo approccio migliora le prestazioni di scrittura e facilita lo sviluppo dell'applicazione, poiché lo sviluppatore scrive solo da una parte (Redis). RedisGears fornisce funzionalità sia di write-through che write-behind. Write-Behind (Write-Back) 12 Strategie di caching
  • 13. In un ambiente in cui si dispone di una grande quantità di dati storici (ad esempio un mainframe) o si richiede che ogni scrittura debba essere registrata sul database sorgente, i connettori Redis Enterprise Change Data Capture (CDC) permettono di acquisire singole modifiche ai dati e propagare copie esatte senza interrompere le operazioni in corso con una coerenza quasi in tempo reale. CDC permette di recuperare informazioni preziose sui dati che fino ad ora erano poco visibili o del tutto invisibili. Read-replica 13 Strategie di caching
  • 14. 14 Hashes Bitmaps Strings Bit field Streams Hyperloglog Sorted Sets Sets Geospatial Redis Core Redis Modules Linear Scalability HA Geo-Distribution Durability Backup & Restore Tiered-Memory Access Security Redis Enterprise Lists Multi-Tenant Data Structures BloomFilter Search Graph TimeSeries AI JSON Gears Strategie di caching
  • 16. L'architettura guidata dagli eventi (EDA) è un paradigma di architettura software che promuove la produzione, il rilevamento, il consumo e la reazione agli eventi. Un evento può essere definito come "un cambiamento significativo di stato". Questo modello architetturale può essere applicato dalla progettazione e implementazione di applicazioni e sistemi che trasmettono eventi tra componenti e servizi software indipendenti. Un sistema basato su eventi è generalmente costituito da emettitori di eventi (o agenti), consumatori di eventi (o sink) e canali di eventi. Principalmente esistono due modelli di riferimento per le architetture orientate agli eventi: • Message Processing • Stream Processing 16 Architettura orientata ad eventi (in inglese Event Driven)
  • 17. Stream Processing Lo Stream Processing (anche detto modello event stream) consiste nel annotare gli eventi in un registro (stream). I consumer non effettuano la sottoscrizione a un flusso di eventi, ma possono leggere ogni parte del flusso e partecipare in qualsiasi momento. Nello stream processing più componenti possono reagire a più eventi nello stesso momento e fare operazioni su più flussi ed eventi. Message Processing Il Message Processing (anche detto modello pub/sub) consiste in un'infrastruttura di messaggistica che si basa su sottoscrizioni a un flusso di eventi. Con questo modello, al suo verificarsi o in seguito alla sua pubblicazione, l'evento viene inviato ai sottoscrittori che devono essere informati. 17 Architettura orientata ad eventi
  • 18. Redis permette di scegliere diversi livelli di persistenza, a seconda del caso d’uso che si intende implementare. RDB (Redis Database) La persistenza RDB esegue snapshot ad intervalli di tempo predefiniti, di tutto ciò che è contenuto in quel momento in memoria. Questo tipo di approccio è molto utile come backup & recovery. AOF (Append Only File) La persistenza AOF registra ogni operazione di scrittura ricevuta dal server, che verrà riprodotta nuovamente all'avvio del server, ricostruendo il dataset originale. I comandi vengono registrati utilizzando lo stesso formato del protocollo Redis stesso, in modalità di sola aggiunta. RDB + AOF È possibile combinare sia AOF che RDB nella stessa istanza. Si noti che, in questo caso, al riavvio di Redis il file AOF verrà utilizzato per ricostruire il set di dati originale poiché è garantito che sarà il più completo. Inoltre, è possibile sfruttare RDB e AOF contemporaneamente, per ottimizzare i tempi di caricamento e le dimensioni del file AOF. Ad ogni snapshot RDB, il file AOF viene ottimizzato per ripartire dal momento successivo dello snapshot RDB. 18 Persistenza in Redis
  • 19. I messaggi sono inviati attraverso il modello pub/sub nativo di Redis 19 Modello pub/sub Publisher Subscriber PUBLISH SUBSCRIBE Subscriber CHANNEL
  • 20. Gli eventi o messaggi vengono inseriti in una struttura di dati simile ad un append only file che garantisce l’ordinamento dei degli eventi/messaggi in base al tempo. 20 Modello Streams Producer Consumer XADD XREAD Consumer Consumer XREAD XREAD
  • 21. In alternativa è possibile usare le strutture dati core di Redis come LIST e SORTED SET 21 Sistema di code (in inglese Queues) Producer Consumer LPUSH RPOP Producer Consumer ZADD ZPOPMAX
  • 22. 22 Architettura orientata ad eventi… secondo Redis Producer Consumer 1 Consumer 2 Consumer 3 Consumer n Commands Producer: LPUSH <list name> <message> Consumer: RPOP <list name> <timeout> Producer Consumer 1 Consumer 2 Consumer 3 Consumer n Commands Producer: ZADD <sorted set name> <score> <message> Consumer: ZPOPMAX <sorted set name> <count> Reader: ZRANGEBYSCORE <sorted set name> <score range> WITHSCORES Publisher Subscriber a Subscriber b Subscriber c Subscriber x Commands Publisher: PUBLISH <channel name> <message> Subscriber: SUBSCRIBE <channel name> Consumer a Consumer x Producer 1 Producer 2 Producer 3 Producer n Consumer j Consumer n Consumer groups Consumers Commands Producer: XADD Consumer Group: XREAD Consumer Groups: XREADGROUP XACK
  • 25. • Produrre risultati! • Produrre risultati eccellenti! • Più si producono risultati, meglio è! • Più risultati si producono, maggiori i profitti! 25 I requisiti
  • 36. • Non solo cache • Persistenza • Sistema di messaggi • Sistema a code • Stream di eventi https://redis.com/webinars-on-demand/redis-non-solo-cache/ 36 Riepilogo
  • 38. L’architettura di Redis • Redis in alta affidabilità • Redis failover • Redis fault tolerance 38 Prossimo webinar