Bonjour! Je m'appelle Alexey Pyankov, je suis développeur chez Sportmaster. En cela J'ai raconté comment le travail sur le site Sportmaster a commencé en 2012, quelles initiatives nous avons réussi à « mener à bien » et vice versa, quel rake nous avons collecté.
Aujourd'hui, je souhaite partager des réflexions sur un autre sujet : choisir un système de mise en cache pour le backend Java dans le panneau d'administration du site. Cette intrigue a une signification particulière pour moi - bien que l'histoire ne se soit déroulée que sur 2 mois, pendant ces 60 jours nous avons travaillé 12 à 16 heures et sans un seul jour de congé. Je n'avais jamais pensé ni imaginé qu'il était possible de travailler aussi dur.
Par conséquent, j'ai divisé le texte en 2 parties afin de ne pas le charger complètement. Au contraire, la première partie sera très légère - préparation, introduction, quelques considérations sur ce qu'est la mise en cache. Si vous êtes déjà un développeur expérimenté ou si vous avez travaillé avec des caches, du point de vue technique, il n'y aura probablement rien de nouveau dans cet article. Mais pour un junior, une si petite revue peut lui dire dans quelle direction regarder s’il se trouve à un tel carrefour.
Lorsque la nouvelle version du site Web Sportmaster a été mise en production, les données ont été reçues d'une manière qui n'était, pour le moins, pas très pratique. La base était constituée de tableaux préparés pour la version précédente du site (Bitrix), qui devaient être extraits dans ETL, mis sous une nouvelle forme et enrichis de diverses petites choses provenant d'une douzaine de systèmes supplémentaires. Pour qu'une nouvelle image ou description de produit apparaisse sur le site, il fallait attendre le lendemain - mises à jour uniquement la nuit, une fois par jour.
Au début, il y avait tellement d'inquiétudes dès les premières semaines de mise en production que de tels inconvénients pour les gestionnaires de contenu étaient insignifiants. Mais dès que tout s'est calmé, le développement du projet s'est poursuivi - quelques mois plus tard, début 2015, nous avons commencé à développer activement le panneau d'administration. En 2015 et 2016, tout se passe bien, nous publions régulièrement, le panneau d'administration couvre de plus en plus la préparation des données, et nous nous préparons au fait que bientôt notre équipe se verra confier la chose la plus importante et la plus complexe - le produit circuit (préparation complète et maintenance des données sur tous les produits). Mais à l'été 2017, juste avant le lancement du circuit des matières premières, le projet se retrouvera dans une situation très difficile - précisément à cause de problèmes de mise en cache. Je souhaite parler de cet épisode dans la deuxième partie de cette publication en deux parties.
Mais dans cet article, je partirai de loin, je présenterai quelques réflexions - des idées sur la mise en cache, qui seraient une bonne étape à parcourir avant un grand projet.
Lorsqu'une tâche de mise en cache se produit
La tâche de mise en cache n'apparaît pas simplement. Nous sommes des développeurs, écrivons un produit logiciel et souhaitons qu'il soit demandé. Si le produit est demandé et réussit, les utilisateurs viendront. Et il y en a de plus en plus. Et puis il y a beaucoup d’utilisateurs et alors le produit devient très chargé.
Dans les premières étapes, nous ne pensons pas à l'optimisation et aux performances du code. L'essentiel est la fonctionnalité, le déploiement rapide d'un pilote et le test des hypothèses. Et si la charge augmente, on gonfle le fer. Nous l'augmentons deux ou trois fois, cinq fois, peut-être 10 fois. Quelque part ici – les finances ne le permettront plus. De combien de fois le nombre d’utilisateurs va-t-il augmenter ? Ce ne sera pas comme 2-5-10, mais en cas de succès, ce sera de 100-1000 100 à XNUMX XNUMX fois. Autrement dit, tôt ou tard, vous devrez procéder à une optimisation.
Disons qu'une partie du code (appelons cette partie une fonction) prend un temps indécent et que nous voulons réduire le temps d'exécution. Une fonction peut être l'accès à une base de données ou l'exécution d'une logique complexe - l'essentiel est que son exécution prend beaucoup de temps. De combien pouvez-vous réduire le temps d’exécution ? A la limite, vous pouvez le réduire à zéro, pas plus. Comment réduire le temps d’exécution à zéro ? Réponse : éliminer complètement l’exécution. Au lieu de cela, renvoyez le résultat immédiatement. Comment connaître le résultat ? Réponse : soit calculez-le, soit cherchez quelque part. Le calcul est long. Et espionner, c'est, par exemple, se souvenir du résultat que la fonction a produit la dernière fois lorsqu'elle a été appelée avec les mêmes paramètres.
Autrement dit, la mise en œuvre de la fonction n'est pas importante pour nous. Il suffit de savoir de quels paramètres dépend le résultat. Ensuite, si les valeurs des paramètres sont représentées sous la forme d'un objet pouvant être utilisé comme clé dans un stockage, le résultat du calcul peut être enregistré et lu lors du prochain accès. Si cette écriture et cette lecture du résultat sont plus rapides que l'exécution de la fonction, on a un gain en terme de rapidité. Le montant du profit peut atteindre 100, 1000 et 100 mille fois (10^5 est plutôt une exception, mais dans le cas d'une base assez en retard, c'est tout à fait possible).
Exigences de base pour un système de mise en cache
La première chose qui peut devenir une exigence pour un système de mise en cache est une vitesse de lecture rapide et, dans une moindre mesure, une vitesse d'écriture. C'est vrai, mais seulement jusqu'à ce que nous déployions le système en production.
Jouons à cette affaire.
Disons que nous avons fourni du matériel à la charge actuelle et que nous introduisons maintenant progressivement la mise en cache. Le nombre d'utilisateurs augmente un peu, la charge augmente - on ajoute un peu de caches, on le visse ici et là. Cela continue pendant un certain temps, et désormais les fonctions lourdes ne sont pratiquement plus appelées - toute la charge principale repose sur le cache. Le nombre d’utilisateurs pendant cette période a augmenté N fois.
Et si la fourniture initiale de matériel pouvait être 2 à 5 fois supérieure, alors avec l'aide du cache, nous pourrions améliorer les performances d'un facteur 10 ou, dans le bon cas, d'un facteur 100, dans certains endroits peut-être d'un facteur de 1000. Autrement dit, sur le même matériel – nous traitons 100 fois plus de demandes. Super, vous méritez le pain d'épice !
Mais maintenant, à un moment donné, par hasard, le système s'est écrasé et le cache s'est effondré. Rien de spécial - après tout, le cache a été choisi en fonction de l'exigence "vitesse de lecture et d'écriture élevée, le reste n'a pas d'importance".
Par rapport à la charge de départ, notre réserve de fer était de 2 à 5 fois et la charge pendant cette période a augmenté de 10 à 100 fois. Grâce au cache, nous avons éliminé les appels de fonctions lourdes et donc tout a fonctionné. Et maintenant, sans cache, combien de fois notre système va-t-il ralentir ? Qu'est-ce qui va nous arriver? Le système va tomber.
Même si notre cache n'a pas planté, mais n'a été vidé que pendant un certain temps, il devra être réchauffé, et cela prendra un certain temps. Et pendant ce temps, la principale charge incombera à la fonctionnalité.
Conclusion : les projets de production très chargés nécessitent un système de mise en cache non seulement pour avoir des vitesses de lecture et d'écriture élevées, mais également pour garantir la sécurité des données et la résistance aux pannes.
Choix de farine
Dans un projet avec un panneau d'administration, le choix s'est déroulé comme suit : nous avons d'abord installé Hazelcast, car Nous connaissions déjà ce produit grâce à l'expérience du site principal. Mais ici, ce choix s'est avéré infructueux - selon notre profil de charge, Hazelcast n'est pas seulement lent, mais terriblement lent. Et à ce moment-là, nous avions déjà signé pour la date de sortie.
Spoiler : comment se sont exactement développées les circonstances qui nous ont fait rater une si grosse affaire et nous sommes retrouvés dans une situation aiguë et tendue - je vous le dirai dans la deuxième partie - et comment nous nous sommes retrouvés et comment nous en sommes sortis. Mais maintenant, je dirai simplement que c'était beaucoup de stress, et "pour penser - d'une manière ou d'une autre, je n'arrive pas à penser, on secoue la bouteille". « Secouer la bouteille » est également un spoiler, nous en reparlerons plus tard.
Ce que nous avons fait:
- Nous dressons une liste de tous les systèmes proposés par Google et StackOverflow. Un peu plus de 30
- Nous écrivons des tests avec une charge typique pour la production. Pour ce faire, nous avons enregistré les données qui transitent par le système dans un environnement de production - une sorte de renifleur de données non pas sur le réseau, mais à l'intérieur du système. C'est exactement ces données qui ont été utilisées dans les tests.
- Avec toute l'équipe, chacun sélectionne le système suivant dans la liste, le configure et exécute des tests. Il ne réussit pas le test, il ne supporte pas la charge – nous le jetons et passons au suivant.
- Sur le 17ème système, il est devenu clair que tout était sans espoir. Arrêtez de secouer la bouteille, il est temps de réfléchir sérieusement.
Mais c'est une option lorsque vous devez choisir un système qui « passera à travers la vitesse » lors de tests pré-préparés. Que se passe-t-il s'il n'existe pas encore de tels tests et que vous souhaitez choisir rapidement ?
Modélisons cette option (il est difficile d'imaginer qu'un développeur intermédiaire+ vive dans le vide et qu'au moment de la sélection, il n'ait pas encore formalisé sa préférence quant au produit à essayer en premier - par conséquent, un raisonnement ultérieur relève davantage d'un théoricien/philosophie/ à propos d'un junior).
Après avoir décidé des exigences, nous commencerons à sélectionner une solution prête à l'emploi. Pourquoi réinventer la roue : prenons un système de mise en cache tout fait.
Si vous débutez et recherchez sur Google, donnez ou prenez la commande, mais en général, les directives seront comme ceci. Tout d’abord, vous croiserez Redis, on l’entend partout. Vous découvrirez alors qu’EhCache est le système le plus ancien et le plus éprouvé. Nous parlerons ensuite de Tarantool, un développement national qui présente un aspect unique de la solution. Et aussi Ignite, car il gagne désormais en popularité et bénéficie du soutien de SberTech. À la fin, il y a aussi Hazelcast, car dans le monde de l'entreprise, il apparaît souvent parmi les grandes entreprises.
La liste n'est pas exhaustive, il existe des dizaines de systèmes. Et on ne foutra qu'une chose. Prenons les 5 systèmes sélectionnés pour le « concours de beauté » et faisons une sélection. Qui sera le vainqueur?
Redis
Nous lisons ce qu'ils écrivent sur le site officiel.
- projet open source. Offre un stockage de données en mémoire, la possibilité de sauvegarder sur disque, un partitionnement automatique, une haute disponibilité et une récupération après une panne de réseau.
Il semble que tout va bien, vous pouvez le prendre et le visser - tout ce dont vous avez besoin, c'est le cas. Mais juste pour le plaisir, regardons les autres candidats.
EhCache
- « le cache le plus utilisé pour Java » (traduction du slogan du site officiel). Également open source. Et puis nous comprenons que Redis n'est pas pour Java, mais général, et pour interagir avec lui, vous avez besoin d'un wrapper. Et EhCache sera plus pratique. Que promet d’autre le système ? Fiabilité, fonctionnalité éprouvée et complète. Eh bien, c'est aussi le plus courant. Et met en cache des téraoctets de données.
Redis est oublié, je suis prêt à choisir EhCache.
Mais un sentiment de patriotisme me pousse à voir ce qu’il y a de bien chez Tarantool.
Tarantoutil
- répond à l'appellation « Plateforme d'intégration de données en temps réel ». Cela semble très compliqué, alors nous lisons la page en détail et trouvons une déclaration forte : « Met en cache 100 % des données dans la RAM ». Cela devrait soulever des questions : après tout, il peut y avoir bien plus de données que de mémoire. L'explication est que cela signifie que Tarantool n'exécute pas de sérialisation pour écrire des données sur le disque à partir de la mémoire. Au lieu de cela, il utilise des fonctionnalités de bas niveau du système, lorsque la mémoire est simplement mappée sur un système de fichiers avec de très bonnes performances d'E/S. En général, ils ont fait quelque chose de merveilleux et de cool.
Regardons les implémentations : Mail.ru Corporate Highway, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
S'il y avait encore des doutes sur Tarantool, alors le cas d'implémentation chez Mastercard m'achève. Je prends Tarantool.
Mais peu importe…
Enflammer
… y en a-t-il d'autres , est présenté comme une « plate-forme informatique en mémoire… des vitesses en mémoire sur des pétaoctets de données ». Il existe également de nombreux avantages ici : cache en mémoire distribué, stockage et cache clé-valeur les plus rapides, mise à l'échelle horizontale, haute disponibilité, intégrité stricte. En général, il s'avère que le plus rapide est Ignite.
Implémentations : Sberbank, American Airlines, Yahoo! Japon. Et puis je découvre qu'Ignite n'est pas seulement implémenté dans Sberbank, mais que l'équipe SberTech envoie ses gens dans l'équipe Ignite elle-même pour affiner le produit. C'est complètement captivant et je suis prêt à prendre Ignite.
On ne sait absolument pas pourquoi, je regarde le cinquième point.
Noisette
je vais sur le site , en lisant. Et il s'avère que la solution la plus rapide pour la mise en cache distribuée est Hazelcast. C'est des ordres de grandeur plus rapides que toutes les autres solutions et, en général, c'est un leader dans le domaine de la grille de données en mémoire. Dans ce contexte, prendre autre chose, ce n’est pas se respecter soi-même. Il utilise également un stockage de données redondant pour un fonctionnement continu du cluster sans perte de données.
Ça y est, je suis prêt à prendre Hazelcast.
Comparaison
Mais si vous regardez bien, les cinq candidats sont décrits de telle manière que chacun d'eux est le meilleur. Comment choisir? Nous pouvons voir lequel est le plus populaire, rechercher des comparaisons et le mal de tête disparaîtra.
On en trouve un comme ça , choisissez nos 5 systèmes.
Les voici triés : Redis est en tête, Hazelcast est en deuxième place, Tarantool et Ignite gagnent en popularité, EhCache a été et reste le même.
Mais regardons : liens vers des sites Web, intérêt général pour le système, offres d'emploi - super ! Autrement dit, lorsque mon système tombe en panne, je dirai : « Non, c'est fiable ! Il existe de nombreuses offres d'emploi..." Une comparaison aussi simple ne suffira pas.
Tous ces systèmes ne sont pas de simples systèmes de mise en cache. Ils ont également de nombreuses fonctionnalités, y compris lorsque les données ne sont pas pompées vers le client pour traitement, mais vice versa : le code qui doit être exécuté sur les données est déplacé vers le serveur, y est exécuté et le résultat est renvoyé. Et ils ne sont pas si souvent considérés comme un système de mise en cache distinct.
Bon, n'abandonnons pas, trouvons une comparaison directe des systèmes. Prenons les deux principales options : Redis et Hazelcast. Nous nous intéressons à la vitesse, et nous les comparerons en fonction de ce paramètre.
Hz contre Redis
On trouve ça :
Le bleu est Redis, le rouge est Hazelcast. Hazelcast gagne partout, et il y a une raison à cela : il est multithread, hautement optimisé, chaque thread fonctionne avec sa propre partition, donc il n'y a pas de blocage. Et Redis est monothread ; il ne bénéficie pas des processeurs multicœurs modernes. Hazelcast a des E/S asynchrones, Redis-Jedis a des sockets bloquants. Après tout, Hazelcast utilise un protocole binaire et Redis est centré sur le texte, ce qui signifie qu'il est inefficace.
Au cas où, tournons-nous vers une autre source de comparaison. Que va-t-il nous montrer ?
Redis contre Hz
Autre :
Ici, au contraire, le rouge est Redis. Autrement dit, Redis surpasse Hazelcast en termes de performances. Hazelcast a remporté la première comparaison, Redis a remporté la seconde. a expliqué très précisément pourquoi Hazelcast a remporté la comparaison précédente.
Il s'avère que le résultat du premier était en fait truqué : Redis a été pris dans la boîte de base et Hazelcast a été adapté pour un scénario de test. Ensuite, il s’avère : premièrement, nous ne pouvons faire confiance à personne, et deuxièmement, lorsque nous choisissons finalement un système, nous devons encore le configurer correctement. Ces paramètres incluent des dizaines, voire des centaines de paramètres.
Secouer la bouteille
Et je peux expliquer tout le processus que nous avons maintenant réalisé avec la métaphore suivante : « Secouer la bouteille ». Autrement dit, vous n'avez plus besoin de programmer, l'essentiel est désormais de pouvoir lire le stackoverflow. Et j'ai une personne dans mon équipe, un professionnel, qui travaille exactement comme ça dans les moments critiques.
Que fait-il? Il voit un objet cassé, voit une trace de pile, en extrait quelques mots (lesquels sont son expertise dans le programme), recherche sur Google, trouve un débordement de pile parmi les réponses. Sans lire, sans réfléchir, parmi les réponses à la question, il choisit quelque chose qui ressemble le plus à la phrase « fais ceci et cela » (choisir une telle réponse est son talent, car ce n'est pas toujours la réponse qui a reçu le plus de likes), s'applique, regarde : si quelque chose a changé, alors tant mieux. S'il n'a pas changé, annulez-le. Et répétez la recherche de lancement-vérification. Et de cette manière intuitive, il s'assure que le code fonctionne après un certain temps. Il ne sait pas pourquoi, il ne sait pas ce qu'il a fait, il ne peut pas l'expliquer. Mais! Cette infection fonctionne. Et « le feu est éteint ». Voyons maintenant ce que nous avons fait. Lorsque le programme fonctionne, c'est un ordre de grandeur plus facile. Et cela fait gagner beaucoup de temps.
Cette méthode est très bien expliquée avec cet exemple.
Il était autrefois très courant de collectionner un voilier dans une bouteille. En même temps, le voilier est grand et fragile, et le goulot de la bouteille est très étroit, il est impossible de le pousser à l'intérieur. Comment l'assembler ?
Il existe une telle méthode, très rapide et très efficace.
Le navire est constitué d'un tas de petites choses : des bâtons, des cordes, des voiles, de la colle. Nous mettons tout cela dans une bouteille.
Nous prenons la bouteille à deux mains et commençons à trembler. Nous la secouons et la secouons. Et généralement, cela s’avère être de la foutaise totale, bien sûr. Mais parfois. Parfois, il s'avère que c'est un navire ! Plus précisément, quelque chose de similaire à un navire.
Nous montrons quelque chose à quelqu'un : « Seryoga, tu vois !? Et effectivement, de loin, on dirait un navire. Mais cela ne peut pas continuer.
Il existe une autre façon. Ils sont utilisés par des personnes plus avancées, comme les hackers.
J'ai confié une tâche à ce type, il a tout fait et est parti. Et vous regardez, on dirait que c'est fait. Et au bout d'un moment, quand il faut finaliser le code, ça commence à cause de lui... C'est bien qu'il ait déjà réussi à s'enfuir loin. Ce sont eux qui, en prenant l'exemple d'une bouteille, feront ceci : vous voyez, là où est le fond, le verre se plie. Et il n’est pas tout à fait clair si c’est transparent ou non. Ensuite, les « hackers » ont coupé ce fond, y ont inséré un vaisseau, puis recollé le fond, et c’est comme si c’était censé être comme ça.
Du point de vue de la problématique, tout semble correct. Mais en prenant les navires comme exemple : pourquoi fabriquer ce navire, qui en a besoin de toute façon ? Il ne fournit aucune fonctionnalité. Habituellement, ces navires sont des cadeaux à des personnes de très haut rang, qui les placent sur une étagère au-dessus d'eux, comme une sorte de symbole, comme un signe. Et s'il s'agit d'une telle personne, chef d'une grande entreprise ou d'un haut fonctionnaire, comment le drapeau représentera-t-il un tel pirate dont le cou a été coupé ? Ce serait mieux s'il ne le savait jamais. Alors, comment finissent-ils par fabriquer ces vaisseaux qui peuvent être offerts à une personne importante ?
Le seul endroit clé sur lequel vous ne pouvez vraiment rien faire est le corps. Et la coque du navire s’insère parfaitement dans le cou. Alors que le navire est assemblé en dehors de la bouteille. Mais il ne s’agit pas seulement d’assembler un navire, c’est un véritable métier de joaillier. Des leviers spéciaux sont ajoutés aux composants, qui permettent ensuite de les soulever. Par exemple, les voiles sont pliées, soigneusement ramenées à l'intérieur, puis, à l'aide de pinces, elles sont tirées et remontées de manière très précise, avec précision. Le résultat est une œuvre d’art qui peut être offerte avec conscience et fierté.
Et si l’on veut que le projet réussisse, il faut qu’il y ait au moins un bijoutier dans l’équipe. Quelqu'un qui se soucie de la qualité du produit et qui prend en compte tous les aspects, sans rien sacrifier, même dans les moments de stress, lorsque les circonstances exigent de faire l'urgent au détriment de l'important. Tous les projets réussis, durables, qui ont résisté à l'épreuve du temps, sont construits sur ce principe. Il y a en eux quelque chose de très précis et d’unique, quelque chose qui exploite toutes les possibilités disponibles. Dans l'exemple avec un navire dans une bouteille, le fait que la coque du navire passe par le goulot est joué.
Revenant à la tâche de choisir notre serveur de mise en cache, comment cette méthode pourrait-elle être appliquée ? Je propose cette option de choisir parmi tous les systèmes qui existent - ne secouez pas la bouteille, ne choisissez pas, mais regardez ce qu'ils ont en principe, ce qu'il faut rechercher lors du choix d'un système.
Où chercher les goulots d'étranglement
Essayons de ne pas secouer la bouteille, de ne pas passer en revue tout ce qui s'y trouve un par un, mais voyons quels problèmes surgiront si nous, soudainement, pour notre tâche, concevons nous-mêmes un tel système. Bien sûr, nous n’assemblerons pas le vélo, mais nous utiliserons ce schéma pour nous aider à déterminer les points auxquels il faut prêter attention dans les descriptions de produits. Esquissons un tel schéma.
Si le système est distribué, nous aurons alors plusieurs serveurs (6). Disons qu'il y en a quatre (c'est pratique de les placer sur l'image, mais, bien sûr, il peut y en avoir autant que vous le souhaitez). Si les serveurs se trouvent sur des nœuds différents, cela signifie qu'ils exécutent tous un code chargé de garantir que ces nœuds forment un cluster et, en cas de panne, se connectent et se reconnaissent.
Nous avons également besoin d'une logique de code (2), qui concerne en fait la mise en cache. Les clients interagissent avec ce code via une API. Le code client (1) peut se trouver dans la même JVM ou y accéder via le réseau. La logique mise en œuvre à l'intérieur est la décision quant aux objets à laisser dans le cache et à ceux à jeter. Nous utilisons la mémoire (3) pour stocker le cache, mais si nécessaire, nous pouvons sauvegarder certaines données sur le disque (4).
Voyons dans quelles parties la charge se produira. En fait, chaque flèche et chaque nœud seront chargés. Premièrement, entre le code client et l'API, s'il s'agit d'une communication réseau, l'affaissement peut être assez perceptible. Deuxièmement, dans le cadre de l'API elle-même, si nous en faisons trop avec une logique complexe, nous pouvons rencontrer des problèmes avec le CPU. Et ce serait bien si la logique ne perdait pas de temps en mémoire. Et il reste l'interaction avec le système de fichiers - dans la version habituelle, il s'agit de sérialiser/restaurer et d'écrire/lire.
Vient ensuite l’interaction avec le cluster. Très probablement, ce sera dans le même système, mais cela pourrait être séparément. Ici, vous devez également prendre en compte le transfert des données vers celui-ci, la vitesse de sérialisation des données et les interactions entre le cluster.
Maintenant, d'une part, nous pouvons imaginer « quels engrenages vont tourner » dans le système de cache lors du traitement des requêtes de notre code, et d'autre part, nous pouvons estimer quelles et combien de requêtes notre code générera à ce système. Cela suffit pour faire un choix plus ou moins sobre : choisir un système adapté à notre cas d'utilisation.
Noisette
Voyons comment appliquer cette décomposition à notre liste. Par exemple, Hazelcast.
Afin de mettre/prendre des données de Hazelcast, le code client accède (1) à l'API. Hz vous permet d'exécuter le serveur de manière intégrée, et dans ce cas, l'accès à l'API est un appel de méthode à l'intérieur de la JVM, qui peut être considéré comme gratuit.
Pour que la logique de (2) fonctionne, Hz s'appuie sur le hachage du tableau d'octets de la clé sérialisée - c'est-à-dire que la clé sera sérialisée dans tous les cas. C’est une surcharge inévitable pour Hz.
Les stratégies d'expulsion sont bien mises en œuvre, mais pour des cas particuliers, vous pouvez ajouter les vôtres. Vous n'avez pas à vous soucier de cette partie.
Le stockage (4) peut être connecté. Super. L'interaction (5) pour l'embarqué peut être considérée comme instantanée. Échange de données entre les nœuds du cluster (6) – oui, cela existe. Il s’agit d’un investissement dans la tolérance aux pannes au détriment de la vitesse. La fonctionnalité Hz Near-cache vous permet de réduire le prix - les données reçues des autres nœuds du cluster seront mises en cache.
Que peut-on faire dans de telles conditions pour augmenter la vitesse ?
Par exemple, pour éviter la sérialisation de la clé dans (2), attachez un autre cache au-dessus de Hazelcast, pour les données les plus chaudes. Sportmaster a choisi Caffeine à cet effet.
Pour la torsion au niveau (6), Hz propose deux types de stockage : IMap et ReplicatedMap.
Il convient de mentionner comment Hazelcast est entré dans la pile technologique Sportmaster.
En 2012, alors que nous travaillions sur le tout premier pilote du futur site, c'est Hazelcast qui s'est avéré être le premier lien renvoyé par le moteur de recherche. La connaissance a commencé « du premier coup » - nous avons été captivés par le fait qu'à peine deux heures plus tard, lorsque nous avons vissé Hz dans le système, cela a fonctionné. Et ça a bien fonctionné. À la fin de la journée, nous avions effectué un certain nombre de tests et étions satisfaits. Et cette réserve de vigueur suffisait à surmonter les surprises que Hz nous réservait au fil du temps. Désormais, l'équipe Sportmaster n'a aucune raison d'abandonner Hazelcast.
Mais des arguments tels que « le premier lien dans le moteur de recherche » et « HelloWorld a été rapidement assemblé » sont, bien entendu, une exception et une caractéristique du moment où le choix a eu lieu. Les véritables tests du système choisi commencent dès la mise en production, et c'est à ce stade que vous devez faire attention lors du choix d'un système, y compris le cache. En fait, dans notre cas, nous pouvons dire que nous avons choisi Hazelcast par accident, mais il s'est avéré que nous avions choisi le bon.
Pour la production, c'est bien plus important : surveillance, gestion des pannes sur les nœuds individuels, réplication des données, coût de mise à l'échelle. Autrement dit, il convient de prêter attention aux tâches qui surviendront lors de la maintenance du système - lorsque la charge est des dizaines de fois supérieure à celle prévue, lorsque nous téléchargeons accidentellement quelque chose au mauvais endroit, lorsque nous devons déployer une nouvelle version. du code, remplacez les données et faites-le inaperçu pour les clients.
Pour toutes ces exigences, Hazelcast fait certainement l’affaire.
À suivre
Mais Hazelcast n’est pas une panacée. En 2017, nous avons choisi Hazelcast pour le cache administrateur, simplement sur la base des bonnes impressions de notre expérience passée. Cela a joué un rôle clé dans une blague très cruelle, à cause de laquelle nous nous sommes retrouvés dans une situation difficile et en sommes sortis « héroïquement » pendant 60 jours. Mais nous en reparlerons dans la partie suivante.
En attendant... Joyeux Nouveau Code !
Source: habr.com