Recomendados
Mais conteúdo relacionado
Le Cache - Principes avancés - Devoxx
- 1. Le cache – Principes avancés 9h30- 12h30 - Salle XX
- 2. Pratiques de caching avancées Aurélien Broszniowski Mathile Lemée Ingénieurs R&D – Software AG @AurBroszniowski @MathildeLemee 27 au 29 mars 2013
- 3. Aurélien Broszniowski • Ingénieur lead @ Terracotta • Tester Terracotta/Ehcache/Quartz • Tester un système distribué… Comment faire? • www.takeon.me • CEO, CTO, CFO, Marketing, Architecte, Développeur, Testeur…
- 4. Mathilde Lemée • Ehcache/Terracotta • DuchessFR • FluentLenium, wrapper autour de Selenium • Aetys, studio mobile
- 5. Le cache TODO desc caching
- 6. Le cache Cacher… TODO desc caching Pourquoi? Comment?
- 10. …OF YOUR CACHE
- 11. Chacun dans son coin…
- 14. Pourquoi le caching? - Hotset - Proximité - Partage - Distribution - Vitesse!!!!
- 15. Cache Aside "Par ma foi ! Il y a plus de quarante ans que je dis de la prose sans que j'en susse rien. " Molière ; Le Bourgeois gentilhomme
- 16. Cache aside Application Cache Get B Put A B DAO Read B Database
- 17. Cache as a System of Record
- 18. Cache as a s-o-r : read through Application Ehcache Get B Put A B Persistence layer Read B Database
- 19. Cache as a s-o-r : Write through Application Ehcache Put A Persistence layer Write A Database
- 20. Cache as a s-o-r : Write-behind Application Get A B C D Write-behind Ehcache thread B D Put A C Persistence layer Write A B C D Database
- 21. Write Through – Temps de réponses
- 22. Write Behind – Temps de réponses
- 23. Write Through – Database load
- 24. Write Behind – Database load
- 25. Refresh Ahead
- 26. Cache Aside vs Read/Write Through
- 27. Refresh Ahead vs Read Through
- 28. Write Behind vs Write Through
- 29. Partie 2 – Fonctionnalités avançées
- 30. Search
- 31. Search Results results = cache.createQuery().includeValues() .addCriteria(age.eq(32).and(gender.eq("male"))) .execute();
- 32. Du cache au data store
- 33. Recharge le cache en cas d’arrêt… …ou de crash.
- 34. Choisir où stocker ses données…
- 35. Allocation de la mémoire
- 36. Allocation de la mémoire Par unité
- 37. Allocation de la mémoire Par espace mémoire
- 38. Allocation de la mémoire Automatique
- 39. Partie 3 – La Scalabilité
- 41. Tant que ca marche…
- 42. Horizontale Scalabilité Scalabilité Scalabilité Scalabilité Scalabilité Scalabilité Scalabilité Scalabilité Scalabilité Scalabilité Scalabilité Scalabilité
- 43. Offheap
- 48. Near Cache
- 49. Partie 4 – Réplication WAN
- 51. WAN 3
- 53. Solutions solutions des bonus
- 54. Automatic Resource Control http://jsoftbiz.wordpress.com/2011/08/01/ehcache-2-5-goes-beta-explan Etudes de cas Write Behind / Write Through : http://www.infoq.com/articles/write-behind-caching http://ehcache.org/documentation/recipes/wan
Notas do Editor
- Description + Quand utiliser ? Cas classique, besoin de monter en charge, focus sur les lectures. 2 APIs une pour le cache, une pour la DB Améliore les temps de lecture Décharge la base de données en lecture Peut introduire une race condition en ecriture Probleme d’invalidation (incoherence db/cache)
- Réduit la latence des lectures / Décharge la BDD => comme cache aside Une seule API Dog-pile effect possible : si plusieurs threads demandent en meme temps la meme donnée qui n’est pas la, alors il va y avoir n requetes vers la db. Recquiert un cache intelligent
- Focus sur les écritures 1 API pour le cache La transaction n’est pas complete tant que la donnée n’a pas eté écrite dans la “ bdd ” => pas de races conditions Augmente legerement la latence des ecritures Invalidation naturelle
- Augmente énormément le nombre d’écriture par seconde Possibilité d’écrire par batch => une grosse requete plus efficace que plusieurs petite Conflation Fenetre dans laquelle il y a des différences entre le cache et la db / incohérence.
- Une lecture peut entrainer une ecriture asynchrone Diminution latence read. Se base sur le fait que l’on est capable de prédire nos acces future à nos données. Si celui ci est respecté alors pas de surcharge de la DB. Par contre, si celui ci n’est pas “ respecté ” alors beaucoup de données vont étre recalculées/récupérées pour rien => charge inutile de la base de données.
- Si plusieurs threads attaquent la meme données, chacun va faire les aller retour réseau dans le cas de cache aside. Alors qu’une seule action dans le cas de read/write through (lock sur la clé par exemple)
- Refresh Ahead tres performant si un cache peut prédire quelles donnéees vont etre accessible dans le futur. Si cette connaissance est complete, alors des lectures beaucoup plus rapides et pas d’overhead sur la base. Mais plus il y a d’échec dans cette connaissance, plus il va y avoir un overhead important sur la base de données ( des données non utilisées sont mises à jour).
- Si write Behind possible au point de vue métier (fenetre d’incohérence) alors il vaut mieux le choisir, diminue la latence, la charge de la dbb, permet de faire bcp plus de write a la secondes. Sinon write through.
- Un actif / 1 ou plusieurs passifs. Chacun contient toutes les données du cache. Pour toutes les updates du cache sur le server 1, les servers passifs, ici 2, sont également mis à jour mais de maniere asynchrone. Un cache mirroir est quasiment aussi efficace qu’un cache local, avec l’avantage d’une haute disponiblité : si le server 1 crash, le serveur 2 devient actif, et tous les clients s’y connectent.
- Chaque cache contient les données en entier. Toutes les mises a jours sont faites de maniere atomique Lecture extremement rapide Ecriture lente : necessite une ecriture synchrone. Le nombre d’écriture par seconde diminue fortement si plusieurs serveurs. Le cout d’une update n’est pas scalable si l’on rajoute un serveur Utile dans le cas de données de références –> pas d’écriture
- Topologie tres scalable Le cout d’une lecture ou d’une ecriture reste constant quelque soit le nombre de noeud du cluster. Les données sont distribuées sur les differents serveurs, les clients connaissent la map de distribution. Ainsi, les clients peuvent contacter directement le serveur qui contient les bonnes donées. Les données ne sont mises a jour que sur un seul serveur, pas besoin d’un systeme de lock qui necessiterait un aller-retour réseau.
- Combinaison d’un cache partionne et répliqué. Les données peuvent etre mises a jours dans les réplica de maniere synchrone ou asynchrone. A l’inverse du cache partionné, en cas de crash serveur, un autre serveur contenant le meme sous ensemble de données d’n serveur secondaire dit “ passif ” sera élu comme étant le nouveau seveur principal dit “ actif ” .
- Mirroir réplication Avantage : simple a mettre en oeuvre Toutes les lectures/ecritures sont faites sur l’actif du datacenterA. Necessite une configuration wan tres puissante / un réseau tres stable Latence pour les appli du data center B
- Les lectures sont effectuées sur le cache local (TSA a pour les appli du data center A, TSA B pour les appli du data center B) Les ecritures sont faites simultanément sur les deux data center via l’utilisation de JTA. Faible latence des écritures, haut débit de lecture Nécessite un gestionnaire XA Les écritures prennent plus de temps
- Les lectures sont effectuées sur le cache local (TSA a pour les appli du data center A, TSA B pour les appli du data center B) Les ecritures sont effectuées en local puis envoyée à un rythme défini via le message bus => batch scheduling / batch sizing configuration Point - : un message bus est requis