Le Cache - Principes avancés - Devoxx

466 views

Published on

Hands on Cache - Devoxx

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
466
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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
  • Le Cache - Principes avancés - Devoxx

    1. 1. Le cache – Principes avancés 9h30- 12h30 - Salle XX
    2. 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. 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. 4. Mathilde Lemée • Ehcache/Terracotta • DuchessFR • FluentLenium, wrapper autour de Selenium • Aetys, studio mobile
    5. 5. Le cache TODO desc caching
    6. 6. Le cache Cacher… TODO desc caching Pourquoi? Comment?
    7. 7. HOTSET+ PROXIMITE
    8. 8. …OF YOUR CACHE
    9. 9. Chacun dans son coin…
    10. 10. …partager c’est mieux!
    11. 11. Parallélismeetdistribution
    12. 12. Pourquoi le caching? - Hotset - Proximité - Partage - Distribution - Vitesse!!!!
    13. 13. Cache Aside "Par ma foi ! Il y a plus de quarante ans que je dis de la prose sans que jen susse rien. "   Molière ; Le Bourgeois gentilhomme
    14. 14. Cache aside Application Cache Get B Put A B DAO Read B Database
    15. 15. Cache as a System of Record
    16. 16. Cache as a s-o-r : read through Application Ehcache Get B Put A B Persistence layer Read B Database
    17. 17. Cache as a s-o-r : Write through Application Ehcache Put A Persistence layer Write A Database
    18. 18. 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
    19. 19. Write Through – Temps de réponses
    20. 20. Write Behind – Temps de réponses
    21. 21. Write Through – Database load
    22. 22. Write Behind – Database load
    23. 23. Refresh Ahead
    24. 24. Cache Aside vs Read/Write Through
    25. 25. Refresh Ahead vs Read Through
    26. 26. Write Behind vs Write Through
    27. 27. Partie 2 – Fonctionnalités avançées
    28. 28. Search
    29. 29. SearchResults results = cache.createQuery().includeValues() .addCriteria(age.eq(32).and(gender.eq("male"))) .execute();
    30. 30. Du cache au data store
    31. 31. Recharge le cache en cas d’arrêt… …ou de crash.
    32. 32. Choisir où stocker ses données…
    33. 33. Allocation de la mémoire
    34. 34. Allocation de la mémoire Par unité
    35. 35. Allocation de la mémoire Par espace mémoire
    36. 36. Allocation de la mémoire Automatique
    37. 37. Partie 3 – La Scalabilité
    38. 38. VerticaleSCALABILITE
    39. 39. Tant que ca marche…
    40. 40. HorizontaleScalabilité Scalabilité Scalabilité ScalabilitéScalabilité Scalabilité Scalabilité Scalabilité Scalabilité Scalabilité Scalabilité Scalabilité
    41. 41. Offheap
    42. 42. Near Cache
    43. 43. Partie 4 – Réplication WAN
    44. 44. WAN 3
    45. 45. Solutions solutions des bonus
    46. 46. Automatic Resource Controlhttp://jsoftbiz.wordpress.com/2011/08/01/ehcache-2-5-goes-beta-explanEtudes de cas Write Behind / Write Through : http://www.infoq.com/articles/write-behind-cachinghttp://ehcache.org/documentation/recipes/wan

    ×