JRedisStabilità futura

Question

Sto utilizzando l'implementazione sincrona di JRedis, ma ho intenzione di passare alla modalità asincrona per comunicare con il server Redis.

Ma prima vorrei chiedere alla comunità se l'implementazione JRedisFuture di alphazero jredis è abbastanza stabile per l'uso in produzione o no?

C'è qualcuno che lo usa o ha esperienza con esso?

Grazie!

Answer 1

Quando JRedis ottiene il supporto per la semantica delle transazioni (Redis 1.3.n, ramo principale JRedis), certamente dovrebbe essere sufficientemente "stabile".

Il protocollo Redis per comandi non transazionali, essi stessi atomici, consente una finestra di errore irreversibile quando è stato inviato un comando distruttivo e in fase di lettura si verifica un errore di connessione.Il client NON ha MODO di sapere se Redis ha effettivamente elaborato l'ultima richiesta ma la risposta è stata interrotta a causa di un errore di rete (ad esempio).Anche il client di richiesta/risposta di base è suscettibile a questo (e penso che questo non sia limitato a Java di per sé).

Poiché il protocollo di Redis non richiede alcun metadato (assolutamente) con i comandi di tipo DML e DDL (ad es.nessun numero sequenziale del comando) viene aperta questa finestra di errore.

Con il pipelining non esiste più un'associazione sequenziale tra il comando che viene scritto e la risposta che viene letta.(La pipe sta inviando un comando che è N comandi dietro quello che ha causato a Redis l'emissione della risposta letta contemporaneamente.Se qualcosa va bene, ci sono MOLTI piatti nell'aria :)

Detto questo, ogni singolo oggetto futuro nella pipe verrà contrassegnato come difettoso e lo farai Sapere precisamente in quale risposta si è verificato il guasto.

Si qualifica come "instabile"?Secondo me no.Questo è un problema con il pipeline.

Ancora una volta, Redis 1.3.n con la semantica delle transazioni risolve completamente questo problema.

Al di fuori di questo problema, con il sistema asincrono (pipeline), c'è una grande responsabilità da parte tua nell'assicurarti di non sovraccaricare eccessivamente l'ingresso al connettore.In larga misura le pipeline JRedis ti proteggono da questo (poiché il thread del chiamante viene utilizzato per far scrivere alla rete, smorzando così naturalmente il carico di input sulla coda di risposta in sospeso).

Ma devi comunque eseguire i test: hai detto "Produzione", giusto?)) -- e dimensiona le tue scatole e metti un limite al numero di thread di caricamento sul front-end.

Consiglierei anche potenzialmente di non eseguire più di una pipeline JRedis su macchine multi-core.Nell'implementazione esistente (che non suddivide in blocchi il buffer di scrittura) c'è spazio per ottenere efficienze (nel contesto dell'utilizzo completo della larghezza di banda e della massimizzazione del throughput) eseguendo più pipeline sullo stesso server.Mentre una pipeline è impegnata a creare buffer da scrivere, l'altra sta scrivendo, ecc.Ma queste due pipeline interferiranno tra loro a causa della loro (inevitabile - ricorda che sono code e deve verificarsi una qualche forma di sincronizzazione) e dell'invalidazione periodica della cache (su ogni accodamento/accodamento nel peggiore dei casi - ma in Doug Lea confidiamo .) Quindi, se la latenza media della pipeline A raggiunge d1 (in isolamento), lo stesso vale per la pipe B.Purtroppo, eseguirne due sugli stessi core comporterà un nuovo periodo di invalidamento della cache a livello di sistema che è la METÀ del sistema originale, quindi DUE VOLTE man mano che si verificano più invalidamenti della cache (in media).Quindi è controproducente.Ma testa le condizioni di carico e sulla piattaforma di distribuzione della produzione prevista.