Come organizzare gli scambi di messaggi non critici tra server in più data center utilizzando Kafka (o altra soluzione)?

Question

Come organizzare gli scambi di messaggi non critici tra server in più data center utilizzando Kafka (o altra soluzione)?

#1 da (1 voti)

3

Abbiamo bisogno di organizzare un modo per scambiare messaggi tra server in più data center. I messaggi non sono critici. Dobbiamo solo essere in grado di inviare messaggi da qualsiasi server in qualsiasi data center a qualsiasi altro server in qualsiasi data center.

Stiamo pensando di utilizzare Kafka come broker di messaggi per questo caso d'uso, ma non siamo sicuri che sia una buona opzione.

Come abbiamo capito, Kafka non funzionerà normalmente se il cluster è distribuito tra più data center (perché deve funzionare con Zookeeper, che è più simile a una singola soluzione di data center). Pensiamo di utilizzare cluster separati in ogni data center. Ogni server deve avere una connessione a tutti i cluster Kafka in tutti i data center. Ecco perché qualsiasi server può inviare un messaggio a qualsiasi altro server in qualsiasi data center.

Quindi, ogni server avrà connessioni n . Il numero totale di tutte le connessioni sarà: n * m , dove n - è il numero totale di data center e m è il numero totale dei server.

È possibile ridurre il numero totale di connessioni a m ? Cioè che tutti i server sarebbero collegati solo ai cluster Kafka locali.

architecture enterprise-architecture message-queue message-passing apache-kafka

posta Alexandr 29.10.2017 - 22:54

fonte

1 risposta

Leggi altre domande sui tag architecture enterprise-architecture message-queue message-passing apache-kafka

REST Api Design Patterns Sviluppo API - Sinatra?

score 1 · Accepted Answer

Abbiamo deciso di utilizzare l'architettura simile all'architettura che ha proposto Todd Palino (Staff Site Reliability Engineer di LinkedIn). Cioè l'architettura che stanno usando in LinkedIn.

Abbiamo deciso di utilizzare un argomento unico per ogni server. Il nome dell'argomento deve avere un identificatore del data center e un identificativo del server (in quel data center).
Ad esempio, se disponiamo di 3 data center con 3 nodi in ciascun data center avremo prossimi argomenti:
DC1_1, DC1_2, DC1_3;
DC2_1, DC2_2, DC2_3;
DC3_1, DC3_2, DC3_3;

Gli stessi argomenti devono essere creati in tutti i cluster (nella nostra situazione 9 argomenti in ciascun cluster). MirrorMaker viene utilizzato in ogni data center per consumare i dati necessari per il cluster locale e produrre tali dati nel nostro cluster locale.

Quindi, i nostri cluster locali sono cluster aggregati allo stesso tempo e produciamo nei nostri cluster locali.
Abbiamo visto la presentazione di Todd Palino e ho detto qualcosa come "MAI produrre per aggregare i cluster" . Ma la sua spiegazione era che i dati prodotti non verranno replicati in altri cluster aggregati. Ma il fatto è che non replichiamo i dati locali (che sono consumati dai consumatori locali) in qualsiasi altro cluster. Solo i dati correlati al cluster locale vengono prodotti da cluster esterni nel cluster locale. Quindi, nella nostra situazione, è OK produrre in cluster aggregati.

L'esempio sopra può essere rappresentato dalla seguente architettura: Come vedi, i server API (sono i nostri produttori e consumatori) producono e consumano solo dai cluster locali di Kafka. Inoltre, ogni consumatore consuma solo dall'argomento che ha lo stesso identificatore di un identificatore del consumatore (ad esempio, il server API DC1_1 utilizzerà solo l'argomento DC1_1). Come puoi vedere, ogni MirrorMaker consuma dati solo per argomenti che devono essere consumati in un data center locale (ad esempio, in DC1 gli argomenti consumati saranno DC1_1, DC1_2, DC1_3). Questi argomenti (argomenti locali) non vengono replicati da altre istanze di MirrorMaker, quindi possiamo pubblicare e utilizzare questi argomenti nel nostro cluster locale. La memorizzazione dei dati per argomenti esterni può essere relativamente piccola (dipende dal tuo carico).