Qual è la differenza tra Kafka e Redis OSS?
Redis OSS è 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 OSS 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 Messaggistica pub/sub di Redis OSS
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 OSS è 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 OSS per recuperare i messaggi.
Sebbene sia possibile utilizzare entrambi per la messaggistica pub/sub, Kafka e Redis OSS 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 Redis OSS
Redis OSS viene eseguito 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 OSS 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 OSS 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 OSS per ricevere messaggi. Questa è nota come semantica di distribuzione connessa.
Gestione dei messaggi nella messaggistica pub/sub Kafka e Messaggistica pub/sub di Redis OSS
Apache Kafka fornisce agli sviluppatori sistemi di messaggistica distribuita altamente scalabili. Viceversa, Redis OSS 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 OSS funzionano meglio quando inviano pacchetti di dati di piccole dimensioni tra consumatori e abbonati.
Redis OSS, in particolare, non è progettato per gestire dati di grandi dimensioni senza compromettere il throughput. 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 OSS invia automaticamente il messaggio agli abbonati connessi. Gli abbonati Redis OSS attendono passivamente i messaggi in arrivo indirizzati loro dal server. Trattandosi di una configurazione di consegna simultanea, gli abbonati Redis OSS 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 OSS non archivia i messaggi dopo che sono stati consegnati. Se nessun abbonato è connesso allo stream, Redis OSS scarta i messaggi. I messaggi scartati non possono essere recuperati anche se l'abbonato si connette a Redis OSS in un secondo momento.
Gestione degli errori
Sia Kafka sia Redis OSS consentono alle applicazioni di mitigare il recapito inaffidabile dei messaggi, ma lo fanno in modo diverso.
La gestione degli errori in Redis OSS si concentra sull'interazione tra l'applicazione client e i servizi Redis OSS. Con Redis OSS, 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 OSS 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 Messaggistica pub/sub di Redis OSS
Nel complesso, Apache Kafka supera Redis OSS nella messaggistica pub/sub perché Kafka è stato progettato specificamente per lo streaming di dati. Redis OSS 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 OSS 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 un throughput più elevato rispetto alla messaggistica pub/sub di Redis OSS. 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 OSS deve attendere il riconoscimento da parte di ciascun utente, il che riduce notevolmente il suo throughput 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 OSS sono adatti per l'elaborazione di dati a bassa latenza. Redis OSS offre un tempo di messaggistica inferiore, nell'ordine dei millisecondi, mentre Kafka ha una media di decine di millisecondi.
Considerando che Redis OSS legge e scrive dati principalmente sulla RAM, naturalmente supera Kafka in termini di velocità. Tuttavia, Redis OSS 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 OSS 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 OSS 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 OSS 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 OSS non esegue il backup dei dati per impostazione predefinita e gli utenti devono abilitare la funzionalità manualmente. Redis OSS utilizza un archivio dati in memoria, che perde tutti i dati quando viene spento. Per evitarlo, gli sviluppatori attivano la persistenza di Redis OSS Database (RDB) per acquisire periodicamente snapshot dei dati RAM e archiviarli su disco.
Quando utilizzare Kafka oppure Messaggistica pub/sub di Redis OSS
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 OSS 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 OSS 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
| Apache Kafka |
Redis OSS |
|
| 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 OSS 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 OSS 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. |
Throughput inferiore perché il server Redis OSS deve attendere una risposta prima di inviare un messaggio a un altro abbonato. |
| Latenza |
Bassa latenza. Leggermente più lento di Redis OSS 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 OSS manualmente. Rischio di perdita dei dati di piccole dimensioni. |
In che modo AWS può supportare i tuoi requisiti relativi a Kafka e Redis OSS?
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 Servizio gestito da Amazon per Apache Flink.
Utilizza Amazon MemoryDB per fornire archiviazione in memoria ad alta disponibilità per i tuoi carichi di lavoro Redis OSS. 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 OSS 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 OSS e Kafka su AWS creando un account oggi stesso.
