Qual è la differenza tra Kafka e Redis?
Redis è un archivio dati chiave-valore in memoria, mentre Apache Kafka è un motore di elaborazione dei flussi. Tuttavia, puoi confrontare le due tecnologie perché puoi utilizzarle entrambe per creare un sistema di messaggistica pubblicazione-abbonamento (pub/sub). Nella moderna architettura cloud, le applicazioni sono disaccoppiate in blocchi più piccoli e indipendenti chiamati servizi. La messaggistica pub/sub fornisce notifiche istantanee di eventi per questi sistemi distribuiti. Kafka supporta un sistema basato su pull in cui editori e abbonati condividono una coda di messaggi comune dalla quale gli abbonati estraggono i messaggi secondo necessità. Redis supporta un sistema basato su push in cui l'editore distribuisce messaggi a tutti gli abbonati quando si verifica un evento.
Come funzionano: Kafka e Redis per la messaggistica pub/sub
Apache Kafka è una piattaforma di streaming di eventi che consente a più applicazioni di trasmettere dati indipendentemente l'una dall'altra. Queste applicazioni, denominate produttori e consumatori, pubblicano e sottoscrivono informazioni da e verso determinate partizioni di dati chiamate argomenti.
D'altro canto, Redis è progettato come un database in memoria che supporta il trasferimento di dati a bassa latenza tra applicazioni. Per ridurre i tempi di lettura e scrittura dei dati, memorizza tutti i messaggi sulla RAM anziché su un disco rigido. Come Kafka, più consumatori possono abbonarsi a un flusso Redis per recuperare i messaggi.
Sebbene sia possibile utilizzare entrambi per la messaggistica pub/sub, Kafka e Redis funzionano in modo diverso.
Flusso di lavoro di Kafka
Apache Kafka collega produttori e consumatori tramite cluster di calcolo. Ogni cluster è composto da diversi broker Kafka che risiedono su server diversi.
Kafka crea argomenti e partizioni per i seguenti scopi:
- Argomenti per raggruppare dati simili appartenenti a un argomento di interesse, come e-mail, pagamenti, utenti e acquisti
- Partizioni di broker diversi per la replica dei dati e la tolleranza agli errori
I produttori pubblicano messaggi al broker. Quando il broker riceve un messaggio, classifica i dati in un argomento e li archivia in una partizione. I consumatori si connettono all'argomento pertinente ed estraggono i dati dalla partizione.
Flusso di lavoro di Redis
Redis funziona con un'architettura client-server come sistema di database NoSQL. Produttori e consumatori sono vagamente collegati e non è necessario che si conoscano per l'invio dei messaggi.
Redis utilizza chiavi e nodi primari-secondari per i seguenti scopi:
- Chiavi per raggruppare messaggi simili. Ad esempio, "email" è una chiave che punta all'archivio dati che contiene solo i messaggi di posta elettronica.
- Nodi primari-secondari per la replica dei messaggi.
Quando un produttore invia un messaggio a un nodo specifico, Redis lo recapita a tutti gli abbonati connessi controllando la chiave del messaggio. Il consumatore deve sempre avviare e mantenere una connessione attiva con il server Redis per ricevere messaggi. Questa è nota come semantica di distribuzione connessa.
Gestione dei messaggi nella messaggistica pub/sub Kafka e Redis
Apache Kafka fornisce agli sviluppatori sistemi di messaggistica distribuita altamente scalabili. Viceversa, Redis offre ricche strutture di dati che consentono a un'applicazione di inviare rapidamente i dati su più nodi. Entrambi i sistemi presentano diverse differenze nei meccanismi di accodamento dei messaggi.
Dimensioni del messaggio
Kafka e Redis funzionano meglio quando inviano pacchetti di dati di piccole dimensioni tra consumatori e abbonati.
Redis, in particolare, non è progettato per gestire dati di grandi dimensioni senza compromettere la velocità di trasmissione effettiva. Inoltre, non è in grado di archiviare grandi quantità di dati, poiché la RAM ha una capacità inferiore rispetto all'archiviazione su disco.
Viceversa, Kafka può supportare messaggi di dimensioni ragionevolmente grandi nonostante non sia stato creato appositamente per farlo. Kafka può gestire messaggi fino a 1 GB se comprime il messaggio e tu lo configuri per l'archiviazione su più livelli. Invece di archiviare tutti i messaggi nell'archiviazione locale, utilizza l'archiviazione remota per archiviare i file di log completati.
Recapito dei messaggi
I consumatori di Kafka estraggono i dati dalla coda di messaggi. Ogni utente di Kafka tiene traccia del messaggio che ha letto con un offset, che aggiorna per recuperare il messaggio successivo. I consumatori possono rilevare e tenere traccia dei messaggi duplicati.
D'altra parte, Redis invia automaticamente il messaggio agli abbonati connessi. Gli abbonati Redis attendono passivamente i messaggi in arrivo indirizzati loro dal server. Trattandosi di una configurazione di consegna simultanea, gli abbonati Redis non sono in grado di rilevare messaggi duplicati.
Conservazione dei messaggi
Kafka conserva i messaggi dopo che i consumatori li hanno letti. Pertanto, se un'applicazione client perde i dati recuperati, può richiederli nuovamente dalla partizione a cui è abbonata. Impostando la policy di conservazione dei messaggi, gli utenti possono determinare per quanto tempo Kafka conserva i dati.
Al contrario, Redis non archivia i messaggi dopo che sono stati consegnati. Se nessun abbonato è connesso allo stream, Redis scarta i messaggi. I messaggi scartati non possono essere recuperati anche se l'abbonato si connette a Redis in un secondo momento.
Gestione degli errori
Sia Kafka sia Redis consentono alle applicazioni di mitigare il recapito inaffidabile dei messaggi, ma lo fanno in modo diverso.
La gestione degli errori in Redis si concentra sull'interazione tra l'applicazione client e i servizi Redis. Con Redis, gli sviluppatori possono risolvere circostanze come i timeout del client, il superamento del buffer di memoria e i limiti massimi del client. A causa della sua architettura di database a coppie chiave-valore, Redis non è in grado di fornire una solida gestione degli errori dei messaggi come Kafka.
Gli sviluppatori di Kafka possono archiviare gli eventi errati in una coda DLQ, riprovare o reindirizzarli per consentire una consegna coerente dei messaggi alle applicazioni client. Gli sviluppatori possono anche utilizzare l'API Kafka Connect per riavviare automaticamente le attività del connettore in caso di determinati errori.
Differenze di prestazioni nella messaggistica pub/sub Kafka e Redis
Nel complesso, Apache Kafka supera Redis nella messaggistica pub/sub perché Kafka è stato progettato specificamente per lo streaming di dati. Redis ha diversi casi d'uso per i quali Kafka non è adatto.
Parallelismo
Il parallelismo è la capacità di più utenti di ricevere lo stesso messaggio contemporaneamente.
Redis non supporta il parallelismo.
D'altra parte, Kafka consente di distribuire lo stesso messaggio a più consumatori simultaneamente. Di solito, i consumatori dei gruppi di consumatori di Kafka recuperano a turno nuovi messaggi da una partizione. Se c'è un solo consumatore in più gruppi di consumatori, recupera tutti i messaggi. Sfruttando questa configurazione e la replica delle partizioni, è possibile assegnare un consumatore a ciascun gruppo di consumatori in ogni replica della partizione. Ciò consente a tutti gli utenti di recuperare una sequenza di messaggi simile.
Velocità di trasmissione effettiva
La velocità di trasmissione effettiva misura il numero di messaggi che ogni sistema può elaborare al secondo.
Kafka ha generalmente una velocità di trasmissione effettiva più elevata rispetto alla messaggistica pub/sub di Redis. Kafka è in grado di gestire volumi di dati molto più elevati poiché non è necessario attendere che ogni abbonato riceva il messaggio prima di passare al successivo. Al contrario, i messaggi vengono memorizzati in una cache di memoria e uno spazio di archiviazione, ottimizzando così la velocità di lettura.
Tuttavia, le prestazioni di Kafka potrebbero diminuire se gli utenti non recuperano il messaggio abbastanza velocemente, poiché i messaggi non letti dalla cache a un certo punto vengono rimossi. In questo caso, gli utenti devono leggere dal disco, che è più lento.
Viceversa, Redis deve attendere il riconoscimento da parte di ciascun utente, il che riduce notevolmente la sua velocità di trasmissione effettiva con più nodi connessi. Una soluzione alternativa consiste nell'inviare più richieste con un processo chiamato pipelining, ma ciò riduce la latenza della messaggistica.
Latenza
Sia Kafka sia Redis sono adatti per l'elaborazione di dati a bassa latenza. Redis offre un tempo di messaggistica inferiore, nell'ordine dei millisecondi, mentre Kafka ha una media di decine di millisecondi.
Considerando che Redis legge e scrive dati principalmente sulla RAM, naturalmente supera Kafka in termini di velocità. Tuttavia, Redis potrebbe non essere in grado di mantenere le operazioni sui dati alla latenza minima quando deve gestire messaggi di grandi dimensioni. Viceversa, Kafka ha bisogno di più tempo per replicare le partizioni su diverse unità fisiche per la persistenza dei dati, il che aggiunge un sovraccarico ai tempi di consegna dei messaggi.
È possibile ottimizzare la latenza di Redis e Kafka, ma occorre procedere con cautela. Ad esempio, è possibile comprimere i messaggi di Kafka per ridurre la latenza, ma produttori e consumatori hanno bisogno di più tempo per decomprimerli.
La latenza in Redis potrebbe essere causata da diversi fattori, tra cui l'ambiente operativo, le operazioni di rete, la lentezza dei comandi o il forking. Per ridurre i ritardi dovuti al forking, Redis consiglia di eseguire il sistema di distribuzione pub/sub su moderne istanze EC2 basate su una macchina virtuale hardware (HVM).
Tolleranza ai guasti
Kafka scrive tutti i dati sul disco di archiviazione di un broker principale e li replica su diversi server. Quando un server si guasta, più abbonati recuperano i dati dalle partizioni di backup.
A differenza di Kafka, Redis non esegue il backup dei dati per impostazione predefinita e gli utenti devono abilitare la funzionalità manualmente. Redis utilizza un archivio dati in memoria, che perde tutti i dati quando viene spento. Per evitarlo, gli sviluppatori attivano la persistenza di Redis Database (RDB) per acquisire periodicamente snapshot dei dati RAM e archiviarli su disco.
Quando utilizzare Kafka oppure Redis per la messaggistica pub/sub
Apache Kafka è la scelta migliore per creare applicazioni che trasmettono in streaming set di dati di grandi dimensioni e richiedono un'elevata ripristinabilità. Inizialmente è stato sviluppato come un'unica pipeline di dati distribuita in grado di gestire migliaia di miliardi di messaggi in transito. Kafka replica le partizioni su diversi server per prevenire la perdita di dati in caso di guasto di un nodo. Le organizzazioni utilizzano Kafka per supportare la comunicazione in tempo reale tra applicazioni, dispositivi mobili per l'Internet delle cose (IoT) e microservizi. È anche la scelta migliore per l'aggregazione dei log, l'elaborazione dei flussi e altre attività di integrazione dei dati basate sul cloud.
D'altro canto, Redis fornisce una distribuzione di eventi a latenza minima per le applicazioni che richiedono il trasferimento istantaneo dei dati ma tollerano piccole perdite di dati. Redis viene comunemente utilizzato come cache di sessione per archiviare dati a cui si accede di frequente o inviare messaggi urgenti. È adatto anche per archiviare dati di giochi, e-commerce o social media per consentire un'esperienza utente più fluida.
Riepilogo delle differenze tra Kafka e Redis per la messaggistica pub/sub
| Apache Kafka |
Redis |
|
| Dimensioni del messaggio |
Supporta messaggi di dimensioni fino a 1 GB con compressione e archiviazione su più livelli. |
Supporta messaggi di dimensioni inferiori. |
| Recapito dei messaggi |
Gli abbonati estraggono i messaggi dalla coda. |
Il server Redis invia messaggi agli abbonati connessi. |
| Conservazione dei messaggi |
Conserva i messaggi dopo il recupero. |
Non conserva i messaggi. |
| Gestione degli errori |
Solida gestione degli errori a livello di messaggistica. Coda DLQ, nuovo tentativo di evento e reindirizzamento. |
È necessario gestire le eccezioni Redis a livello di applicazione con timeout, limiti client e capacità del buffer di memoria. |
| Parallelismo |
Kafka sostiene il parallelismo. Più utenti possono recuperare lo stesso messaggio simultaneamente. |
Non supporta il parallelismo. |
| Prestazioni |
Ha una velocità di trasmissione effettiva più elevata grazie alla lettura/scrittura asincrona. |
Velocità di trasmissione effettiva inferiore perché il server Redis deve attendere una risposta prima di inviare un messaggio a un altro abbonato. |
| Latenza |
Bassa latenza. Leggermente più lento di Redis a causa della replica dei dati per impostazione predefinita. |
Latenza minima per la distribuzione di messaggi di piccole dimensioni. |
| Tolleranza ai guasti |
Esegue automaticamente il backup delle partizioni su diversi broker. |
Non esegue il backup per impostazione predefinita. Gli utenti possono abilitare la persistenza di Redis manualmente. Rischio di perdita dei dati di piccole dimensioni. |
In che modo AWS può supportare i tuoi requisiti relativi a Kafka e Redis?
Amazon Web Services (AWS) fornisce un'infrastruttura scalabile e gestita per supportare le tue esigenze di messaggistica pubblicazione-abbonamento (pub/sub).
Utilizza Streaming gestito da Amazon per Apache Kafka (Amazon MSK) per importare ed elaborare facilmente grandi volumi di dati in tempo reale. È possibile creare un bus dati ad accesso privato per fornire nodi di streaming ad alta disponibilità su larga scala. Puoi anche connetterti senza problemi con altri servizi AWS come AWS IoT Core, Amazon Virtual Private Cloud (Amazon VPC) e Analisi dei dati Amazon Kinesis.
Utilizza Amazon MemoryDB per Redis per fornire archiviazione in memoria ad alta disponibilità per i tuoi carichi di lavoro Redis. Puoi eseguire feed di dati in streaming ad alta simultaneità per importare l'attività degli utenti. Inoltre, puoi supportare milioni di richieste al giorno per applicazioni multimediali e di intrattenimento.
Invece di Redis o Kafka, puoi anche utilizzare Amazon Simple Notification Service (Amazon SNS) per creare un sistema di messaggistica pub/sub. Puoi inviare messaggi direttamente dalle tue applicazioni ai clienti o ad altre applicazioni in modo scalabile ed economico. Amazon SNS offre diverse funzionalità, come:
- Messaggistica con velocità di trasmissione effettiva elevata, basata su push e molti a molti tra sistemi distribuiti, microservizi e applicazioni serverless basate su eventi.
- Crittografia dei messaggi e privacy del traffico.
- Funzionalità Fanout in tutte le categorie AWS. Ciò include analisi, calcolo, container, database, Internet delle cose (IoT), machine learning (ML), sicurezza e archiviazione.
Inizia a utilizzare la messaggistica pub/sub, Redis e Kafka su AWS creando un account oggi stesso.
