Як уникнути "повторних штормів" у розподілених службах?

"Повторний шторм" викликається, коли клієнти налаштовані повторно спробувати задану кількість разів перед тим, як відмовитись, необхідна політика повторної дії, оскільки втрата пакетів відбудеться в нормальній роботі сервісу.

Візьмемо цей приклад:

Якщо, наприклад, послуги в цілому були розширені, щоб підтримувати 80 000 запитів в секунду і запускати приблизно 80% потужності, сплеск трафіку, який спричинив отримання сервісом 101 000 запитів в секунду, призведе до відмови 1000 таких запитів.

Коли розпочнеться повторна політика, ви отримуєте додаткові 1000+ запитів, залежно від того, де виявлено збій, який підштовхне службу в цілому до 102 000 запитів в секунду - звідти ваша послуга переходить у спіраль смерті, подвоюючи число невдалих запитів щосекунди.

Окрім масового перевиконання послуг за межі прогнозованої пікової транзакції, що було б неефективно. Які стратегії ви можете використовувати, щоб уникнути "повторних штормів"?

Це залежить від того, чого ви намагаєтеся уникати.

Якщо ви намагаєтесь уникнути будь-якого переривання сервісу чогось, що є справді критичною послугою (я думаю, що з точки зору "люди помруть, якщо мій дзвінок API не буде належним чином обслужений"), вам потрібно просто сплатити бюджет на величезну неефективність, здебільшого надходять через забезпечення виділених ресурсів. І так, вони повинні бути присвячені, і нічого з цього не передбачає скорочення трафіку, багаторазове скорочення послуг не призвело б до відключення.

У набагато більш імовірному сценарії, коли ви знижуєте службу, було б незручно, ви можете вирішити проблему як з боку клієнта, так і з боку сервера. Хоча варто зазначити, що фактично вирішити проблему великого трафіку логічно неможливо, оскільки без обробки трафіку (який споживає ресурси) ви не можете знати, чи це повтор, якщо це повторне запит, який був успішним, але неправильно оброблений. клієнтом, якщо це DDOS тощо. Але ви можете пом'якшити вплив.

У клієнтському коді запишіть розумну логіку повторної спроби, яка має верхню межу та механізм витонченої відмови. Таким чином, ви не стикаєте своїх користувачів у нескінченному циклі відмовних запитів, а ви просто даєте їм помилку, кажучи їм спробувати все, що вони просто зробили за короткий час.

Для інфраструктури на вашому сервері найпростішим рішенням є дросель. Жорсткі обмеження щодо запитів, особливо якщо ви можете спробувати і поширити їх логічно, залежно від конкретного випадку використання (тобто. Якщо у вас централізована служба приймає важкі рішення, чи хочете ви почати блокувати географічно віддалені запити, які можуть спричинити зависання потоків Сторінка сервера? Або ви хочете рівномірно розподілити свій неминучий, але незначний збій? І т. д.) Це в основному зводиться до того, що навмисне повернення 503 з шлюзу - це пекло набагато дешевше, ніж пропускати запит і надсилати номер 504 все одно. В основному змушуйте клієнтів вести себе на основі того, що ви можете на даний момент надати, і надати правильні відповіді, щоб клієнти могли відповідним чином реагувати.

Одним із способів запобігання цих повторних штормів є використання механізмів баккоффа.

У розділі " Реалізувати" в розділі " Повторити спробу " в посібнику " Розробка дизайну додатків Google" для посібника масштабу :

Ваш код може повторно повторитись, незважаючи на виклик такої служби, як Cloud Datastore або зовнішньої служби за допомогою URL Fetch або API Socket. У цих випадках ви завжди повинні проводити рандомізовану експоненціальну політику відновлення, щоб уникнути громоздатної проблеми із стадом . Вам також слід обмежити загальну кількість повторних спроб та несправності після досягнення максимальної межі спроб.

Більшість API-програм GAE вже мають такі механізми / політики зворотного зв’язку, включені за замовчуванням.