Aller au contenu

Bases de données Mis à jour le 2026-05-29

Memcached

Référence opérationnelle de Memcached sur Stack Harbor PaaS — provisionnement, configuration, allocation mémoire et partage de sessions PHP.

Memcached est un magasin clé-valeur en mémoire distribué utilisé comme cache en frontal d’un magasin plus lent. Stack Harbor PaaS l’expose comme un nœud d’environnement avec lequel tout palier applicatif dans le même environnement peut dialoguer via le protocole binaire ou texte standard de Memcached.

Cette page est l’entrée de la documentation Memcached. Le reste de la section couvre la référence opérationnelle par sujet.

Ce qui est couvert

  • Le système de cache Memcached — ce qu’est Memcached et le modèle de déploiement.
  • Configuration Memcached — /etc/sysconfig/memcached et les flags d’exécution.
  • Allocation mémoire Memcached — comment fonctionnent les slabs et les pages.
  • Sessions PHP dans Memcached — utiliser Memcached comme handler de session PHP.
  • Réplication de sessions via Memcached — magasin de sessions partagé entre serveurs applicatifs.

Questions fréquentes

À quoi sert Memcached ? Un cache mémoire distribué. Il réduit la charge sur la base et accélère les réponses applicatives en servant les valeurs fréquemment lues depuis la mémoire.

Les données Memcached sont-elles persistantes ? Non. Memcached stocke uniquement en mémoire. Un redémarrage supprime toutes les valeurs en cache. Traiter Memcached comme un cache, pas comme un magasin primaire — écrire de façon traversante vers la base, lire depuis Memcached quand présent, retomber sur la base quand absent.

Comment la mémoire est-elle allouée ? Memcached utilise un allocateur en slabs — des morceaux de taille fixe par classe de slab — plutôt qu’une allocation par item. Cela rend l’allocateur immunisé à la fragmentation quand les clés expirent et que les morceaux sont réutilisés. Voir Allocation mémoire Memcached pour les détails.

Puis-je utiliser Memcached pour la réplication de sessions ? Oui — Memcached comme magasin de sessions partagé est un patron standard pour garder les sessions web cohérentes sur un palier applicatif multi-nœuds.

Provisionnement

Memcached est proposé comme module d’environnement quand vous créez l’environnement dans l’assistant de topologie. Choisir votre serveur applicatif (Tomcat, Apache PHP, NGINX PHP, Node.js, ce qui convient), activer Memcached dans la même étape de l’assistant, définir la limite de cloudlets sur le nœud Memcached, créer l’environnement.

Après création, Memcached est disponible sur le port 11211 (par défaut) sur le CNAME ou l’IP privée du nœud Memcached — mêmes règles d’hôte de connexion que tout autre conteneur base de données.

Quand utiliser Memcached

  • Cache de requêtes base de données. Cacher le résultat d’une requête coûteuse sous une clé dérivée des paramètres de la requête. Frapper Memcached d’abord, retomber sur la base au manqué.
  • Magasin de sessions. Remplacer un magasin de sessions mono-nœud par un Memcached partagé, pour que les utilisateurs ne perdent pas leurs sessions quand le trafic est équilibré sur plusieurs nœuds applicatifs.
  • Cache d’objets. Cacher des fragments de template rendus, des réponses d’API, ou tout autre objet sérialisable coûteux à recalculer et fréquemment accédé.

Pour un cache plus durable (qui survit à un redémarrage), utiliser Redis — Redis a le même modèle clé-valeur avec persistance optionnelle.

Ce que Memcached n’est pas

  • Une base de données. Pas de persistance ; un redémarrage perd les données.
  • Un système pub/sub. Memcached n’a pas la notion de canaux ou d’abonnés. Utiliser Redis pour le pub/sub.
  • Une file d’attente. Memcached n’a pas d’opérations atomiques sur listes au-delà de prepend et append. Utiliser Redis ou une file dédiée (RabbitMQ, NATS) pour la sémantique de file.
  • Un magasin pour des données sensibles. Memcached n’a pas d’authentification en déploiement par défaut, ni de TLS. Le garder sur le réseau privé et le traiter comme non sûr au regard de qui peut lire.

Voir aussi