Системний дизайн Інтерв'ю Vocabulary: Scalability, Availability, Consistency, and Partitioning
Освоєння англійської мови для інтерв’ ю з розробниками систем — шаблони масштабованості, компроміси доступності, моделі послідовності, розділення баз даних і термінологія розподілених систем.
Інтерв’ю з системним проектуванням є стільки ж тестом комунікації, скільки і технічних знань. Інтерв’ юери оцінюють, чи можете ви сформулювати компроміси, обґрунтувати вимоги і використовувати правильний словник для опису розподілених систем. Неправильне вживання слів — наприклад, «масштабування», коли ви маєте на увазі «шардування», або «доступність», коли ви маєте на увазі «стійкість» — сигналізує про прогалини у вашому розумінні. У цьому підручнику наведено точний словник, який вам слід використовувати для чіткого спілкування під час обговорення проектування системи.
Словник лексикографії
** Масштабування ** — здатність системи обробляти збільшене навантаження за допомогою додавання ресурсів. Фундаментальна відмінність полягає у горизонтальному і вертикальному масштабуванні.
** Вертикальна масштабування (збільшення) ** — збільшення обсягу пам’ яті однієї машини: більше процесора, більше ОЗП, швидше зберігання. « Ми збільшили об’ єм пам’ яті сервера бази даних з 16 ГБ до 64 ГБ ОЗП, щоб обробляти збільшене навантаження запитів ». Вертикальна масштабування має обмеження — з часом ви не зможете додавати більше об’ єму пам’ яті до однієї машини.
** Горизонтальне масштабування (розширення масштабу) ** — додавання нових машин для розподілу навантаження. « Ми розширили рівень API з 3 до 12 екземплярів за балансуванням навантаження ». Горизонтальне масштабування вимагає безстатевих служб.
** Stateless ** — служба, яка не зберігає інформацію про сеанс клієнта між запитами. Будь- який екземпляр може обробляти будь- який запит. « API має бути без стану, щоб горизонтальне масштабування працювало — дані сеансу переносяться у Redis, а не у пам’ ять. »
** Балансування навантаження ** — компонент, який розподіляє вхідні запити між декількома екземплярами сервера. « Запити розподіляються між екземплярами API за допомогою балансування навантаження шару 7 за допомогою кругової обробки »
** Прохідність ** — кількість запитів, які система може обробляти за одиницю часу, часто вимірюється у запитах на секунду (RPS) або транзакціях на секунду (TPS). « Наша мета — 10 000 RPS при максимальній прохідності. »
** Затримка ** — час між надсиланням запиту і отримання відповіді. Часто виражається як p50, p95 або p99 перцентилів. « Нам потрібна затримка p99 менше 200 мс — p99 захоплює найгірший 1% запитів, саме тут споживання ресурсів користувачем найгірше. »
** Вузький кут** — компонент системи, який обмежує загальну продуктивність. « Вузким кутом є база даних — рівень API має запасну потужність, але запитуванні є повільними. »
Доступність і надійність словарю
** Доступність ** — частка часу, протягом якого система працює і доступна. Зазвичай виражається в відсотках: 99,9% («три дев’ятки»), 99,99% («чотири дев’ятки»). «Ми потребуємо п’ять дев’яток доступності для платіжної служби — це менше 6 хвилин простою на рік»
** Надійність ** — ймовірність того, що система виконує свою призначену функцію без збоїв протягом певного періоду часу. Доступність і надійність пов’язані, але відрізняються.
** Відмінність у стійкості до помилок ** — здатність системи продовжувати працювати правильно, якщо один або декілька компонентів не працюють. « Система відмінна у стійкості до помилок: якщо одна з реплік не працює, запити автоматично перенаправляються на інші репліки, які працюють належним чином. »
** Redundancy ** — додаткові компоненти, які можуть перейняти функції у разі відмови головного. « У нас є резервування у шарі бази даних — головна і дві репліки для читання, з автоматичним відмовним переходом. »
** Відновлення після аварії ** — автоматичне або вручну перемикання на резервну систему, якщо головна система не працює. « Відновлення після аварії на допоміжну область завершено за 90 секунд під час події. »
** Одна точка відмови (SPOF) ** — компонент, відмова якого призведе до аварійного завершення роботи всієї системи. « У поточній архітектурі існує SPOF — черга повідомлень. Якщо він впаде, весь конвеєр замовлення зупиниться»
** Граціозне зниження якості ** — здатність системи продовжувати надання деяких функцій у разі відмови компонентів, а не повної відмови. « Якщо служба рекомендацій не працює, домашня сторінка все одно завантажується — на ній показано лише популярні елементи замість персоналізованих рекомендацій. » Це грациозне зневажання»
** Circuit breaker ** — шаблон, який зупиняє систему від повторних спроб виклику служби, яка не працює, надаючи їй час на відновлення. « Ми додали обмежувач до інтеграції платежів — після 5 послідовних невдач, обмежувач відкривається і ми повертаємо приємну помилку замість того, щоб збирати платежі з постачальника »
Теорія і практика гештальт-терапії
** Послідовність ** — у розподілених системах, кожне читання отримує останній запис або помилку. (Зауваження: це відрізняється від послідовності у транзакціях ACID.) « Сильна послідовність забезпечує повернення кожним вузлом однакових даних, але це вимагає певної затримки. »
** Теорема CAP ** — у розподіленій системі ви можете гарантувати не більше двох з трьох властивостей одночасно: ** Несуперечність (C) **, ** Доступність (A) ** і ** Допуск розділів (P) **. На практиці, допуск розділу є необхідним, тому справжній компроміс між послідовністю і доступністю.
** Послідовність можливих змін ** — слабша модель послідовності, за якої, якщо не буде нових оновлень, всі вузли з часом повернуть ті ж самі дані. « DNS є класичним прикладом послідовності можливих змін — зміна запису розповсюджується по всіх серверах імен протягом декількох хвилин, а не мілісекунд. »
** Сильна послідовність ** — кожне читання відображає останній запис у всіх вузлах. Потрібно для фінансових операцій. « Ми вимагаємо сильної послідовності для служби балансу рахунків — користувачі не можуть бачити застарілих балансів »
** ACID ** — властивості надійних транзакцій бази даних: ** Атомність ** (все або нічого), ** Послідовність ** (дані завжди коректні), ** Ізоляція ** (трансакції не перешкоджають), ** Тривалість ** (збережені дані зберігаються назавжди). « Ми використовуємо PostgreSQL, оскільки нам потрібні гарантії ACID для фінансових операцій. »
BASE — альтернатива ACID для розподілених систем: Basicly Available, Soft state, Eventually consistent. Часто використовується для опису баз даних NoSQL. « У аналітичному конвеєрі використовується модель BASE — ми можемо терпіти дещо застарілі дані в обмін на високу пропускну здатність запису. »
Розділення і шарування словника
** Розділення на розділи ** — розділення даних на декілька одиниць зберігання для поліпшення швидкодії і можливостей керування. Два основних типи: горизонтальне розділення (шардування) і вертикальне розділення.
** Шарування (горизонтальне розділення) ** — розділення рядків таблиці на декілька екземплярів бази даних за допомогою ключа шарування. « Ми розділимо дані користувачів за ідентифікаторами користувачів — користувачі 1— 1, 000, 000 знаходяться на шару А, 1, 000, 001— 2, 000, 000 — на шару Б. »
** Ключ шарду ** — поле, яке використовується для визначення того, до якого шарду належить запис. Вибір неправильного ключа для фрагмента призведе до появи точок доступу. « Ми обирали ідентифікатор користувача як ключ для фрагмента, оскільки обсяг запитів майже завжди обмежується одним користувачем. »
** Hotspot ** — шард, який отримує непропорційно більше трафіку, ніж інші, що обмежує масштабованість. « Використання часового штампу як ключа шарду створило точку доступу на останньому шарді — всі записи були спрямовані до одного вузла. »
** Реплікація ** — копіювання даних з одного вузла бази даних на інші вузли для зменшення обсягу і масштабування читання. « У нас є одна головна і три читання реплік — всі записи надходять до головного вузла, читання розподіляються. »
** Затримка реплікації ** — затримка між записом на головний диск і його появою на реплікації. « Під час пікового навантаження затримка реплікації може досягати 2- 3 секунд — користувачі, які читають дані відразу після запису, можуть побачити застарілі дані. »
Кэшування словника
** Кеш ** — швидкий, тимчасовий шар зберігання, який зберігає дані, до яких часто надходить доступ, щоб зменшити навантаження на повільні сервери. « Ми додали кеш Redis перед базою даних — частота пошуку у кеші становить 85%, що значно зменшило навантаження на базу даних. »
** Пошук у кеші / неможливість знайти у кеші ** — пошук у кеші відбувається, коли запит на дані знайдено у кеші; неможливість знайти у кеші означає, що кеш не містить запитуваних даних, і запит пересилається до джерела. « Частота невдалих спроб у кеші занадто висока — нам слід більш агресивно збільшити TTL або кеш »
** TTL (Time to Live) ** — час, протягом якого кешований елемент вважатиметься чинним, перш ніж його слід буде оновити. « Кеш профілю користувача має TTL 5 хвилин. »
** Правила вилучення ** — стратегія вилучення елементів з кешу, коли він заповнюється. Зазвичай використовуються такі правила: LRU (найменш використані нещодавно), LFU (найменш часто використані), FIFO (перший увійшов, перший вийшов). « Ми використовуємо вилучення LRU — найменш використані елементи вилучаються першими, коли кеш заповнюється. »
** кеш запису ** — кеш, який оновлює кеш і постійне зберігання одночасно під час кожного запису. « Кеш запису забезпечує послідовність, але додає затримку запису. »
** Кеш зворотного запису (запису) ** — кеш, який негайно підтверджує записи і асинхронно списує їх у постійне сховище. « Зворотний запис покращує пропускну здатність запису, але може призвести до втрати даних, якщо кеш не зможе виконати списання. »
Практичні вправи
-
** Імітація розігріву перед інтерв’ ю: ** Попросіть колегу запитати вас « Створити скорочення URL » і записайте себе на 10 хвилин. Перегляньте запис і визначте, коли ви використовували словник з цієї статті правильно — і коли ви повинні були використовувати точний термін, але використовували нечіткий опис.
-
** Визначення компромісу: ** Для кожної з наведених нижче пар, напишіть два речення, у яких пояснюється компроміс: (a) послідовність проти доступності, (b) горизонтальне проти вертикального масштабування, (c) кеш з перезаписом проти кешу з поверненням запису.
-
** Відображення словника архітектури: ** Знайдіть публічний блог з архітектури (кращими джерелами є технічні блоги AWS, Stripe, Netflix). Встановіть 10 слів з цієї статті у контексті.
-
** Розташування за теоремою CAP: ** Для кожної з цих систем вкажіть, чи вони надають пріоритет CP або AP, і чому: (a) послуга балансу банківського рахунку, (b) подача соціальних медіа, (c) розподілене сховище конфігурацій.
Практикуйте словниковий запас для інтерв’ю та обговорення дизайну системи з вправи на інтерв’ю на Coders Lingo.