Architettare un sistema di elaborazione file distribuito con l'elezione dei dirigenti

2

Sono in fase di pianificazione del tentativo di creare un sistema di elaborazione file distribuito in Java e sto cercando feedback e consigli:

Problema : esiste un numero elevato di file pubblicati continuamente su un server FTP che dobbiamo catturare, elaborare e trasmettere.

Idea soluzione : un nodo master cercherà nuovi file su un server FTP e assegnerà il lavoro di elaborazione ai nodi figlio. Il nodo principale invierà al figlio un messaggio JMS che gli dirà quale file elaborare e il bambino invierà una risposta quando sarà terminato e chiederà più lavoro.

Se il nodo master scende per qualche motivo, uno dei nodi figlio dovrebbe presumere il ruolo di maestro. La mia idea per l'implementazione di questo è stata quella di avere una collezione "lock" in un MongoDB che contenga informazioni sul nodo master, oltre a un tempo di scadenza del blocco. Ogni 15 secondi circa il nodo master aggiornerà il blocco e aggiornerà il tempo di scadenza a 30 secondi in futuro. Se i nodi figli vedono che il blocco è scaduto, uno di questi si assegnerà come nodo principale.

Sto cercando feedback su questo progetto e mi chiedo se qualcuno ha consigli su miglioramenti / framework java o strumenti già esistenti che posso sfruttare per qualcosa di simile.

Grazie!

    
posta user8811409 20.12.2018 - 12:55
fonte

2 risposte

2

Bene, il problema delle "elezioni leader" è abbastanza noto e l'app più utilizzata per risolverlo è probabilmente Apache Zookeeper .

Google e troverai molti documenti al riguardo.

Se vuoi un esempio del mondo reale - questo è il modo in cui Apache Hadoop sta implementando HA usando Zookeeper - link

    
risposta data 20.12.2018 - 21:11
fonte
1

I nodi worker possono vedere il filesystem dove arrivano i file?

Se sì, non usare nessun altro canale per comunicare con loro - invece fai tutta la segnalazione tramite il filesystem usando le tecniche Unix standard della vecchia scuola e la semi-atomicità delle operazioni di Unix FS di basso livello.

Se no, allora in che modo il lavoratore raccoglierà il file per l'elaborazione? Per esempio. I file sono troppo grandi per essere inviati su JMS direttamente?

Mentre il design è valido, hai 3 percorsi indipendenti:

• ⁠ Meccanismo di notifica synch (JMS) • ⁠ Consegna dei dati (??? - in che modo i lavoratori ottengono effettivamente i byte del file da elaborare) • ⁠ Bloccaggio distribuito (attualmente proposto come database)

Questo è troppo. Questi tipi di soluzioni possono essere eseguiti con un solo meccanismo (nel caso in cui i lavoratori vedono il filesystem direttamente, o possono scansionarlo) e con 2 (nel caso in cui i lavoratori non abbiano accesso diretto alle FS).

    
risposta data 21.12.2018 - 13:17
fonte