la stabilité JRedisFuture

Question

J'utilise la mise en œuvre synchrone JRedis, mais je prévois de passer à la manière asynchrone pour communiquer avec le serveur Redis.

Mais avant que je voudrais demander à la communauté si la mise en œuvre de JRedisFuture de alphazero jredis est stable suffisant pour une utilisation de production ou non?

Est-ce qu'il ya quelqu'un là-bas qui utilise ou ont de l'expérience avec elle?

Merci!

Answer 1

Lorsque JRedis obtient le soutien à la sémantique de transaction (Redis 1.3.n, branche maître JRedis) alors certainement, il devrait être assez de "stable".

protocole Redis pour les commandes non transactionnelles, eux-mêmes atomiques, permet à une fenêtre de défaillance irrémédiable quand une commande de destruction a été envoyé, et sur la phase de lecture des défauts de connexion. Le client n'a aucun moyen de savoir si Redis en fait traité la dernière demande, mais la réponse a déposés en raison de défaillance du réseau (par exemple). Même la demande de base / client de réponse est sensible à ce (et je pense que cela ne se limite pas à Java, en tant que tel.)

Etant donné que le protocole Redis ne nécessite pas de métadonnées (tout) avec les commandes de type DML et DDL (par exemple pas de numéro de séquent de commande), cette fenêtre d'échec est ouvert.

Avec pipelining, il n'y a plus une association séquentielle entre la commande qui est en cours d'écriture et la réponse qui est en cours de lecture. (Le tuyau envoie une commande qui est N commandes derrière celui qui a causé Redis d'émettre la réponse en cours de lecture en même temps, si quelque chose se passe kaput, il y a beaucoup de plats dans l'air:.)

Cela dit, chaque objet futur unique dans le tuyau sera marqué comme faillé et vous savoir avec précision à laquelle réponse la faute a eu lieu.

Est-ce qui se qualifient comme « instable »? À mon avis, non. C'est un problème avec pipelining.

Encore une fois, Redis 1.3.n avec la sémantique de transaction aborde complètement cette question.

En dehors de cette question, avec asynchrones (pipelines), il y a beaucoup de responsabilité de votre part pour vous assurant de ne pas surcharger excessivement l'entrée du connecteur. Pour un énorme vous protéger de ce pipelines de mesure (depuis le thread de l'appelant est utilisé pour rendre le réseau écriture ainsi d'amortissement naturellement la charge d'entrée sur la file d'attente de réponse en attente).

Mais vous avez encore besoin d'exécuter des tests - vous avez dit « Production », non? )) - et la taille de vos boîtes et mettre un plafond sur le nombre de threads de chargement sur l'extrémité avant.

Je recommande aussi potentiellement ne fonctionne pas plus d'un pipeline JRedis sur les machines multi-core. Dans la mise en œuvre existante (qui n'a pas le morceau tampon d'écriture) il y a place pour l'efficacité (dans le contexte de la pleine utilisation de la bande passante et le débit maximisant) à gagner en exécutant plusieurs pipelines sur le même serveur. Alors que l'un pipeline est des tampons en train de créer à écrire, l'autre est l'écriture, etc. Mais, ces deux pipelines vont interférer entre eux en raison de leur (inévitable - rappelez-vous qu'ils sont des files d'attente et une certaine forme de synchronisation doit se produire) et l'invalidation du cache périodique (sur chaque dequeue / enqueue dans le pire des cas - mais Doug Lea nous faisons confiance.) donc, si coup de latence moyenne pipeline A d1 (en vase clos), puis le fait tuyau B. Malheureusement, l'exécution de deux d'entre eux sur les mêmes noyaux résultera dans une nouvelle période de grande cache infirmation du système qui est à moitié du système original si DEUX FOIS que se produisent invalidations plus de cache (en moyenne). Il est donc l'encontre du but. Mais tester vos conditions de charge, et sur votre plate-forme de déploiement de la production projetée.