Sto costruendo un semplice server reattivo che dovrebbe consumare messaggi protobuf/protostuff in arrivo da più client, eseguire su di essi alcune logiche di business ed eventualmente inviare messaggi fire-and-forget ad altri utenti. Voglio implementare la parte di trasporto e decodifica in Netty. La mia domanda è: c'è qualche motivo per pubblicare i messaggi decodificati sul ring buffer di Disruptor in termini di prestazioni o le prestazioni extra offerte da Disruptor verrebbero annullate dalla pianificazione interna di Netty? Devo fornire a Netty due thread (uno per "accetta" e altri per il gruppo "connect") o solo uno è meglio? Forse, dovrei semplicemente dividere i messaggi per il campo della lunghezza nei gestori di Netty ed eseguire la decodifica in quelli di Disruptor?C'è qualche motivo per usare Netty con Disruptor in termini di prestazioni?
risposta
Dipende;)
Il disgregatore permette di disaccoppiare varie azioni differenti, e, potenzialmente, li esegue in parallelo. Quindi la domanda è: quanto è costosa la tua logica di business e quanto è scarso il tuo carico di lavoro? Il Disruptor viene utilizzato per trasferire dati tra thread, in particolare thread potenzialmente in esecuzione a velocità di messaggio diverse. Cioè consente al thread di produzione di generare una serie di messaggi mentre il thread di consumo è occupato a gestire l'ultimo messaggio.
Ad esempio, se si desidera mantenere il messaggio nel database e inviare il risultato in avanti, è possibile pubblicare il messaggio su un ringbuffer "in uscita" e utilizzare il codice non elaborato da questo e un DB persister.
Meno tempo spendi a fare cose in Netty's eventloop più client puoi gestire, o volumi di messaggi più grandi a livello di trasporto.
Grazie! Sembra che Disruptor si adatterebbe in quanto la gestione delle scoppi di messaggi e il giornalismo sono una parte importante. – wyrd