Quand on développe une application informatique en Java: utiliser plutôt Ehcache ou plutôt zookeeper ?
Encore des frameworks Java! En environnement distribué, on parle souvent d'Hystrix, Storm, Pinpoint, Zuul, Hazelast, Quasar, Ribbon, Orbit, Atomix, Redisson. Quand il s'agit de recopier des données en Java, on pense de suite à Ehcache et à Zookeeper.
J'entends beaucoup parler de Zookeeper en ce moment. La mode était à Ehcache ces derniers temps, il semble que Zookeeper le soit en ce moment.
Lorsque l’on a des rogrammmes démarrés des horaires différents, des cycles différents, MAIS ils doivent avoir le meme contexte. Si un premier démarre et qu’il charge un cache (base de donnée, fichier) si le 2eme démarre, il doit posseder le même contexte.
EHCACHE gere un mécanisme de réplication en RMI
Les 2 programmes qui utilisent EHCACHE ont un contexte répliqué en temps reel
Les 2 caches sont découverts automatiquement. Une fois découverts, les caches peuvent communiquer. Exemple, la valeur d’un compte bancaire sur un serveur, sera répliquée sur un autre serveur, et inversement.
Le cache est par exemple une base de données. Pendant le cycle de vie, on écrit dans ce cache. L’état du cache est plus récent que la base de donnée. Si maintenant on a 2 programmes partageant ce cache. Si un client écrit dans le cache, ca écrit dans l’autre cache, MAIS les caches sont plus récents que la base de donnée. Le cache rend cohérent l’état du contenu de la base de donnée avec le cache, c’est son grand interet. Tout ce mécanisme est géré par la librairie EHCACHE.
Comment EHCACHE met à jour la base de donnée ? EHCACHE apporte des APIs. Ces APIS, on les implémente pour lui dire : est-ce que je vais flusher mon contenu de mon cache à tel intervalle, etc. Ehcache doit persister quelque chose, ou, quand comment ? A configurer dans EHcache. Ce dernier fonctionne avec des clés-valeurs, qu’il va mettre ensuite dans les tables de la base de donnée.
Les accès concurrents sont très bien gérés au niveau de la base de donnée. Si un cache contient une valeur A et un autre cache contient une autre valeur A ? Aucun interet que les 2 écrivent la valeur A en même temps dans la base de donnée.
Si N programmes sont tous répliquée, on considère que chaque réplicant possède la même version. Pourquoi implanter de la persistance sur chacun ? Pas besoin. On implante la persistance sur un seul réplicant pour qu’il flush à intervalle régulier, donc pas de problème d’accès concurrents.
Dans un cluster, il y a un maitre : toutes les instances se répliquent, mais seul le maître persiste. Si le maitre tombe, un nouveau maître est élu et il acquiert la fonctionnalité de flusher dans la base de donnée.
Une question? Posez-la ici
Avec Zookeeper, alternative à Ehcache, pourquoi plutôt l’un ou plutôt l’autre ?
Ehcache est une API Java. On doit nécéssairement l’intégrer au projet et on doit écrire du code. La notion de contexte est libre : la structure proposée est clé-valeur mais on organise ce cache comme on veut Ensuite des routines existent pour répliquer, etc. S’il y a 2 programmes, chacun embarque un ehcache, donc 2 programmes. A chaque fois qu’il ya un process, il y a EHcache embarqué. Ca veut dire qu’avec 3 programmes : 2 sur un host, et 1 sur 1 host, chacun embarque EHCACHE. Programmation plus pointue que pour zookeeper.
En terme de scalabilité
augenter la performance = augmenter le nombre d’hote : dur à augmenter
EHcache permet de savoir comment fonctionne la programmation réseau
Zookeeper est une API qui permet d’acceder à quelquechose, mais par contre, il y a un process. Si 2 hosts, 2 programmes, et donc 1 instance de zookeeper sur chaque host. Un host = 1 zookeeper. Ehosts, 2 programmes sur le 1er, 1 sur le 2eme, 2 zookeeper avec l’instane locale, et sur la machine distance, instance zookeeper, et ce sont les zookeper qui se parlent. L’aPI Zookeeper permet de se connecter rapidement sur un Znode, sans se soucier du port et de l’IP, on s’occupe du nœud facilement : La philosophie d’Hadoop, c’est de gérer des nœuds : notion d’autorité de gestion. En terme de scalabilité: augenter la performance = augmenter le nombre d’hote : facile à augmenter.
Avec Zookeeper on a une abstraction plus élevée niveau programmation réseau.
Zookepper est plus facile à implémenter qu’EHcache, car plus récent.
Une question? Posez-la ici
Ehcache/Zookeeper ; Dans quel cas utiliser quel produit ?
Si je crée une PAAS (Platform as a service), j’utilise Hadoop, j’utilise donc zookeeper. Si je crée une solution Kafka de file de message intensive, très fortement couplé avec zookeeper car on redonde les instances de kafka avec zookeeper.
Une question? Posez-la ici
Et Jersey SSE dans tout ça ?
Le Multicast classique en UDP : envoi de paquets sans garantie qu’ils arrivent. On considère qu’à 99% ça arrive. Mais dans certains cas, coupure, on perd des paquets . Conséquence on risque d’avoir des contenus de cache qui sont « inconsistents » qui ne sont plus cohérents. Exemple le compte bancaire à gauche n’est pas identique au compte bancaire à droite, parce que le paquet de réplication est perdu. Donc pour rendre les réplications transactionnelles : on écrit SI et seulement SI on a répliqué sur les autres instances. On est donc obligé d’établir des communications avec chacun des réplicants pour s’assurer que tout le monde est au même niveau de réplication.
Pattern Eventual Consistency, incohérence naturelle et acceptable
On considère dans une application distribuée, pour ne pas dégrader la performance : en TCP Il faut se connecter, il y a plus d’échanges, donc c’est couteux. En UDP, on peut dire que dans 99%des cas ca fonctionne. MAIS, on accepte qu’à des moments du cycle de vie on ait des incohérences, mais on met en place des mécanismes de résilience pour gérer ces incohérences plus tard
Une question? Posez-la ici
Besoin d'aide avec les communications dans les systèmes distribués? Remplissez ce formulaire: