Pool de connexions

Ouvrir une connexion à la base coûte cher et chacune consomme de la mémoire serveur. Un pool comme PgBouncer partage quelques connexions entre de nombreux threads applicatifs : ajouter des serveurs n'épuise plus la base.

Où on le retrouve dans les vrais systèmes

  • Base de données relationnelle

    Le primaire traite toutes les écritures ; les réplicas en lecture ajoutent de la capacité mais ont un léger retard, un utilisateur peut donc ne pas voir sa propre écriture. Un standby multi-AZ prend le relais en une minute environ si le primaire tombe. Le sharding multiplie la capacité d'écriture, mais une mauvaise clé crée un shard chaud. Sans pool de connexions, beaucoup d'instances applicatives épuisent la limite de connexions.

    En production : PostgreSQL (Amazon RDS, Aurora), MySQL, Azure SQL Database, Cloud SQL, Citus, Vitess

  • Proxy de connexions à la base

    Place-le entre tes services et une base relationnelle. Les fonctions serverless et les grandes flottes ouvrent bien plus de connexions qu'une base ne peut en accepter ; le proxy les multiplexe et raccourcit aussi les basculements en gardant les connexions pendant que le standby prend le relais.

    En production : PgBouncer, Amazon RDS Proxy, ProxySQL, Odyssey, Supavisor

Regarde-le casser, puis répare-le

Construis une architecture, envoie-lui une journée de trafic et de pannes, et comprends pourquoi elle tient ou cède. Gratuit pour commencer.

Ouvrir le parcours Ouvrir le bac à sable