Distribuzione del lavoro tra client TCP

3

Ho un'applicazione (eseguita da un servizio di Windows) che si connette a un server TCP (chiamiamo il servizio 'Listener' da qui in poi).

[È importante notare che il server TCP è fuori dalla mia portata e dovrebbe essere considerato come un componente esterno che non può essere modificato in relazione alla seguente domanda]

Il server TCP trasferisce i dati a qualsiasi client che è collegato ad esso e questi dati iniziano una catena di business logic complessa, che è molto impegnativa.

Per migliorare l'affidabilità, vorrei eseguire diversi ascoltatori e distribuire i dati in arrivo tra di loro.

Condividono una cache distribuita (Redis, se è importante).

Come progetteresti un algoritmo che sia efficace, veloce (dato che il tempo è essenziale) e che i diversi ascoltatori non dovrebbero dipendere l'uno dall'altro (se uno di questi fallisce, l'algoritmo dovrebbe comunque funzionare)?

È anche importante che nessun dato del server vada in malora (ad esempio, non dovrebbe essere possibile che nessun listener gestisca dati inviati dal server)

Stavo pensando nella direzione delle Elezioni Leader basate su numeri casuali - sono nella giusta direzione?

[Listener è scritto in C #]

    
posta Berlo 18.02.2016 - 21:23
fonte

1 risposta

2

TCP non è un ottimo protocollo per questo tipo di cose.

Suggerirei un livello intermedio. Un singolo listener TCP che riceve tutti i messaggi e li mette in coda, dove "una coda" indica qualsiasi sistema di accodamento che consente la distribuzione di messaggi tra più abbonati.

RabbitMQ è abbastanza facile da implementare in .NET e molto flessibile per le tue esigenze. Le code di lavoro sono il concetto che stai cercando.

    
risposta data 18.02.2016 - 22:58
fonte

Leggi altre domande sui tag