Ce que nous faisons · Données et web: Cache d'objets avec failover automatique
Un cache d'objets est ce qui empêche WordPress, Magento et Laravel de poser la même question à la base de données des milliers de fois par minute. Nous le faisons tourner en trio répliqué avec promotion automatique, de sorte qu'un nœud de cache qui tombe ne se transforme jamais en base de données sans cache et surchargée.
De quoi il s'agit
Valkey (et Redis, son ancêtre compatible) garde en mémoire des résultats calculés : options, menus, données de session, résultats de requêtes, fragments rendus. Cela fait du cache une partie de votre disponibilité, pas seulement de vos performances. Une instance de cache unique est un point unique de défaillance caché, et nous n'en construisons pas.
Comment nous le construisons
- Trois nœuds, un primaire et deux réplicas, sur des hôtes séparés avec une anti-affinity stricte pour que deux d'entre eux n'atterrissent jamais sur le même matériel.
- Trois Sentinels avec un quorum de deux surveillent le primaire. S'il tombe, ils s'accordent, promeuvent un réplica et indiquent aux clients où se trouve le nouveau primaire.
- Les applications se connectent via Sentinel, en utilisant le nom du service plutôt qu'un hôte et un port fixes. Une promotion est transparente pour PHP : aucun changement de configuration, aucun redémarrage.
- Détection rapide par conception. Sentinel est réglé pour détecter un primaire mort en quelques secondes. Un bref failover inutile coûte bien moins qu'une longue fenêtre avec un primaire mort.
- De l'isolation là où elle compte. Les propriétés plus petites peuvent partager un cluster via des bases logiques séparées ; les sites grands ou critiques reçoivent leur propre instance, de sorte que l'événement de cache d'un site ne peut jamais vider celui d'un autre.
Nous intégrons aussi le côté application : le drop-in de cache d'objets WordPress configuré pour Sentinel, les drivers de cache et de session de Laravel, ou l'équivalent de votre framework.
Ce dont il vous protège
- Un serveur de cache qui tombe et chaque site derrière lui qui retombe sur la base de données d'un coup.
- Un cache partagé qui se remplit et évince les clés dont chaque site dépend.
- Le flush ou le mauvais déploiement d'un site qui vide le cache de ses voisins.
- Une intervention manuelle au milieu de la nuit pour pointer les applications vers un nouvel hôte de cache.
- Des entrées périmées qui survivent à une release, parce que nous vidons et réchauffons le cache dans chaque plan de déploiement.
En pratique
Tuer le primaire, à dessein. Sur la plateforme d'un éditeur multi-sites, nous avons arrêté le primaire du cache pendant les tests de recette. Sentinel a promu un réplica en environ six secondes et chaque site s'est rétabli tout seul, sans action humaine. Sur une plateforme d'analytique construite plus tard, le même test a mesuré environ sept secondes.
Pourquoi EuroVPS
- Le failover basé sur Sentinel par défaut, pas en option payante.
- L'anti-affinity appliquée, de sorte que les réplicas ne partagent jamais le matériel de leur primaire.
- Nous configurons aussi le côté application, pour que le failover atteigne réellement PHP.
- Chaque construction est testée en failover avant la livraison, le temps mesuré consigné par écrit.
Questions fréquentes
- Valkey ou Redis ? Valkey est un fork open source compatible Redis. Les applications et les bibliothèques clientes fonctionnent sans changement. Nous faisons tourner celui que votre stack exige.
- Notre site tombera-t-il pendant un failover du cache ? Les requêtes en vol pendant les quelques secondes de promotion peuvent manquer le cache ou réessayer. Ensuite, tout continue automatiquement sur le nouveau primaire.
- En avons-nous besoin pour un petit site ? Une instance unique convient à un petit site dont la base de données peut porter toute la charge. Dès que perdre le cache surchargerait la base, il doit être répliqué.
- Les sessions peuvent-elles y vivre ? Oui. Avec la réplication et Sentinel, les sessions survivent à la perte d'un nœud de cache.
- Pouvez-vous vous occuper de notre plugin de cache d'objets WordPress ? Oui. Nous le configurons et le maintenons dans le cadre de la stack.
Vous voulez un cache qui bascule avant que quiconque ne s'en aperçoive ? Parler à un ingénieur.
Votre prochain partenaire d'infrastructure
Examinons votre environnement.
Dites-nous ce que vous faites tourner aujourd'hui et ce qui doit s'améliorer. Un ingénieur examinera votre demande et vous aidera à planifier la suite.
+357 222 32280
Commençons par votre environnement.
Un peu de contexte nous aide à démarrer la bonne conversation.