Проблема гуркітливого табуна(Як звучить, га? Thundering herd, може, чули.)Так називається ситуація, де багато споживачів одночасно звертаються до одного обмеженого ресурсу.Певно, найтиповіший випадок — одночасний старт багатьох копій сервісу. Та, припустимо, цей сервіс зчитує з бази складну конфігурацію. Якщо сервіс один, все проходить непомітно. Але з декількома копіями база несподівано лягає. Під копитами гуркітливого табуна.А якщо ви покладете конфігурацію в кеш, проблема не те щоб зникає. Бо все одно всі звернуться до бази, аж поки перший запит не завершиться та в кеші не зʼявиться значення. Так само буде й після вичерпання терміну придатності кешу.Інший приклад: класична помилка планувати повторювані задачі на початок дня чи години. Чітко на нуль хвилин. Таке призводить до раптового вичерпання ресурсів системи. (Зокрема, поштові сервіси отримують пікове навантаження саме в рокові нульові хвилини.)Порятунок від гуркітливого табуна, зазвичай, це розосередження викликів. Впровадження маленької випадкової розбіжності: 1 min + rand(5) s. Уникнення монотонності. Словами Франка Герберта, walk without rhythm and it won't attract the worm.Є й інший, значно складніший вихід. Але він допоможе, коли виклики відбуваються непередбачувано. Це згортання запитів (request coalescing або request collapsing.) Власне, потрібний посередник, який буде відстежувати однакові та одночасні запити, робити лише один, та роздавати результат усім. Наприклад, цим може займатися nginx з директивою proxy_cache_lock.︙ Підтримати канал: 👑 Patreon ︙