Come progettare archivio / messaggi master / slave e deduplicazione?

Question

Come progettare archivio / messaggi master / slave e deduplicazione?

#1 da (1 voti)

1

Per chiarire, poiché non sono del tutto sicuro di come riassumere nel titolo.

Ho un cluster redis e un programmatore redis-backed (simile a sidekiq / resque, ecc.)

Il mio cluster redis ha un master e un paio di slave. Inserisco un lavoro sul master e questo viene replicato sugli slave.

Ho 4 lavoratori che ascoltano questi schiavi.

Il problema: voglio che un lavoro venga raccolto una sola volta. Ma come è attualmente impostato è che un lavoro verrà replicato tra gli schiavi, che verrà poi prelevato da più lavoratori, duplicando il carico di lavoro.

Gradirei qualche suggerimento su come risolvere questo problema. Potrei usare le code specifiche dell'operatore e quindi pianificare un lavoro su una particolare coda. Ma questo continuerà a replicarsi tra schiavi e lavori di ricostruzione che non vengono mai raccolti e che dovranno essere eliminati.

Capisco che redis non sia costruito per questo tipo di passaggio di messaggi e forse qualcosa come rabbitmq sarebbe una soluzione migliore. Aperto a qualsiasi idea.

message-queue redis rabbitmq distributed-system

posta Damien Roche 17.04.2018 - 20:50

fonte

1 risposta

Leggi altre domande sui tag message-queue redis rabbitmq distributed-system

Come sincronizzare i dati tra due sistemi separati usando l'API di riposo? Come rappresentare / indirizzare il contenuto in tipi mime multipli / diversi / impilati?

score 1 · Answer 1

In che modo i tuoi lavoratori raccolgono il lavoro? I sondaggi sono redis o si iscrivono a un canale? Hai ragione che questo non è qualcosa per cui Redis è adatto. Il fatto che le sue garanzie di durata non siano così grandi dovrebbe anche darti qualcosa di cui preoccuparti se almeno una volta che consegna è qualcosa che ti interessa.

Per riferimento, i sistemi di archiviazione di messaggi su larga scala, come Kafka, adottano l'approccio di sharding. Occupano sicuramente un diverso spazio di progettazione, ma non si andrebbe in un territorio inesplorato seguendo questa strada. Avresti comunque altri problemi. Blocco della linea di testa, distribuzione non uniforme del lavoro, problemi con l'aggiunta o la rimozione di client ecc. Per finire, c'è ancora bisogno di un meccanismo per proteggersi dal lavoro duplicato. Questa è una best practice del tipo di sistemi distribuiti.