{"id":73949,"date":"2020-03-13T02:42:07","date_gmt":"2020-03-12T23:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1"},"modified":"2020-03-13T02:42:07","modified_gmt":"2020-03-12T23:42:07","slug":"kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","title":{"rendered":"Comment nous avons choisi le syst\u00e8me de mise en cache chez Sportmaster. Partie 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour ! Je m'appelle Alexey Pyankov, je suis d\u00e9veloppeur chez Sportmaster. Dans ce article<\/a><\/noindex> j'ai parl\u00e9 de la fa\u00e7on dont le travail sur le site de Sportmaster a commenc\u00e9 en 2012, quelles initiatives nous avons r\u00e9ussi \u00e0 \u00ab propulser \u00bb et, au contraire, quels obstacles nous avons rencontr\u00e9s.<\/p>\n

Aujourd'hui, je veux partager des r\u00e9flexions qui suivent un autre sujet : le choix du syst\u00e8me de mise en cache pour le backend Java de l'administration du site. Ce sujet a une signification particuli\u00e8re pour moi \u2013 bien que l'histoire ait dur\u00e9 seulement 2 mois, nous avons travaill\u00e9 12 \u00e0 16 heures par jour sans un seul jour de repos. Je n'avais jamais pens\u00e9 ni imagin\u00e9 qu'il \u00e9tait possible de travailler autant.<\/p>\n

C'est pourquoi je divise le texte en 2 parties, pour ne pas trop surcharger. Au contraire, la premi\u00e8re partie sera tr\u00e8s l\u00e9g\u00e8re \u2013 une introduction, quelques r\u00e9flexions sur ce qu'est la mise en cache. Si vous \u00eates d\u00e9j\u00e0 un d\u00e9veloppeur exp\u00e9riment\u00e9 ou avez travaill\u00e9 avec des caches, il n'y aura probablement rien de nouveau sur le plan technique dans cet article. Mais pour un junior, un petit aper\u00e7u comme celui-ci peut lui indiquer dans quelle direction regarder, s'il se retrouve \u00e0 un tel carrefour.<\/p>\n

\"Comment<\/a><\/noindex>
\n<\/a><\/noindex>
\nLorsque la nouvelle version du site Sportmaster a \u00e9t\u00e9 mise en production, les donn\u00e9es \u00e9taient transmises d'une mani\u00e8re, pour le dire poliment, peu pratique. Des tables pr\u00e9par\u00e9es pour l'ancienne version du site (Bitrix) servaient de base, qu'il fallait int\u00e9grer dans ETL, modifier dans un nouveau format et enrichir avec divers d\u00e9tails provenant d'une dizaine de syst\u00e8mes. Pour qu'une nouvelle image ou description de produit apparaisse sur le site, il fallait attendre jusqu'au lendemain \u2013 la mise \u00e0 jour n'ayant lieu qu'une fois par nuit, une fois par jour.<\/p>\n

Au d\u00e9but, il y avait tellement de soucis durant les premi\u00e8res semaines de mise en production que ces d\u00e9sagr\u00e9ments pour les gestionnaires de contenu semblaient mineurs. Mais, une fois que tout s'est stabilis\u00e9, le d\u00e9veloppement du projet s'est poursuivi \u2013 quelques mois plus tard, d\u00e9but 2015, nous avons commenc\u00e9 \u00e0 d\u00e9velopper activement l'administration. En 2015 et 2016, tout se passait bien, nous publions r\u00e9guli\u00e8rement, l'administration couvre une partie de plus en plus importante de la pr\u00e9paration des donn\u00e9es et nous nous pr\u00e9parons \u00e0 ce que notre \u00e9quipe se voie bient\u00f4t confier la t\u00e2che la plus importante et la plus complexe : le circuit des produits (pr\u00e9paration compl\u00e8te et gestion des donn\u00e9es pour tous les produits). Mais \u00e0 l'\u00e9t\u00e9 2017, juste avant le lancement du circuit des produits, le projet se retrouvera dans une situation tr\u00e8s complexe \u2013 justement \u00e0 cause de probl\u00e8mes de mise en cache. C'est cet \u00e9pisode que je veux raconter dans la deuxi\u00e8me partie de cette publication en deux parties.<\/p>\n

Mais dans ce post, je vais commencer par le d\u00e9but, en r\u00e9sumant certaines pens\u00e9es - des id\u00e9es sur la mise en cache, qu'il serait bon d'explorer avant de se lancer dans un grand projet.<\/p>\n

Quand la question de la mise en cache se pose<\/h2>\n

\nLe besoin de mise en cache ne surgit pas par hasard. En tant que d\u00e9veloppeurs, nous cr\u00e9ons des produits logiciels et voulons qu'ils soient demand\u00e9s. Si le produit est pris\u00e9 et r\u00e9ussi, les utilisateurs affluent. Et encore et encore. \u00c0 un moment donn\u00e9, il y a tellement d'utilisateurs que le produit devient tr\u00e8s sollicit\u00e9.<\/p>\n

Au d\u00e9but, nous ne pensons pas \u00e0 l'optimisation et \u00e0 la performance du code. L'essentiel est la fonctionnalit\u00e9, il faut rapidement lancer un prototype et tester des hypoth\u00e8ses. Et si la charge augmente, nous am\u00e9liorons le mat\u00e9riel. Nous doublons, triplons, quintuple le potentiel, voire le d\u00e9cuplons. \u00c0 un certain point, les finances ne le permettront plus. Et de combien le nombre d'utilisateurs pourrait-il augmenter ? Ce ne sera pas juste 2-5-10, mais en cas de succ\u00e8s \u2014 cela pourrait aller de 100 \u00e0 1000 et jusqu'\u00e0 100 000 fois. Donc, t\u00f4t ou tard, nous devrons nous attaquer \u00e0 l'optimisation.<\/p>\n

Supposons qu'une certaine partie du code (appelons-la une fonction) prenne de mani\u00e8re inacceptable beaucoup de temps, et que nous souhaitions r\u00e9duire ce temps d'ex\u00e9cution. Une fonction peut impliquer un acc\u00e8s \u00e0 une base de donn\u00e9es, ou l'ex\u00e9cution d'une logique complexe - l'essentiel \u00e9tant qu'elle prenne beaucoup de temps. Jusqu'o\u00f9 pouvons-nous r\u00e9duire le temps d'ex\u00e9cution ? En th\u00e9orie, nous pouvons le r\u00e9duire \u00e0 z\u00e9ro, mais pas moins que cela. Comment peut-on r\u00e9duire le temps d'ex\u00e9cution \u00e0 z\u00e9ro ? R\u00e9ponse : en \u00e9liminant compl\u00e8tement l'ex\u00e9cution. \u00c0 la place, il faut juste renvoyer le r\u00e9sultat. Mais comment conna\u00eetre ce r\u00e9sultat ? R\u00e9ponse : soit le calculer, soit le consulter \u00e0 quelque part. Le calcul peut prendre du temps. Et le consulter consiste, par exemple, \u00e0 m\u00e9moriser le r\u00e9sultat que la fonction a donn\u00e9 lors de la derni\u00e8re invocation avec les m\u00eames param\u00e8tres.<\/p>\n

C'est-\u00e0-dire, la mise en \u0153uvre de la fonction ne nous importe pas. Il suffit de savoir de quels param\u00e8tres d\u00e9pend le r\u00e9sultat. Donc, si les valeurs des param\u00e8tres sont pr\u00e9sent\u00e9es sous la forme d'un objet pouvant \u00eatre utilis\u00e9 comme cl\u00e9 dans un certain stockage, nous pouvons sauvegarder le r\u00e9sultat du calcul et le r\u00e9cup\u00e9rer lors de la prochaine demande. Si ces op\u00e9rations d'enregistrement et de lecture du r\u00e9sultat sont plus rapides que l'ex\u00e9cution de la fonction, nous avons un gain en vitesse. Le gain peut atteindre 100, 1000 et m\u00eame 100 000 fois (10^5 est plut\u00f4t une exception, mais dans le cas d'une base assez lagg\u00e9e, c'est tout \u00e0 fait possible).<\/p>\n

Exigences principales pour le syst\u00e8me de cache<\/h2>\n

\nLa premi\u00e8re exigence potentielle pour un syst\u00e8me de cache est une vitesse de lecture rapide et, dans une moindre mesure, une vitesse d'\u00e9criture. C'est vrai, mais seulement jusqu'\u00e0 ce que nous d\u00e9ployions le syst\u00e8me en production.<\/p>\n

Imaginons un tel cas.<\/p>\n

Supposons que nous avons \u00e9quip\u00e9 le mat\u00e9riel pour la charge actuelle et que nous commen\u00e7ons maintenant \u00e0 introduire progressivement le cache. Le nombre d'utilisateurs augmente un peu, la charge cro\u00eet - nous ajoutons un peu de caches, les installant ici et l\u00e0. Cela dure un certain temps, et voil\u00e0, les fonctions lourdes ne sont presque plus appel\u00e9es - toute la charge principale repose sur le cache. Le nombre d'utilisateurs a augment\u00e9 de N fois pendant ce temps.<\/p>\n

Et si le stock initial de mat\u00e9riel pouvait \u00eatre de 2 \u00e0 5 fois, gr\u00e2ce au cache, nous avons pu multiplier les performances par 10 ou, dans le meilleur des cas, par 100, et parfois m\u00eame par 1000. Autrement dit, sur le m\u00eame mat\u00e9riel, nous traitons 100 fois plus de requ\u00eates. G\u00e9nial, nous avons m\u00e9rit\u00e9 une r\u00e9compense !<\/p>\n

Mais maintenant, \u00e0 un certain moment opportun, la syst\u00e8me a \u00e9chou\u00e9 et le cache s'est effondr\u00e9. Rien de particulier - le cache avait \u00e9t\u00e9 choisi selon les exigences de \u00abvitesse de lecture et d'\u00e9criture \u00e9lev\u00e9e, le reste n'est pas important\u00bb.<\/p>\n

Par rapport \u00e0 la charge initiale, nous avions un stock de mat\u00e9riel de 2 \u00e0 5 fois, et la charge a depuis augment\u00e9 de 10 \u00e0 100 fois. Gr\u00e2ce au cache, nous avons exclu les appels aux fonctions lourdes, et c'est pourquoi tout fonctionnait parfaitement. Mais maintenant, sans cache - de combien de fois notre syst\u00e8me va-t-il s'effondrer ? Que va-t-il se passer ? Le syst\u00e8me va tomber.<\/p>\n

M\u00eame si notre cache ne s'est pas effondr\u00e9, mais s'est simplement vid\u00e9 pendant un certain temps - il faudra le r\u00e9chauffer, et cela prendra un certain temps. Et durant ce temps, la charge principale retombera sur la fonctionnalit\u00e9.<\/p>\n

Sortie : les projets \u00e0 forte charge en production exigent d'un syst\u00e8me de mise en cache non seulement une vitesse de lecture et d'\u00e9criture \u00e9lev\u00e9es, mais aussi la s\u00e9curit\u00e9 des donn\u00e9es et une r\u00e9sistance aux pannes.<\/p>\n

Les douleurs du choix<\/h2>\n

\nDans le projet avec une interface d'administration, le choix s'est fait comme suit : au d\u00e9part, nous avons install\u00e9 Hazelcast, car nous \u00e9tions d\u00e9j\u00e0 familiaris\u00e9s avec ce produit gr\u00e2ce \u00e0 notre exp\u00e9rience avec le site principal. Cependant, ce choix s'est av\u00e9r\u00e9 peu judicieux : pour notre profil de charge, Hazelcast fonctionne non seulement lentement, mais atrocement lentement. Et au moment o\u00f9 nous \u00e9tions engag\u00e9s \u00e0 respecter les d\u00e9lais de mise en production, nous avions d\u00e9j\u00e0 sign\u00e9.<\/p>\n

Alerte spoiler : comment les circonstances ont fait que nous avons rat\u00e9 un tel fiasco et avons obtenu une situation aigu\u00eb et tendue - je raconterai cela dans la deuxi\u00e8me partie - et comment nous nous sommes retrouv\u00e9s et comment nous sommes sortis. Mais pour l'instant, je dirai simplement que cela a \u00e9t\u00e9 un fort stress, et \"penser - \u00e7a ne vient pas, on secoue la bouteille\". \"Secouer la bouteille\" - c'est aussi un spoiler, j'en parlerai un peu plus loin.<\/p>\n

Ce que nous avons fait :<\/p>\n

    \n
  1. Nous dressons une liste de tous les syst\u00e8mes sugg\u00e9r\u00e9s par Google et StackOverflow. Un peu plus de 30.<\/li>\n
  2. Nous \u00e9crivons des tests avec une charge caract\u00e9ristique pour la production. Pour cela, nous avons enregistr\u00e9 les donn\u00e9es qui passent par le syst\u00e8me en environnement de production - une sorte de sniffer pour les donn\u00e9es non en ligne, mais \u00e0 l'int\u00e9rieur du syst\u00e8me. Nous avons test\u00e9 exactement ces donn\u00e9es.<\/li>\n
  3. Toute l'\u00e9quipe, chacun choisit le syst\u00e8me suivant dans la liste, le configure et ex\u00e9cute les tests. Si le test \u00e9choue, si cela ne supporte pas la charge - nous le rejetons et passons au suivant.<\/li>\n
  4. Sur le 17\u00e8me syst\u00e8me, il est devenu clair que tout \u00e9tait d\u00e9sesp\u00e9r\u00e9. Assez de \"secouer la bouteille\", il est temps de r\u00e9fl\u00e9chir s\u00e9rieusement.<\/li>\n<\/ol>\n

    \nMais cela est une option lorsque vous devez choisir un syst\u00e8me qui \"passera en vitesse\" dans des tests pr\u00e9par\u00e9s \u00e0 l'avance. Et si de tels tests n'existent pas encore et que vous voulez choisir plus rapidement ?<\/p>\n

    Mod\u00e9lisons un tel cas (il est difficile d'imaginer qu'un d\u00e9veloppeur de niveau interm\u00e9daire soit dans le vide, et au moment du choix n'ait pas encore form\u00e9 de pr\u00e9f\u00e9rence quant \u00e0 quel produit essayer en premier - donc, les r\u00e9flexions suivantes rel\u00e8vent plut\u00f4t de la th\u00e9orie \/ philosophie \/ sur un junior).<\/p>\n

    Apr\u00e8s avoir d\u00e9fini les exigences, commen\u00e7ons \u00e0 choisir une solution cl\u00e9 en main. Pourquoi r\u00e9inventer la roue : nous allons prendre un syst\u00e8me de cache pr\u00eat \u00e0 l'emploi.<\/p>\n

    Si vous d\u00e9butez et que vous effectuez quelques recherches, l'ordre peut varier, mais en gros, voici ce \u00e0 quoi vous pouvez vous attendre. Vous tomberez d'abord sur Redis, car il est partout mentionn\u00e9. Ensuite, vous d\u00e9couvrirez EhCache, qui est le syst\u00e8me le plus ancien et \u00e9prouv\u00e9. Par la suite, il sera question de Tarantool - un d\u00e9veloppement national avec un aspect unique de la solution. Et aussi Ignite, car il est en pleine ascension et b\u00e9n\u00e9ficie du soutien de SberTech. Enfin, il y a aussi Hazelcast, car il appara\u00eet souvent dans le monde de l'entreprise, notamment parmi les grandes entreprises.<\/p>\n

    Cette liste n'est pas exhaustive, il existe des dizaines de syst\u00e8mes. Mais nous allons nous concentrer sur une seule. Prenons les 5 syst\u00e8mes s\u00e9lectionn\u00e9s pour un \u00ab concours de beaut\u00e9 \u00bb et faisons une s\u00e9lection. Qui sera le gagnant ?<\/p>\n

    Redis<\/h3>\n

    \nLisons ce qui est \u00e9crit sur le site officiel.
    \n    Redis<\/a><\/noindex> \u2014 projet open-source. Propose un stockage de donn\u00e9es en m\u00e9moire, la possibilit\u00e9 de sauvegarde sur disque, un partitionnement automatique, une haute disponibilit\u00e9 et une r\u00e9cup\u00e9ration apr\u00e8s les coupures r\u00e9seau.<\/p>\n

    Tout semble parfait, on peut l'adopter et l'adapter \u2014 il fait tout ce qu'on attend de lui. Mais par curiosit\u00e9, examinons les autres candidats.<\/p>\n

    EhCache<\/h3>\n

    \nEhCache<\/a><\/noindex> \u2014 \u00ab le cache Java le plus largement utilis\u00e9 \u00bb (traduction du slogan du site officiel). \u00c9galement open-source. Ici, nous r\u00e9alisons que Redis n'est pas sp\u00e9cifique \u00e0 Java mais est g\u00e9n\u00e9ral, et qu'une couche d'abstraction est n\u00e9cessaire pour interagir avec. EhCache s'av\u00e8re \u00eatre plus pratique. Que promet encore le syst\u00e8me ? Fiabilit\u00e9, \u00e9prouv\u00e9 et fonctionnalit\u00e9 compl\u00e8te. De plus, c'est le plus r\u00e9pandu. Et il met en cache des t\u00e9raoctets de donn\u00e9es.<\/p>\n

    Redis est mis de c\u00f4t\u00e9, je suis pr\u00eat \u00e0 choisir EhCache.<\/p>\n

    Mais mon sentiment patriotique me pousse \u00e0 explorer les avantages de Tarantool.<\/p>\n

    Tarantool<\/h3>\n

    \nTarantool<\/a><\/noindex> \u2014 d\u00e9crit comme une \u00ab plateforme d'int\u00e9gration de donn\u00e9es en temps r\u00e9el \u00bb. Cela semble compliqu\u00e9, alors lisons la page en d\u00e9tail et trouvons une d\u00e9claration audacieuse : \u00ab Cache 100 % des donn\u00e9es en m\u00e9moire vive \u00bb. Cela suscite des questions \u2014 car les donn\u00e9es peuvent largement d\u00e9passer la m\u00e9moire. En r\u00e9alit\u00e9, cela signifie qu'\u00e0 l'heure d'\u00e9crire des donn\u00e9es sur disque depuis la m\u00e9moire, Tarantool ne passe pas par la s\u00e9rialisation. Au lieu de cela, il utilise des caract\u00e9ristiques de bas niveau du syst\u00e8me, lorsque la m\u00e9moire est simplement mapp\u00e9e sur le syst\u00e8me de fichiers avec des performances I\/O tr\u00e8s satisfaisantes. Globalement, ils ont fait quelque chose de remarquable et d'incroyable.<\/p>\n

    Regardons les mises en \u0153uvre : Mail.ru, le r\u00e9seau corporatif, Avito, Beeline, MegaFon, Alfa-Bank, Gazprom\u2026<\/p>\n

    S'il restait des doutes concernant Tarantool, le cas d'impl\u00e9mentation chez Mastercard me confirme le contraire. Je prends Tarantool.<\/p>\n

    Mais tout de m\u00eame\u2026<\/p>\n

    Ignite<\/h3>\n

    \n\u2026 il y a encore Ignite<\/a><\/noindex>, annonc\u00e9 comme \u00ab une plateforme de calcul in-memory\u2026 vitesses in-memory sur des p\u00e9taoctets de donn\u00e9es \u00bb. Il y a aussi beaucoup d'avantages : cache distributed in-memory, le stockage key-value le plus rapide et cache, \u00e9volutivit\u00e9 horizontale, haute disponibilit\u00e9, int\u00e9grit\u00e9 stricte. En r\u00e9sum\u00e9, il s'av\u00e8re que le plus rapide \u2013 c'est Ignite.<\/p>\n

    Impl\u00e9mentations : Sberbank, American Airlines, Yahoo! Japan. De plus, j'apprends que Ignite n'est pas seulement impl\u00e9ment\u00e9 chez Sberbank, l'\u00e9quipe de SberTech envoie ses employ\u00e9s dans l'\u00e9quipe m\u00eame d'Ignite pour am\u00e9liorer le produit. Cela me convainc totalement et je suis pr\u00eat \u00e0 prendre Ignite.<\/p>\n

    Il est totalement incompr\u00e9hensible pourquoi je regarde le cinqui\u00e8me point.<\/p>\n

    Hazelcast<\/h3>\n

    \nJe vais sur le site Hazelcast<\/a><\/noindex>, je lis. Et il s'av\u00e8re que la solution la plus rapide pour le caching distribu\u00e9 \u2013 c'est Hazelcast. Il est plusieurs ordres de grandeur plus rapide que toutes les autres solutions et c'est en fait le leader dans le domaine des grilles de donn\u00e9es in-memory. Dans ce contexte, prendre quelque chose d'autre serait un manque de respect envers soi-m\u00eame. De plus, il utilise le stockage redondant des donn\u00e9es pour un fonctionnement continu du cluster sans perte de donn\u00e9es.<\/p>\n

    Voil\u00e0, je suis pr\u00eat \u00e0 prendre Hazelcast.<\/p>\n

    Comparaison<\/h2>\n

    \nMais si l'on regarde, tous les cinq candidats sont d\u00e9crits de telle sorte que chacun d'eux est le meilleur. Comment choisir ? Nous pouvons voir lequel est le plus populaire, chercher des comparaisons, et la douleur de t\u00eate dispara\u00eetra.<\/p>\n

    Nous trouvons cela la revue<\/a><\/noindex>, nous choisissons nos 5 syst\u00e8mes.<\/p>\n

    \"Comment
    \n
    \nIci, ils sont tri\u00e9s : en haut Redis, en deuxi\u00e8me position \u2013 Hazelcast, Tarantool et Ignite gagnent en popularit\u00e9, EhCache reste comme il \u00e9tait. <\/p>\n

    Mais regardons le m\u00e9thode de calcul<\/a><\/noindex>: liens vers des sites web, int\u00e9r\u00eat g\u00e9n\u00e9ral pour le syst\u00e8me, offres d'emploi \u2013 super ! Cela signifie que, quand mon syst\u00e8me va tomber, je pourrai dire : \u00ab Non, il est fiable ! Voil\u00e0 plein d'offres d'emploi\u2026 \u00bb. Une telle comparaison simple ne conviendra pas.<\/p>\n

    Tous ces syst\u00e8mes ne sont pas simplement des syst\u00e8mes de cache. Ils ont aussi beaucoup de fonctionnalit\u00e9s, notamment \u2013 lorsque ce ne sont pas des donn\u00e9es qui sont transf\u00e9r\u00e9es au client pour traitement, mais \u00e0 l'inverse : le code devant \u00eatre ex\u00e9cut\u00e9 sur les donn\u00e9es se d\u00e9place vers le serveur, y est ex\u00e9cut\u00e9, et le r\u00e9sultat est retourn\u00e9. En tant que syst\u00e8me de cache \u00e0 part enti\u00e8re, ils ne sont pas souvent regard\u00e9s.<\/p>\n

    Bien, ne nous d\u00e9courageons pas, trouvons une comparaison directe des syst\u00e8mes. Prenons les deux meilleures options \u2013 Redis et Hazelcast. Nous nous int\u00e9ressons \u00e0 la vitesse, et c'est sur ce crit\u00e8re que nous allons les comparer.<\/p>\n

    Hz vs Redis<\/h3>\n

    \nNous trouvons cela comparaison<\/a><\/noindex>:
    \n\"Comment
    \n
    \nLe bleu repr\u00e9sente Redis, le rouge Hazelcast. Hazelcast l'emporte partout, et cela est justifi\u00e9 : il est multithread\u00e9, hautement optimis\u00e9, chaque thread fonctionne avec sa propre partition, donc il n'y a pas de blocages. Redis, en revanche, est monoc\u0153ur, il ne tire pas profit des CPU modernes \u00e0 plusieurs c\u0153urs. Hazelcast utilise l'I\/O asynchrone, tandis que Redis-Jedis utilise des sockets bloquants. En fin de compte, Hazelcast emploie un protocole binaire, alors que Redis est bas\u00e9 sur du texte, ce qui le rend moins efficace.<\/p>\n

    Pour \u00eatre s\u00fbr, posons \u00e0 nouveau la question \u00e0 une autre source de comparaison. Que va-t-il nous montrer ?<\/p>\n

    Redis vs Hz<\/h3>\n

    \nEncore une autre comparaison<\/a><\/noindex>:
    \n\"Comment
    \n
    \nIci, c'est l'inverse, le rouge repr\u00e9sente Redis. Cela signifie que Redis surpasse Hazelcast en termes de performance. Dans la premi\u00e8re comparaison, Hazelcast l'emportait, dans la seconde, c'est Redis.     Ici aussi<\/a><\/noindex> il a \u00e9t\u00e9 tr\u00e8s clairement expliqu\u00e9 pourquoi Hazelcast a gagn\u00e9 dans la comparaison pr\u00e9c\u00e9dente.<\/p>\n

    Il s'av\u00e8re que le r\u00e9sultat du premier test \u00e9tait en fait truqu\u00e9 : Redis a \u00e9t\u00e9 \u00e9valu\u00e9 dans sa version de base, tandis que Hazelcast a \u00e9t\u00e9 ajust\u00e9 pour le cas de test. Donc, il s'av\u00e8re que, d'une part, personne n'est vraiment fiable, et d'autre part, lorsque nous choisissons finalement un syst\u00e8me, nous devons \u00e9galement le configurer correctement. Ces r\u00e9glages comprennent des dizaines, voire des centaines de param\u00e8tres.<\/p>\n

    Secouons la bouteille<\/h2>\n

    \nEt tout le processus que nous venons de d\u00e9crire, je peux l'expliquer par cette m\u00e9taphore : \u00ab Secouons la bouteille \u00bb. En d'autres termes, actuellement, il n'est pas n\u00e9cessaire de programmer, l'essentiel est de savoir lire stackoverflow. Dans mon \u00e9quipe, j'ai un professionnel qui fonctionne pr\u00e9cis\u00e9ment comme cela dans les moments critiques.<\/p>\n

    Que fait-il ? Il voit une chose qui ne fonctionne pas, remarque la trace de pile, prend certains mots de celle-ci (lesquels exactement, c'est son expertise dans le programme), cherche sur Google, trouve stackoverflow parmi les r\u00e9ponses. Sans lire ni r\u00e9fl\u00e9chir, parmi les r\u00e9ponses \u00e0 la question, il choisit quelque chose qui ressemble le plus \u00e0 \u00ab faire ceci ou cela \u00bb (choisir cette r\u00e9ponse est son talent, car ce n'est pas toujours celle qui a recueilli le plus de likes), applique, regarde : si quelque chose a chang\u00e9, alors c'est super. Si rien n\u2019a chang\u00e9, nous revenons en arri\u00e8re. Et nous r\u00e9p\u00e9tons le lancement-v\u00e9rification-recherche. De cette mani\u00e8re intuitive, il parvient \u00e0 faire en sorte que, apr\u00e8s 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 chose fonctionne. Et \u00ab le feu est \u00e9teint \u00bb. Maintenant, nous examinons ce que nous avons fait. Quand le programme fonctionne, c'est beaucoup plus facile. Et cela fait \u00e9conomiser beaucoup de temps.<\/p>\n

    Cette m\u00e9thode est tr\u00e8s bien expliqu\u00e9e par cet exemple.<\/p>\n

    Il fut un temps o\u00f9 il \u00e9tait tr\u00e8s populaire de construire un voilier dans une bouteille. Le voilier est grand et fragile, tandis que le goulot de la bouteille est tr\u00e8s \u00e9troit, impossible de le faire passer \u00e0 l'int\u00e9rieur. Comment le monter ?<\/p>\n

    \"Comment
    \n
    \nIl existe une m\u00e9thode, tr\u00e8s rapide et tr\u00e8s efficace.<\/p>\n

    Le bateau est compos\u00e9 de nombreux petits \u00e9l\u00e9ments : b\u00e2tons, ficelles, voiles, colle. Nous mettons tout cela dans la bouteille.
    \nNous prenons la bouteille \u00e0 deux mains et commen\u00e7ons \u00e0 secouer. Nous secouons, secouons. Et g\u00e9n\u00e9ralement, \u00e7a donne un r\u00e9sultat compl\u00e8tement rat\u00e9, bien s\u00fbr. Mais parfois. Parfois, \u00e7a donne un bateau ! Plus pr\u00e9cis\u00e9ment, quelque chose qui ressemble \u00e0 un bateau.<\/p>\n

    Nous montrons ce quelque chose \u00e0 quelqu'un : \u00ab Sergue\u00ef, tu vois !? \u00bb. Et en effet, de loin, on dirait un bateau. Mais apr\u00e8s, il ne faut pas le l\u00e2cher.<\/p>\n

    Il existe une autre m\u00e9thode. Les gars plus avanc\u00e9s, comme des hackers, l'utilisent.<\/p>\n

    J'ai confi\u00e9 une t\u00e2che \u00e0 un tel gars, il a tout fait et est parti. Et en regardant, on dirait que c'est fait. Mais au bout d'un certain temps, quand il faut retravailler le code, c'est l\u00e0 que \u00e7a commence \u00e0 devenir compliqu\u00e9 \u00e0 cause de lui... Heureusement, il avait d\u00e9j\u00e0 eu le temps de s'\u00e9loigner. Ce sont ces gars qui, sur l'exemple de la bouteille, font \u00e7a : voyez, l\u00e0 o\u00f9 se trouve le fond, le verre se courbe. Et il n'est pas tout \u00e0 fait clair s'il est transparent ou non. Alors, les \u00ab hackers \u00bb coupent ce fond, ins\u00e8rent le bateau \u00e0 l'int\u00e9rieur, recollent ensuite le fond, et \u00e7a a l'air comme si c'\u00e9tait pr\u00e9vu.<\/p>\n

    D'un point de vue de formulation de t\u00e2che, cela semble tout \u00e0 fait correct. Mais en ce qui concerne les bateaux : \u00e0 quoi bon construire ce bateau, \u00e0 qui en a-t-on vraiment besoin ? Il n'a aucune fonctionnalit\u00e9. En g\u00e9n\u00e9ral, ces bateaux sont des cadeaux pour des personnes tr\u00e8s haut plac\u00e9es, qui les mettent sur une \u00e9tag\u00e8re, comme un symbole, un signe. Et si une telle personne, un directeur d'une grande entreprise ou un fonctionnaire de haut rang, a un tel produit de qualit\u00e9 inf\u00e9rieure, avec le goulot coup\u00e9, cela serait mieux qu'il n'en sache jamais rien. Alors, comment fabriquent-ils ces bateaux qui peuvent \u00eatre offerts \u00e0 une personne importante ?<\/p>\n

    Le seul endroit, cl\u00e9, avec lequel il n'y a vraiment rien \u00e0 faire, c'est la coque. Et la coque du navire passe pr\u00e9cis\u00e9ment par le goulot. Alors que le navire est assembl\u00e9 en dehors de la bouteille. Mais ce n'est pas simplement assembler le navire, c'est un v\u00e9ritable art de la bijouterie. Des leviers sp\u00e9ciaux sont ajout\u00e9s aux pi\u00e8ces qui permettent de les soulever par la suite. Par exemple, les voiles sont pli\u00e9es, soigneusement mises \u00e0 l'int\u00e9rieur, et ensuite, \u00e0 l'aide d'une pince, elles sont tr\u00e8s d\u00e9licatement, pr\u00e9cis\u00e9ment, tir\u00e9es et lev\u00e9es. En guise de r\u00e9sultat, on obtient une \u0153uvre d'art, que l'on peut offrir avec une conscience tranquille et fiert\u00e9.<\/p>\n

    Et si nous voulons que le projet soit r\u00e9ussi - il doit y avoir au moins une personne bijoutier dans l'\u00e9quipe. Celui qui se soucie de la qualit\u00e9 du produit et prend en compte tous les aspects, sans sacrifier aucun, m\u00eame dans des moments de stress, lorsque les circonstances exigent de faire quelque chose en urgence au d\u00e9triment de l'important. Tous les projets r\u00e9ussis, qui sont durables, qui ont r\u00e9sist\u00e9 \u00e0 l'\u00e9preuve du temps, sont construits sur ce principe. Ils ont quelque chose de tr\u00e8s pr\u00e9cis et unique, quelque chose qui utilise toutes les possibilit\u00e9s disponibles. Dans l'exemple du navire dans une bouteille - cela joue sur le fait que la coque du navire passe par le goulot.<\/p>\n

    Revenant \u00e0 la t\u00e2che de choisir notre serveur de mise en cache, comment ce proc\u00e9d\u00e9 pourrait-il \u00eatre appliqu\u00e9 ? Je propose une option de s\u00e9lection parmi tous les syst\u00e8mes disponibles : ne pas secouer la bouteille, ne pas choisir, mais examiner ce qu'il y a fondamentalement dans chacun d'eux, les points \u00e0 consid\u00e9rer lors du choix du syst\u00e8me.<\/p>\n

    O\u00f9 chercher le goulet d'\u00e9tranglement<\/h2>\n

    \nEssayons de ne pas secouer la bouteille, ne pas passer en revue tout ce qu'il y a, mais examinons les t\u00e2ches qui pourraient survenir si, par hasard, pour notre t\u00e2che - nous devions concevoir un tel syst\u00e8me par nous-m\u00eames. Bien s\u00fbr, nous ne reconstruirons pas le v\u00e9lo, mais nous utiliserons ce sch\u00e9ma pour nous orienter sur quels points pr\u00eater attention dans les descriptions des produits. \u00c9bauchons un tel sch\u00e9ma.<\/p>\n

    \"Comment
    \n
    \nSi le syst\u00e8me est distribu\u00e9, alors nous aurons plusieurs serveurs (6). Supposons quatre (pratique \u00e0 repr\u00e9senter sur l'image, mais bien s\u00fbr, il peut y en avoir autant que n\u00e9cessaire). Si les serveurs sont sur diff\u00e9rents n\u0153uds, cela signifie que certains codes tournent sur chacun d'eux, responsables de l'agencement de ces n\u0153uds en un cluster et, en cas de rupture - se connectant, se reconnaissant mutuellement.<\/p>\n

    Il faut encore un code de logique (2) qui concerne le cache. Ce code interagit avec les clients via une certaine API. Le code client (1) peut \u00eatre ex\u00e9cut\u00e9 \u00e0 l'int\u00e9rieur de la m\u00eame JVM ou l'appeler \u00e0 distance. La logique mise en \u0153uvre d\u00e9termine quels objets conserver dans le cache et lesquels \u00e9liminer. Pour stocker le cache, nous utilisons la m\u00e9moire (3), mais si n\u00e9cessaire, nous pouvons \u00e9galement sauvegarder certaines donn\u00e9es sur le disque (4).<\/p>\n

    Examinons o\u00f9 la charge va appara\u00eetre. En fait, chaque fl\u00e8che et chaque n\u0153ud va \u00eatre charg\u00e9. Tout d'abord, entre le code client et l'API, si c'est une interaction r\u00e9seau, le ralentissement peut \u00eatre assez perceptible. Deuxi\u00e8mement, \u00e0 l'int\u00e9rieur m\u00eame de l'API - si nous complexifions trop la logique, nous pouvons \u00eatre limit\u00e9s par le CPU. Il serait pr\u00e9f\u00e9rable que la logique ne sollicite pas la m\u00e9moire inutilement. Et il reste l'interaction avec le syst\u00e8me de fichiers - g\u00e9n\u00e9ralement, cela consiste \u00e0 s\u00e9rialiser \/ r\u00e9cup\u00e9rer et \u00e9crire \/ lire.<\/p>\n

    Ensuite, l'interaction avec le cluster. Tr\u00e8s probablement, il sera sur le m\u00eame syst\u00e8me, mais il peut aussi \u00eatre s\u00e9par\u00e9. Ici, il faut \u00e9galement prendre en compte le transfert de donn\u00e9es vers lui, la vitesse de s\u00e9rialisation des donn\u00e9es et l'interaction entre le cluster.<\/p>\n

    Maintenant, d'une part, nous pouvons visualiser \u00abquelles roues vont tourner\u00bb dans le syst\u00e8me de cache lors du traitement des requ\u00eates de notre code, et d'autre part, nous pouvons estimer quels types et combien de requ\u00eates notre code g\u00e9n\u00e9rera vers ce syst\u00e8me. C'est suffisant pour faire un choix plut\u00f4t \u00e9clair\u00e9 - adapter le syst\u00e8me \u00e0 notre cas d'utilisation.<\/p>\n

    Hazelcast<\/b><\/p>\n

    Voyons comment appliquer ce type de d\u00e9composition \u00e0 notre liste. Par exemple, Hazelcast.<\/p>\n

    Pour stocker \/ r\u00e9cup\u00e9rer des donn\u00e9es de Hazelcast, le code client fait appel (1) \u00e0 l'API. Hz permet de d\u00e9marrer le serveur en mode embarqu\u00e9, et dans ce cas, l'appel \u00e0 l'API est un appel de m\u00e9thode \u00e0 l'int\u00e9rieur de la JVM, ce qui peut \u00eatre consid\u00e9r\u00e9 comme gratuit.<\/p>\n

    Pour que la logique dans (2) fonctionne, Hz s'appuie sur le hachage d'un tableau de bytes s\u00e9rialis\u00e9 comme cl\u00e9 - en d'autres termes, la s\u00e9rialisation de la cl\u00e9 se produira dans tous les cas. C'est une surcharge in\u00e9vitable pour Hz.
    \nLes strat\u00e9gies d'\u00e9viction sont bien mises en \u0153uvre, mais pour des cas particuliers, on peut brancher les siennes. Il n'y a pas lieu de s'inqui\u00e9ter pour cette partie.<\/p>\n

    Le stockage (4) peut \u00eatre connect\u00e9. Excellent. L'interaction (5) pour embedded peut \u00eatre consid\u00e9r\u00e9e comme instantan\u00e9e. L'\u00e9change de donn\u00e9es entre les n\u0153uds du cluster (6) \u2013 oui, cela existe. C'est une contribution en faveur de la r\u00e9silience au prix de la vitesse. La fonction Hz Near-cache permet de r\u00e9duire le co\u00fbt \u2013 les donn\u00e9es obtenues \u00e0 partir d'autres n\u0153uds du cluster seront mises en cache.<\/p>\n

    Que peut-on faire dans de telles conditions pour augmenter la vitesse?<\/p>\n

    Par exemple, pour \u00e9viter la s\u00e9rialisation de la cl\u00e9 dans (2) \u2013 ajouter un autre cache au-dessus de Hazelcast pour les donn\u00e9es les plus chaudes. Chez Sportmaster, ils ont choisi Caffeine pour cet objectif.<\/p>\n

    Pour le tuning au niveau (6), deux types de stockage sont propos\u00e9s dans Hz : IMap et ReplicatedMap.
    \n\"Comment
    \n
    \nIl convient de dire comment Hazelcast est entr\u00e9 dans la pile technologique de Sportmaster.<\/p>\n

    En 2012, lorsque nous travaillions sur le tout premier pilote du futur site, c'est Hazelcast qui s'est av\u00e9r\u00e9 \u00eatre le premier lien fourni par le moteur de recherche. La rencontre s'est faite \u00e0 'premi\u00e8re vue' - ce qui nous a s\u00e9duits, c'est qu'apr\u00e8s seulement deux heures d'int\u00e9gration de Hz dans le syst\u00e8me - il fonctionnait. Et \u00e7a fonctionnait bien. D'ici la fin de la journ\u00e9e, nous avons ajout\u00e9 plusieurs tests, ravis. Et cet \u00e9lan nous a permis de surmonter les surprises que Hz a r\u00e9v\u00e9l\u00e9es avec le temps. Actuellement, l'\u00e9quipe de Sportmaster n'a aucune raison de se s\u00e9parer de Hazelcast.<\/p>\n

    Mais des arguments tels que 'premier lien dans le moteur de recherche' et 'nous avons rapidement construit HelloWorld' - sont bien s\u00fbr l'exception et le contexte particulier dans lequel s'est d\u00e9roul\u00e9 le choix. Les v\u00e9ritables \u00e9preuves pour le syst\u00e8me choisi commencent avec le passage en production, et c'est \u00e0 cette \u00e9tape qu'il faut pr\u00eater attention lors du choix de tout syst\u00e8me, y compris le cache. En fait, dans notre cas, on peut dire que nous avons choisi Hazelcast par hasard, mais il s'est av\u00e9r\u00e9 que nous avons fait le bon choix.<\/p>\n

    Pour la production, il est beaucoup plus important : la surveillance, le traitement des pannes sur des n\u0153uds individuels, la r\u00e9plication des donn\u00e9es, le co\u00fbt de mise \u00e0 l'\u00e9chelle. En d'autres termes, il faut pr\u00eater attention aux probl\u00e8mes qui surgiront lors de l'exploitation du syst\u00e8me - lorsque la charge d\u00e9passera de plusieurs dizaines de fois la charge pr\u00e9vue, lorsque nous t\u00e9l\u00e9chargerons accidentellement quelque chose de faux et au mauvais endroit, lorsque nous devrons d\u00e9ployer une nouvelle version du code, remplacer des donn\u00e9es et le faire sans que les clients le remarquent.<\/p>\n

    Pour tous ces besoins, Hazelcast convient sans aucun doute.<\/p>\n

    \u00c0 suivre<\/h2>\n

    \nMais Hazelcast n'est pas une panac\u00e9e. En 2017, nous avons choisi Hazelcast pour le cache de l'interface d'administration, simplement sur la base d'une bonne impression d'exp\u00e9riences pass\u00e9es. Cela a jou\u00e9 un r\u00f4le cl\u00e9 dans une tr\u00e8s mauvaise blague, ce qui nous a mis dans une situation difficile et nous avons mis 60 jours \u00e0 en sortir \u00ab h\u00e9ro\u00efquement \u00bb. Mais nous en parlerons dans la prochaine partie.<\/p>\n

    En attendant\u2026 Joyeux Nouveau Code !
    \n
    Source :     habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440. \u0412 \u044d\u0442\u043e\u043c \u043f\u043e\u0441\u0442\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0430\u0441\u044c \u0440\u0430\u0431\u043e\u0442\u0430 \u043d\u0430\u0434 \u0441\u0430\u0439\u0442\u043e\u043c \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440 \u0432 2012 \u0433\u043e\u0434\u0443, \u043a\u0430\u043a\u0438\u0435 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u0438\u0432\u044b \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u00ab\u043f\u0440\u043e\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u00bb \u0438 \u043d\u0430\u043e\u0431\u043e\u0440\u043e\u0442, \u043a\u0430\u043a\u0438\u0435 \u0433\u0440\u0430\u0431\u043b\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0445\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u043c\u044b\u0441\u043b\u044f\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043b\u0435\u0434\u0443\u044e\u0442 \u0437\u0430 \u0434\u0440\u0443\u0433\u0438\u043c \u0441\u044e\u0436\u0435\u0442\u043e\u043c \u2013 \u0432\u044b\u0431\u043e\u0440 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0434\u043b\u044f java-\u0431\u044d\u043a\u0435\u043d\u0434\u0430 \u0432 \u0430\u0434\u043c\u0438\u043d\u043a\u0435 \u0441\u0430\u0439\u0442\u0430. \u042d\u0442\u043e\u0442 \u0441\u044e\u0436\u0435\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":73950,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-73949","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Comment nous avons choisi un syst\u00e8me de mise en cache chez Sportmaster. Partie 1 | ProHoster","description":"Bonjour ! Je m'appelle Alexe\u00ef Piankov, je suis d\u00e9veloppeur chez Sportmaster.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u0432 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440\u0435 \u0432\u044b\u0431\u0438\u0440\u0430\u043b\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-12T23:42:07+00:00","article:modified_time":"2020-03-12T23:42:07+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"73949","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:23:51","updated":"2022-09-28 05:05:57","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/73949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=73949"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/73949\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/73950"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=73949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=73949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=73949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}