Architettura per sistema di acquisizione / visualizzazione del traffico in tempo reale distribuito

Question

Architettura per sistema di acquisizione / visualizzazione del traffico in tempo reale distribuito

#1 da (2 voti)

0

Ho uno scenario come segue (lo si può considerare come un sistema Wireshark distribuito):

Per una singola sessione di acquisizione, ci sono circa 1 ~ 10 nodi di cattura del traffico distribuiti in una rete LAN. Ogni nodo catturante acquisirà i dati dei messaggi non elaborati alla velocità di circa 1 ~ 1000 record / secondo per circa 1 ~ 10 ore. Nel frattempo, ci sono diversi nodi di visualizzazione del traffico (app WPF) nella stessa rete LAN per visualizzare tutti i record dei messaggi acquisiti.

Requisiti:

Tutti i record di tutte le sessioni di cattura devono essere mantenuti per ulteriori analisi.
Durante una sessione di acquisizione, i nodi di visualizzazione dovrebbero visualizzare il messaggio non elaborato e i dettagli analizzati in tempo reale (la latenza dovrebbe essere inferiore a 1 minuto dal momento in cui è stato acquisito il messaggio non elaborato).
Nei nodi del visualizzatore, l'utente può filtrare facilmente i dati in ogni sessione (come Wireshark).

Ora, ho un'architettura iniziale come di seguito:

E posso vedere diversi inconvenienti nella mia architettura iniziale:

Il DB probabilmente avrà problemi di prestazioni poiché la velocità di acquisizione può essere molto alta e il visualizzatore estrae costantemente dati da esso.
Il messaggio di analisi impiegherà molto tempo CPU di un nodo di visualizzazione e ciascun nodo di visualizzazione dovrà analizzare tutti i messaggi separatamente, il che è uno spreco poiché il risultato analizzato sarà lo stesso in tutti i nodi di visualizzazione.
Tenere tutti i messaggi di una sessione può essere un'enorme pressione di memoria (messaggio superiore a 36M, ogni messaggio impiega circa 100 ~ 1000 byte) per il nodo del visualizzatore.

Qualche suggerimento per migliorare la progettazione dell'architettura?

database architecture wpf redis

posta ricky 15.03.2018 - 03:52

fonte

1 risposta

Leggi altre domande sui tag database architecture wpf redis

Importazione inderogabile di moduli con Python Utente PHP, cliente, relazione commerciale

score 2 · Answer 1

The DB will probably have performance issue since the capturing speed can be very high and viewer will constantly pulling data from it.

Per non parlare del fatto che avrai bisogno di un processo automatico per ripulire il database.

Penso che una soluzione migliore utilizzerebbe un log di streaming come Kafka . L'idea di un tale log è che hai più broker, ognuno dei quali scrive nel proprio archivio di messaggi sequenziale. Per aumentare la larghezza di banda, aumenti il numero di broker. Puoi configurare la replica (forse non è necessaria nel tuo caso) e anche il tramonto automatico dei record.

Il grosso problema con un tale stream è l'ordine: in generale, i record saranno ordinati solo per una partizione dello stream, e c'è il potenziale per scritture fuori ordine anche all'interno di una partizione. Ma se puoi applicare un ordine al momento del consumo, puoi ricostruire l'ordine in uscita.

the parsed result will be the same in all viewer nodes

Questo mi indica che vorresti una singola macchina che esegua l'analisi e produca un output "cotto" dai dati grezzi. Dato che supponevo che volessi che questo output fosse in streaming, Kafka potrebbe essere usato anche per questo caso.

you can think of it as a distributed Wireshark system

Questo sta effettivamente catturando il traffico di rete? Se sì, ricorda che dovrai filtrare i messaggi che invii a qualunque cosa li stia accumulando.