Посібник для манекена з розподілених черг

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

Добре, давайте займемось цим!

Перш за все, навіщо потрібен брокер черг / повідомлень?

Історія про те, як черга врятувала лимонад

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

Ваш веб-додаток має кінцеву точку, скажімо yourlemonade.com/traffic, і кожен раз, коли ви натискаєте кнопку, кількість трафіку збільшується на 1. Красиво.

Коли трафік до вашого стенду для лимонаду збільшується, ви натискаєте кнопку все більше і більше. Ну, оскільки ви живете у порівняно невеликому районі, ви отримуєте лише 10–20 людей на день. Ваші продажі тривають, як зазвичай, веб-додаток чудово обробляє трафік, і все чудово і чудово. Ідеально

Кошмар бурхливого бізнесу

Тепер, коли ваш стенд для лимонаду зарекомендував себе, люди з усього міста з’їжджаються, щоб скуштувати ваш знаменитий лимонад. І в прекрасний недільний ранок місцеві новини вирішили рекламувати ваш стенд, і дорожній рух ВИБУХАЄ .

Як ви можете собі уявити, трафік до вашого стенду для лимонаду збільшується з 10–20 людей на день до 10 000 на день. Ви несамовито натискаєте кнопку трафіку, що, в свою чергу, викликає дзвінок на вашlemonade.com/traffic, і ваша веб-програма продовжує збільшувати обсяг трафіку.

На жаль, ваш веб-додаток розміщений на 8-бітному 128-мегабайтному сервері оперативної пам'яті в гаражі вашого будинку. В умовах бурхливого бізнесу та збільшення трафіку ваш веб-додаток більше не може обробляти масштаби трафіку.

Зрештою, ваш сервер гине. ☠️

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

Що ти робиш?

Черга на порятунок

Хвилинка блиску вражає вас, а що, якщо я поставлю коробку перед прилавком, куди кожен клієнт може просто опустити записку про те, що вони там були?

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

Це те, що ми називаємо асинхронною обробкою , і ласкаво просимо до світу черг . ?

Коли ви починаєте розробляти програмне забезпечення, подібно до підставки для лимонаду, про яку я згадав вище, це звичайне завдання

  1. зателефонуйте у службу, тоді
  2. дочекайтеся закінчення служби, а потім
  3. перейти до наступного завдання.

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

Якщо черга така потужна, чому б нам просто не поставити її перед усім?

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

Кілька запитань, які я б поставив перед тим, як вирішити, чи є черга правильним рішенням для вас:

  • Чи є у вашої служби проблеми через високий трафік? Якщо це не так, можливо, вам слід вивчити, що таке вузьке місце, перш ніж переходити до черг. Як знаменито сказав Дональд Кнут, передчасна оптимізація - корінь усього зла.
  • Чи маєте ви власні знання з управління чергою? Або вам потрібно потенційно найняти команду, яка зробить це за вас? Витрати на обслуговування, як масштабування черги, можуть злетіти, якщо ви не будете обережні. Існують такі послуги, як Amazon SQS (Проста служба обслуговування в черзі), які пропонують кероване рішення (тобто вам не потрібно нічого підтримувати самостійно).
  • Чи можна мати дублікати записів у черзі? Якщо так, чи це прийнятно?
  • Вам потрібно вести облік усіх транзакцій, на випадок, якщо черга впаде?
  • У випадку, коли черга опускається, чи потрібно черзі мати можливість відтворити всі записи? Які варіанти резервного копіювання?

Є набагато більше проблем, які можуть бути специфічними для вашого випадку використання, але, сподіваюся, я твердив, що додавати чергу не так просто, як клацнути пальцями.

Як черги використовуються в сучасній архітектурі

Черги всюдисущі в сучасній сучасній архітектурі розподілених систем - прийняті в різних галузях для різних випадків використання, і з кожним днем ​​все більше нових випадків використання.

Ось деякі випадки реального використання черг:

Трансляція в режимі реального часу

Коли MapReduce з’явився, це було величезним явищем у галузі, оскільки це дозволяло простим смертним обробляти петабайти даних за розумний проміжок часу, де завгодно - від днів до годин. Сьогодні це може здатися абсурдом, коли дані доступні майже за секунди, але до MapReduce було непросто витягти корисні дані з надзвичайно великих наборів даних.

Апетит до аналітики даних зріс, і зараз ми розглядаємо обробку даних протягом годин, а іноді і мілісекунд .

Для постійного досягнення аналітики та ефективності з низькою затримкою була задумана концепція потокового передавання в реальному часі.

Корисним прикладом тут є думка про рекламу: реклама в Twitter, наприклад, показується мільйонам людей на день. Однак для того, щоб переконатись, що користувачі не бачать одних і тих самих оголошень кілька разів протягом встановленого періоду часу, Twitter повинен якось знати, коли останній раз користувач потрапляв до певної реклами.

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

Деякі технології, про які ви часто чуєте у випадках потокового використання в режимі реального часу, це Kafka, потоки Kafka, Redis, Spark Streaming (що відрізняється від Spark) тощо.

Архітектура, керована подіями

Черги використовуються як важливий компонент архітектури, керованої подіями, або розмовно відомий як Pub (lisher) - Sub (scriber). Архітектура, керована подіями, згідно Вікіпедії:

Архітектура, керована подіями (EDA) - це шаблон архітектури програмного забезпечення, що сприяє виробленню, виявленню, споживанню та реагуванню на події.

Я хотів би думати про це як про підписку на розсилку новин: як виробник розсилки ви знаєте, хто підписався на вашу розсилку, а хто ні. Ви пишете вміст, а потім надсилаєте його своїм передплатникам.

З іншого боку, як абонент, ви можете підписатись на декілька бюлетенів, але ви не знаєте, хто інші абоненти. Але вас насправді це не хвилює. Це дійсно приємна функція, адже тепер ви можете писати програмне забезпечення, яке прослуховує купу подій і реагує лише на ті, які вас цікавлять.

RabbitMQ і Amazon SQS (проста служба обслуговування в черзі) - це деякі технології, які часто використовуються для таких типів випадків використання.

Розподілена, відмовостійка, масштабована інфраструктура

Розподілені системи схильні до помилок, і черга є одним із декількох способів підвищення стійкості в архітектурі. В архітектурі мікросервісу (або архітектурі, орієнтованій на послуги), багато мікросервіси взаємодіють між собою через черги як спільні інтерфейси.

Коли мікросервіс несподівано виходить з ладу, черга все ще може приймати повідомлення. Це, по суті, забезпечує буфер для відновлення нашої мікросервіси. Як тільки мікросервіс повернеться в Інтернет, він зможе забрати повідомлення з черги та обробити їх знову.

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

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

Ресурси, які я рекомендую

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

  • Розробка додатків, що обробляють дані: Чудова книга для вивчення масштабування розподілених систем! Настійно рекомендується.
  • Посібник Кафки: Я використав цю книгу як довідковий посібник і насолоджувався нею для опису на високому рівні.
  • Kafka Streams: Це інформативна стаття від Confluent, яка детально розповідає про реалізацію Kafka потокової обробки.
  • Елементи програмування інтерв’ю: чудово підходить для вирішення проблем кодування.
  • Cracking The Coding Interview: Чудово підходить для висвітлення основних проблем кодування CS.
  • Щоденне кодування Problem.com: Це безкоштовний веб-сайт, який пропонує безкоштовні щоденні проблеми з кодуванням. Ви можете підписатись на цікаві щоденні завдання кодування, і можете заплатити за рішення, якщо хочете. Якщо ви використовуєте моє реферальне посилання (dailycodingproblem.com/zhiachong), ви отримуєте знижку 10 доларів!

(FYI, я розподіляю більше ресурсів на своєму веб-сайті: zhiachong.com, де я особисто пробував і тестував, і рекомендую інженерам програмного забезпечення всіх рівнів.)

На здоров’я!