Esiste un approccio migliore per l'elaborazione dei bilanci di massa

0

Il mio compito è elaborare delta di bilanciamento asincrono per più client e fornire importi di bilancio aggregati.

Ho un servizio REST che accetta richieste da N client C₁…Cₙ , ognuna di esse ha il proprio valore di bilancio finanziario che cambia nel tempo. Questi client inviano gli aggiornamenti del saldo positivo / negativo al servizio REST, li accumula e li aggrega. Ad esempio, C₁ ha un saldo iniziale di 100 e invia questa sequenza: [+20, -15, +5] , quindi il saldo risultante dovrebbe essere 110 .

La quantità di richieste è abbastanza grande e la mia soluzione attuale è la seguente. Ogni richiesta viene archiviata come record separato nella tabella DB che specifica l'ID client e un valore delta. Il pool di worker in background inserisce le somme delta per quei client che sono assegnati ad un determinato thread. Ad esempio, solo Thread₁ e nessun altro elaborerà, ad esempio, C₁, C₁₀, C₂₀ and C₃₀ . L'assegnazione viene eseguita all'inserimento di un nuovo record con valore delta.

Questo approccio ha uno svantaggio. Ad esempio, se più client (ad esempio, C₁₀, C₂₀ ) che generano traffico pesante vengono assegnati sullo stesso thread di lavoro (ad esempio Thread₁ ), tutti gli altri thread saranno inattivi per la maggior parte del tempo rispetto a questo Thread₁ . La riassegnazione di C₂₀ a Thread₂ renderebbe il sistema più performante, ma non è possibile in questo progetto. Richiede una riassegnazione dinamica che richiede una sorta di azione "stop-accepting-request" seguita dal ricalcolo del peso dei clienti e dalla riassegnazione. ( UPD : o calcola ogni peso del cliente in background e interrompe le richieste di accettazione almeno da quei client che dovrebbero essere riassegnati.)

Lasciando che i lavoratori elaborino record arbitrari porteranno a valori di bilancio errati poiché non è consentito che il saldo sia inferiore a zero.

Ci sono idee su come migliorare questa soluzione?

    
posta igorp1024 01.03.2018 - 20:16
fonte

1 risposta

2

Non c'è davvero abbastanza informazione per rispondere a questa domanda perché dipende dalla comprensione del requisito di latenza nel caso peggiore, che non è fornito nella domanda, e sarebbe difficile da usare senza comprendere le specifiche del tuo sistema, anche se è stato fornito.

Ecco alcuni pensieri in ordine casuale (combinali se necessario):

  • Potresti stabilire che inizialmente tutti i thread elaborano le richieste da tutti i client.

    Quindi quando i thread si surriscaldano, puoi rilasciare selettivamente i client dai thread, assicurandoti che ogni client abbia almeno un thread.

  • Quando rilevi un thread caldo, seleziona un hot client per passare a un thread freddo. Comanda il thread caldo per inoltrare il saldo corrente del client al thread freddo, mentre allo stesso tempo, modifica le nuove richieste per andare al thread freddo.

  • Fai in modo che i tuoi thread condividano costantemente i saldi con gli altri thread in anticipo, in modo che possano prendere il controllo al più presto.

  • Esegui solo le operazioni sopra riportate con thread che superano un determinato livello di calore e per i client sopra un altro calore.

risposta data 01.03.2018 - 23:58
fonte

Leggi altre domande sui tag