Архитектура бэкенда
Пулинг: свободное припоминание
Припоминание сильнее перечитывания. На каждый промпт проговори или запиши полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания закрепляет материал.
Восстанови ключевые механизмы юнита — зачем нужен pool, как его размерять, что защищает acquisition timeout, почему соединения протухают, как leaks осушают pool и почему fan-in вынуждает мультиплексор — не подглядывая в уроки.
- 01Почему открытие соединения с базой дорого и какие две работы делает с этим pool?
- 02Почему подъём pool size за малое число снижает пропускную способность и какова формула размера HikariCP?
- 03Что происходит, когда запросу нужно соединение, но все заняты, и как настраивать acquisition timeout?
- 04Почему соединение pool может быть мёртвым, пока pool думает, что оно открыто, и какие три контроля держат pool свежим?
- 05Что такое connection leak, почему больший pool — плохой фикс и в чём связанная ловушка hoarding?
- 06Почему горизонтально масштабированный флот переполняет одну базу и как PgBouncer transaction pooling это решает — какой ценой?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: pool амортизирует дорогой setup и ограничивает конкурентность; его размер мал и выведен из ядер, а не угадан большим; acquisition timeout решает fail-fast vs thread starvation; соединения протухают за спиной pool и должны ротироваться по maxLifetime (под таймаутом БД) и валидироваться on borrow; самый частый отказ — leak или hoard, чинимый гарантией return, а не увеличением pool; а на масштабе многие pool сходятся в один max_connections, вынуждая transaction-pooling мультиплексор, торгующий состоянием сессии ради ratio. Соединение — жёсткий, общий, дорогой ресурс — ограничивай его осознанно на каждом слое.