Get best of the week

Comment nous, chez Sportmaster, avons choisi un système de mise en cache. Partie 1

salut! Je m'appelle Alexey Pyankov, je suis développeur chez Sportmaster. Dans cet article, j'ai expliqué comment le travail sur le site Web de Sportmaster a commencé en 2012, quelles initiatives nous avons réussi à faire passer, et vice versa, quel râteau nous avons collecté.

Aujourd'hui, je veux partager les réflexions qui suivent une autre histoire - choisir un système de mise en cache pour le backend java dans le panneau d'administration du site. Ce complot est d'une importance particulière pour moi - bien que l'histoire n'ait eu lieu que 2 mois, mais ces 60 jours, nous avons travaillé pendant 12-16 heures et sans jour de congé. Je n'avais jamais pensé et imaginé que vous pouviez travailler autant.

Par conséquent, je décompose le texte en 2 parties, afin de ne pas le télécharger en entier. Au contraire, la première partie sera très facile - 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 avez travaillé avec des caches - du côté technique, il n'y a probablement rien de nouveau dans cet article. Mais pour un junior, une petite revue de ce type peut dire dans quelle direction regarder, s'il se retrouve à un tel carrefour.



Lorsque la nouvelle version du site Web de Sportmaster a été lancée en production, les données sont arrivées d'une manière, pour le moins, pas très pratique. La base était les tableaux préparés pour la version précédente du site (Bitrix), qui devaient être resserrés dans ETL, apportés à un nouveau look et enrichis de différentes petites choses d'une douzaine de systèmes supplémentaires. Pour qu'une nouvelle photo ou description du produit apparaisse sur le site, vous avez dû attendre le lendemain - mise à jour uniquement la nuit, 1 fois par jour.

Au début, il y avait tellement de soucis dès les premières semaines de la mise en production que de tels inconvénients pour les gestionnaires de contenu étaient minimes. 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 va bien, nous le publierons régulièrement, la zone d'administration couvre la plus grande partie de la préparation des données, et nous nous préparons au fait que bientôt la chose la plus importante et la plus difficile sera confiée à notre équipe - la gamme de produits (préparation complète et maintenance des données pour tous les produits). Mais à l'été 2017, juste avant le lancement de la gamme de produits, le projet sera dans une situation très difficile - précisément en raison de problèmes de mise en cache. Je veux parler de cet épisode dans la deuxième partie de cette publication en deux parties.

Mais dans ce post, je vais partir de loin, comme quelques réflexions - des idées sur la mise en cache, que faire défiler avant un gros projet à l'avance serait une bonne étape.

Lorsqu'une tâche de cache survient


La tâche de mise en cache n'apparaît pas seulement. Nous sommes des développeurs, nous écrivons un produit logiciel et nous voulons qu'il soit en demande. Si le produit est en demande et réussi, les utilisateurs arrivent. Et plus viennent et plus. Et donc il y a beaucoup d'utilisateurs et le produit devient alors très chargé.

Lors des premières étapes, nous ne pensons pas à l'optimisation et aux performances du code. L'essentiel est la fonctionnalité, déployez rapidement le pilote et testez les hypothèses. Et si la charge augmente, nous pompons du fer. Nous l'augmentons d'un facteur deux, trois, cinq, que ce soit 10 fois. Quelque part ici - les finances ne le permettront plus. Et combien de fois le nombre d'utilisateurs augmentera-t-il? Ce ne sera pas seulement 2-5-10, mais en cas de succès, ce sera de 100-1000 et jusqu'à 100 000 fois. C'est, tôt ou tard, mais devra faire l'optimisation.

Disons qu'une partie du code (appelons cette partie une fonction) fonctionne indécemment pendant longtemps et nous voulons réduire le temps d'exécution. Fonction - cela peut être l'accès à la base de données, cela peut être l'exécution d'une logique complexe - l'essentiel est que cela prenne beaucoup de temps. Combien pouvez-vous réduire le délai de livraison? Dans la limite - peut être réduit à zéro, pas plus loin. Et comment pouvez-vous réduire le temps d'exécution à zéro? Réponse: exclut généralement l'exécution. Au lieu de cela, renvoyez immédiatement le résultat. Et comment connais-tu le résultat? Réponse: calculez ou regardez quelque part. Calculer est long. Et regarder, 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'a pas d'importance pour nous. Il suffit de savoir de quels paramètres dépend le résultat. Ensuite, si les valeurs des paramètres sont présentées sous la forme d'un objet qui peut être utilisé comme clé dans un stockage, nous pouvons enregistrer le résultat du calcul et le lire la prochaine fois. Si ces résultats d'écriture-lecture sont plus rapides que l'exécution de la fonction, nous avons un gain de vitesse. La valeur du profit peut atteindre 100, 1000 et 100 mille fois (10 ^ 5 est plus probablement une exception, mais dans le cas d'une base de décalage décente, c'est tout à fait possible).

Exigences de mise en cache clés


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. Il en est ainsi, mais seulement jusqu'à ce que nous déployions le système en production.

Jouons un tel cas.

Supposons que nous ayons fourni la charge actuelle en fer et que nous introduisions progressivement la mise en cache. Les utilisateurs augmentent un peu, la charge augmente - nous ajoutons un peu de caches, nous le fixons ici et là. Cela dure depuis un certain temps, et maintenant les fonctions lourdes ne sont pratiquement plus appelées - tout le fardeau principal tombe sur le cache. Le nombre d'utilisateurs pendant cette période a augmenté N fois.

Et si l'approvisionnement initial en fer pouvait être de 2 à 5 fois, alors avec l'aide du cache, nous pourrions resserrer la productivité tous les 10 ou, dans le bon cas, 100 fois, à certains endroits, peut-être 1000. Autrement dit, nous traitons sur le même fer 100 fois plus de demandes. Super, mérite un pain d'épice!

Mais maintenant, à un moment donné, par accident, le système s'est écrasé et le cache s'est écrasé. Rien de spécial - après tout, le cache a été sélectionné à la demande "lecture et écriture à grande vitesse, le reste n'a pas d'importance".

En ce qui concerne la charge de départ, la réserve de fer était de 2 à 5 fois, et la charge pendant cette période a augmenté de 10 à 100 fois. Avec l'aide du cache, nous avons éliminé les appels à des fonctions lourdes et donc tout a volé. Et maintenant, sans cache - combien de fois notre système s'affaisse-t-il? 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é effacé que pendant un certain temps, il devra être réchauffé, ce qui prendra un certain temps. Et à ce moment - le principal fardeau tombera sur le fonctionnel.

Conclusion: les projets à forte charge dans la prod nécessitent du système de mise en cache non seulement une vitesse de lecture et d'écriture élevée, mais également la sécurité des données et la résistance aux pannes.

Farine de choix


Dans le projet avec le panneau d'administration, le choix a été le suivant: ils ont d'abord mis Hazelcast, car connaissaient déjà ce produit de l'expérience du site principal. Mais, ici, ce choix n'a pas réussi - pour notre profil de charge, Hazelcast fonctionne non seulement lentement, mais terriblement lentement. Et à ce moment-là, nous nous étions déjà inscrits pour les conditions de retrait au prod.

Spoiler: comment exactement les circonstances se sont-elles produites lorsque nous avons raté un tel plop et que nous avons eu une situation aiguë et tendue - je dirai dans la deuxième partie - à la fois comment nous avons tourné et comment nous sommes sortis. Mais maintenant - je vais juste dire que c'était beaucoup de stress, et "pensez - d'une manière ou d'une autre, je ne pense pas, secouez la bouteille." «Secouer la bouteille» est aussi un spoiler, à ce sujet un peu plus loin.

Qu'avons-nous fait:

  1. Nous faisons une liste de tous les systèmes demandés par google et StackOverflow. Un peu plus de 30
  2. , . , - — , .
  3. , , , . , – , .
  4. 17- , . « », .

Mais c'est une option lorsque vous devez choisir un système qui "rampe en vitesse" dans des tests pré-préparés. Et s'il n'y a pas encore de tels tests et que vous souhaitez choisir plus rapidement?

Nous simulerons une telle option (il est difficile d'imaginer que le développeur intermédiaire + vit dans le vide, et au moment de la sélection, il n'avait pas encore décidé quel produit essayer en premier lieu - par conséquent, une discussion plus approfondie est probablement un théoricien / philosophie / à propos d'un junior).

Après avoir déterminé les exigences, nous commencerons à choisir une solution dans la boîte. Pourquoi réinventer la roue: nous irons prendre un système de cache prêt à l'emploi.

Si vous venez de commencer et que vous allez sur Google, alors plus ou moins la commande, mais en général, les directives seront comme ça. Tout d'abord, vous tombez sur Redis, on l'entend partout. Ensuite, vous découvrirez qu'il existe EhCache comme système le plus ancien et le plus éprouvé. Ensuite, il sera écrit sur Tarantool - un développement national dans lequel il y a un aspect unique de la solution. Et aussi Ignite, car il gagne en popularité et bénéficie du soutien de SberTech. En fin de compte, il y a Hazelcast, car dans le monde de l'entreprise, il clignote souvent au milieu des grandes entreprises.

Cette liste ne s'arrête pas là, il existe des dizaines de systèmes. Et nous n'en visons qu'un. Prenez les 5 systèmes sélectionnés pour le "concours de beauté" et effectuez une sélection. Qui sera le vainqueur?

Redis


Nous lisons ce qu'ils écrivent sur le site officiel.
Redis est un projet open source. Il offre un stockage de données en mémoire, la possibilité d'enregistrer sur le disque, une partition automatique en partitions, une haute disponibilité et une récupération après des ruptures de réseau.

Il semble que tout va bien, vous pouvez le prendre et le visser - tout ce dont il a besoin est ce qu'il fait. Mais regardons juste pour l'intérêt des autres candidats.

Ehcache


EhCache - "le cache le plus utilisé pour Java" (traduction du slogan du site officiel). Open source également. Et ici, nous comprenons que Redis n'est pas sous java, mais général, et pour interagir avec lui, vous avez besoin d'un wrapper. Et EhCache sera plus pratique. Que promet le système d'autre? Fiabilité, solidité, fonctionnalité complète. Eh bien, et elle est la plus courante. Et met en cache des téraoctets de données.

Redis est oublié, je suis prêt à choisir EhCache.

Mais un sens du patriotisme me pousse à voir ce qui rend Tarantool bon.

Tarantool


Tarantool - Répond à la désignation «plate-forme d'intégration de données en temps réel». Cela semble très difficile, alors nous lisons la page en détail et trouvons une déclaration forte: "Caches 100% des données dans la RAM." Cela devrait soulever des questions - après tout, il peut y avoir beaucoup plus de données que de mémoire. Le déchiffrement est qu'ici, il est sous-entendu que Tarantool n'exécute pas la sérialisation pour écrire des données sur un disque à partir de la mémoire. Au lieu de cela, il utilise les 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 l'ont fait en quelque sorte merveilleux et cool.

Examinons la mise en œuvre: l'autoroute d'entreprise Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom ...

S'il y avait encore des doutes sur Tarantool, l'introduction de l'implémentation Mastercard me tuerait. Je prends Tarantool.

Mais peu importe…

Enflammer


... il y a Ignite , déclaré comme "une plate-forme informatique en mémoire ... des vitesses en mémoire sur des pétaoctets de données". Les avantages sont également nombreux: cache distribué en mémoire, stockage et cache de valeurs-clés 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 toujours qu'Ignite n'est pas seulement implémenté dans Sberbank, mais l'équipe SberTech envoie son personnel à l'équipe Ignite pour finaliser le produit. C'est complètement captivant et je suis prêt à prendre Ignite.

Il est totalement incompréhensible pourquoi, je regarde le cinquième point.

Hazelcast


Je vais sur le site Hazelcast , je le lis. Et il s'avère que la solution la plus rapide pour la mise en cache distribuée est Hazelcast. Il est des ordres de grandeur plus rapide que toutes les autres solutions et en général, il est un leader dans le domaine de la grille de données en mémoire. Dans ce contexte, prenez autre chose - ne vous respectez pas. Il utilise également un stockage de données redondant pour un fonctionnement continu du cluster sans perte de données.

Tout, je suis prêt à prendre Hazelcast.

Comparaison


Mais si vous regardez, les cinq candidats sont si bien peints que chacun d'eux est le meilleur. Comment choisir? Nous pouvons voir lequel est le plus populaire, chercher des comparaisons et le mal de tête passera.

Nous trouvons un tel avis , choisissez nos 5 systèmes.



Ici, ils sont triés: au sommet de Redis, en deuxième place, Hazelcast, Tarantool et Ignite gagnent en popularité, EhCache a été et reste.

Mais regardons la méthode de calcul : 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, il est fiable! Voici beaucoup d'offres d'emploi ... ". Une comparaison aussi simple ne fonctionnera pas.

Tous ces systèmes ne sont pas uniquement des systèmes de mise en cache. Ils ont encore beaucoup de fonctionnalités, y compris lorsque les données ne sont pas transférées au client pour traitement, mais plutôt: le code qui doit être exécuté sur les données se déplace vers le serveur, il y est exécuté et le résultat est retourné. Et en tant que système distinct pour la mise en cache, ils ne sont pas si souvent considérés.

Eh bien, n'abandonnez pas, nous trouvons une comparaison directe des systèmes. Prenez les deux premières options - Redis et Hazelcast. Nous nous intéressons à la vitesse, nous pouvons les comparer par ce paramètre.

Hz vs Redis


Nous trouvons une telle comparaison : le


bleu est Redis, le rouge est Hazelcast. Hazelcast gagne partout, et la justification est donnée: il est multi-thread, hautement optimisé, chaque thread fonctionne avec sa propre partition, donc il n'y a pas de verrous. Et Redis est mono-thread, il ne prend pas de gain par rapport aux processeurs multicœurs modernes. Hazelcast a des E / S asynchrones, Redis-Jedis a des sockets de blocage. Au final, Hazelcast utilise un protocole binaire, tandis que Redis est orienté texte, ce qui signifie qu'il est inefficace.

Au cas où, nous nous tournons vers une autre source de comparaison. Que va-t-il nous montrer?

Redis vs Hz


Autre comparaison :


ici, au contraire, le rouge est Redis. Autrement dit, Redis surpasse Hazelcast en termes de performances. Dans la première comparaison, Hazelcast a gagné, dans la seconde - Redis. Ici, ils ont expliqué très précisément pourquoi Hazelcast avait gagné dans la comparaison précédente.

Il s'avère que le résultat du premier a été truqué: Redis a été emmené dans la boîte de base et Hazelcast a été emprisonné pour un test. Ensuite, il s'avère: premièrement, personne ne peut faire confiance, et deuxièmement, quand nous choisissons néanmoins un système, nous devons encore le configurer correctement. Ces paramètres incluent des dizaines, presque des centaines de paramètres.

Secouant une bouteille


Et tout le processus que nous venons de faire, je peux l'expliquer avec une telle métaphore, "Secouez la bouteille." Autrement dit, maintenant vous ne pouvez pas programmer, maintenant l'essentiel est de pouvoir lire stackoverflow. Et dans mon équipe, il y a une personne, un professionnel, qui travaille comme ça aux moments critiques.

Que fait-il? Il voit une chose cassée, voit une trace de pile, prend certains de ses mots (lesquels sont son expertise dans le programme), recherche dans Google, trouve stackoverflow parmi les réponses. Sans lire, sans réfléchir, parmi les réponses à la question - il choisit quelque chose de plus similaire à la phrase «faire ceci et cela» (choisir une telle réponse est son talent, car ce n'est pas toujours la réponse qui a recueilli le plus de likes), il utilise , regarde: si quelque chose a changé, ça va. S'il n'a pas changé, nous reculons. Et nous répétons start-check-search. Et d'une manière si intuitive, il y parvient après un certain temps, le code fonctionne. 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 éteint». Nous comprenons maintenant ce que nous avons fait. Lorsque le programme fonctionne, c'est beaucoup plus facile.Et économise considérablement du temps.

Cette méthode est très bien expliquée par un tel exemple.

Il était autrefois très populaire de récupérer un voilier dans une bouteille. Dans le même temps, le voilier est grand et fragile, et le col de la bouteille est très étroit, vous ne pouvez pas le pousser à l'intérieur. Comment l'assembler?



Il existe une telle méthode, très rapide et très efficace.

Le navire se compose d'un tas de petites choses: bâtons, cordes, voiles, colle. Nous mettons tout cela dans une bouteille.
Nous prenons la bouteille à deux mains et commençons à trembler. Nous tremblons, tremblons. Et généralement - vous obtenez des ordures complètes, bien sûr. Mais parfois. Parfois, vous obtenez un navire! Plus précisément, quelque chose de similaire à un navire.

Nous montrons ceci à quelqu'un: "Serge, tu vois!?". Et en effet, de loin - comme si un navire. Mais alors, vous ne pouvez pas laisser tomber.

Il y a une autre manière. Les gars en utilisent des plus avancés, tels des hackers.

A donné un tel gars une tâche, il a tout fait et est parti. Et vous regardez - cela semble être fait. Et au bout d'un moment, quand il faut affiner le code - là ça commence à cause de ça ... C'est bien qu'il ait déjà réussi à s'enfuir loin. Ce sont les gars qui, en utilisant l'exemple d'une bouteille, feront cela: vous voyez, où se trouve le fond - le verre se plie. Et il n'est pas tout à fait clair s'il est transparent ou non. Puis les «hackers» ont coupé ce fond, y ont inséré le vaisseau, puis collé à nouveau le fond, et comme si c'était nécessaire.

Du point de vue de la définition du problème, tout semble correct. Mais voici un exemple de navires: pourquoi ce navire en général, qui en a besoin? Il ne comporte aucune fonctionnalité. Habituellement, ces navires sont des cadeaux pour des personnes de très haut rang qui les placent sur une étagère au-dessus d'eux-mêmes, comme une sorte de symbole, comme un signe. Et maintenant, si une telle personne, la tête d'une grande entreprise ou un haut fonctionnaire, comment le drapeau tient-il une telle poubelle, dans laquelle le cou est coupé? Ce serait mieux s'il ne le savait jamais. Alors, comment ces navires peuvent-ils finalement être présentés à une personne importante?

Le seul endroit, clé, avec lequel il n'y a vraiment rien à faire, c'est le bâtiment. Et la coque du navire passe juste par le cou. Alors que le navire sort de la bouteille. Mais ce n'est pas seulement pour assembler un navire, c'est un véritable artisanat de bijoux. Des leviers spéciaux sont ajoutés aux composants, ce qui permet de les soulever plus tard. Par exemple, les voiles sont pliées, dérivées doucement, puis à l'aide d'une pince à épiler, c'est très bijou, bien sûr, elles sont tirées et soulevées. Le résultat est une œuvre d'art qui peut être présentée avec une conscience claire et une fierté.

Et si nous voulons que le projet réussisse, il doit y avoir au moins un bijoutier dans l'équipe. Quiconque se soucie de la qualité du produit et prend en compte tous les aspects, sans en sacrifier un seul même en période de stress, lorsque les circonstances nécessitent une urgence au détriment de l'important. Tous les projets réussis qui sont durables, qui ont résisté à l'épreuve du temps, ils sont construits sur ce principe. Ils ont quelque chose de très précis et unique, quelque chose qui utilise toutes les fonctionnalités disponibles. Dans l'exemple d'un navire dans une bouteille, il se joue que la coque du navire passe par le cou.

Revenant à la tâche de choisir notre serveur de mise en cache, comment cette méthode pourrait-elle être appliquée? Je propose une telle option parmi tous les systèmes qui existent - ne secouez pas la bouteille, ne choisissez pas, mais voyez ce que, en principe, ils ont quelque chose à rechercher lors du choix d'un système.

Où chercher un goulot d'étranglement


Essayons de ne pas secouer la bouteille, de ne pas trier tout ce qui est tour à tour, mais voyons quelles tâches surgissent, si soudainement, pour votre tâche - pour concevoir vous-même un tel système. Bien sûr, nous n'assemblerons pas le vélo, mais nous utiliserons ce schéma pour nous orienter sur les points à prendre en compte dans les descriptions de produits. Nous décrivons un tel schéma.



Si le système est distribué, nous aurons plusieurs serveurs (6). Disons quatre (il est pratique de les placer dans l'image, mais, bien sûr, il peut y en avoir un certain nombre). Si les serveurs sont sur des nœuds différents, cela signifie que du code tourne sur tous, ce qui est responsable de s'assurer que ces nœuds forment un cluster et, en cas de rupture, se connectent, se reconnaissent.

Encore 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 être à la fois dans la même JVM et y accéder via le réseau. La logique implémentée à l'intérieur est la décision des objets à laisser dans le cache, à jeter. Nous utilisons de la mémoire (3) pour stocker le cache, mais si nécessaire, nous pouvons également enregistrer une partie des données sur le disque (4).

Voyons dans quelles parties la charge va se produire. 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 interaction réseau, l'affaissement peut être assez perceptible. Deuxièmement, dans le cadre de l'API elle-même - ayant remplacé une logique complexe, nous pouvons exécuter le CPU. Et ce serait bien si la logique ne pilotait pas la mémoire une fois de plus. Et il reste une interaction avec le système de fichiers - dans la version habituelle, il est sérialisé / restauré et écrit / lu.

Poursuite de l'interaction avec le cluster. Très probablement, il sera dans le même système, mais il peut être séparé. Ici, vous devez également prendre en compte le transfert de données vers celui-ci, la vitesse de sérialisation des données et l'interaction entre le cluster.

Maintenant, d'une part, nous pouvons imaginer «quels engrenages tourneront» dans le système de cache lors du traitement des demandes de notre code, et d'autre part, nous pouvons estimer ce que et combien de demandes notre code générera à ce système. Cela suffit pour faire un choix plus ou moins sobre - choisir un système pour notre cas d'utilisation.

Hazelcast

Voyons comment cette décomposition s'applique à 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 de démarrer le serveur en tant qu'embarqué, et dans ce cas, l'accès à l'API est un appel de méthode à l'intérieur de la JVM, vous pouvez le lire gratuitement.

Pour que la logique fonctionne en (2), Hz s'appuie sur un hachage du tableau d'octets de la clé sérialisée - c'est-à-dire que la sérialisation de la clé se produit dans tous les cas. Il s'agit d'une surcharge inévitable pour Hz.
Les stratégies d'expulsion sont bien mises en œuvre, mais pour des cas particuliers - vous pouvez connecter les vôtres. Vous n'avez pas à vous soucier de cette partie.

Le stockage (4) peut être connecté. Bien. L'interaction (5) pour embarqué peut être considérée comme instantanée. L'échange de données entre les nœuds du cluster (6) - oui, c'est le cas. Cela contribue à la résilience au détriment de la vitesse. La fonction Hz de Near-cache 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 de sérialiser la clé dans (2), au-dessus de Hazelcast, vissez un autre cache pour les données les plus chaudes. Chez Sportmaster, la caféine a été choisie à cet effet.

Pour la torsion au niveau (6), Hz propose deux types de stockage: IMap et ReplicatedMap.


Il vaut la peine de dire comment Hazelcast est entré dans la pile technologique Sportmaster.

En 2012, lorsque nous avons travaillé sur le tout premier pilote du futur site, c'est Hazelcast qui s'est avéré être le premier lien émis par le moteur de recherche. La connaissance a commencé «la première fois» - nous avons été impressionnés par le fait que seulement deux heures plus tard, lorsque nous avons vissé le Hz dans le système, cela a fonctionné. Et cela a bien fonctionné. Jusqu'à la fin de la journée, nous avons ajouté quelques tests, nous étions contents. Et cet apport de vigueur a suffi à surmonter ces surprises que Hz a lancées au fil du temps. Maintenant, l'équipe Sportmaster n'a aucune raison de refuser de Hazelcast.

Mais des arguments tels que «le premier lien dans un moteur de recherche» et «HelloWorld rapidement assemblé» sont, bien sûr, une exception et une caractéristique du moment où le choix a eu lieu. Ces tests pour le système sélectionné commencent par la sortie de la prod, et c'est à ce stade que vous devez faire attention lorsque vous choisissez un système, y compris le cache. En fait, dans notre cas, nous pouvons dire que nous avons choisi Hazelcast par hasard, mais il s'est avéré que nous avons choisi la bonne.

Pour la production, c'est beaucoup plus important: surveillance, échecs de traitement sur les nœuds individuels, réplication des données, coût de la mise à l'échelle. C'est-à-dire qu'il vaut la peine de prêter attention aux tâches qui surviendront juste au moment où le système est pris en charge - lorsque la charge est dix fois plus élevée que prévu, lorsque nous remplissons accidentellement quelque chose dans la mauvaise direction, lorsque vous devez déployer une nouvelle version du code, remplacer les données et le faire inaperçu pour les clients.

Pour toutes ces exigences, Hazelcast convient parfaitement.

À suivre


Mais Hazelcast n'est pas une panacée. En 2017, nous avons choisi Hazelcast pour le cache dans le panneau d'administration, en nous appuyant simplement sur la bonne impression de l'expérience passée. Cela a joué un rôle clé dans une blague très diabolique, c'est pourquoi nous étions dans une situation difficile et nous en sommes «héroïquement» sortis pendant 60 jours. Mais plus à ce sujet dans la partie suivante.

En attendant ... Happy New Code!

More articles:


All Articles