Забезпечення узгодженості даних між кількома незалежними сервісами в розподілених системах та мікросервісних архітектурах є одним із найскладніших аспектів створення надійних застосунків. Розподілені транзакції є вирішенням цієї проблеми, гарантуячи, що операції, які охоплюють різні системи або бази даних, координуються та успішно виконуються. Але що таке розподілені транзакції, чому вони необхідні та як вони впливають на продуктивність системи?
Що таке розподілені транзакції?
Розподілені транзакції включають кілька сервісів, баз даних або систем, які повинні працювати скоординовано, щоб гарантувати, що операція буде успішно виконана через всю систему. Метою є підтримка атомарності (все або нічого) та узгодженості (гарантування точності та надійності даних), навіть коли транзакція охоплює різні вузли в розподіленому середовищі.
Простіше кажучи, розподілені транзакції дозволяють координувати операції, які мають відбутися між кількома сервісами або базами даних. Якщо якась частина транзакції не вдається, система повинна гарантувати, що всі зміни, здійснені транзакцією, будуть відкатані, зберігаючи узгодженість.
Двухфазне підтвердження (2PC)
Протокол Двухфазного підтвердження (2PC) є алгоритмом консенсусу, розробленим для гарантування, що розподілена транзакція виконується атомарно через кілька систем або баз даних. Основна мета 2PC — гарантувати, що або всі учасники транзакції підтвердять зміни (успішна транзакція), або жоден з них не підтвердить (відкат).
Як працює двухфазне підтвердження
Протокол 2PC складається з двох основних фаз: Підготовка та Підтвердження.
Двухфазне підтвердження
Фаза 1: Підготовка
- Координатор (зазвичай центральний сервіс або система, яка керує транзакцією) надсилає запит на підготовку всім системам-учасникам (так званим учасникам або голосуючим).
- Кожен учасник перевіряє, чи може він безпечно підтвердити зміни для транзакції. Це може включати перевірку операції, блокування ресурсів та перевірку відсутності конфліктів.
- Якщо учасник може підтвердити, він відповідає "так". Якщо ні, він відповідає "ні", вказуючи на помилку або конфлікт.
Фаза 2: Підтвердження або скасування
- Якщо всі учасники надіслали "так", координатор надсилає запит на підтвердження всім учасникам, інструктуючи їх завершити зміни та підтвердити транзакцію.
- Якщо хоча б один учасник відповідає "ні", координатор надсилає запит на скасування, сигналізуючи, що всі учасники повинні відкотити свої зміни, скасовуючи часткові оновлення.
- Транзакція завершується, коли або всі учасники підтвердили, або всі відкотили зміни.
Проблеми з 2PC
- Блокуюча поведінка: Якщо координатор зазнає збою після початку транзакції, учасники можуть залишатися в стані очікування нескінченно, що призводить до затримок.
- Єдина точка відмови: Координатор відіграє критичну роль у прийнятті рішень. Його збій може призупинити весь процес транзакції, що компрометує надійність.
- Розподілені мережеві помилки: У випадку мережевих розривів деякі вузли можуть пропустити фінальне рішення, що призведе до непослідовних станів, коли деякі вузли підтвердять, а інші — ні, що спричиняє неконсистентність даних.
Патерн Саги
Патерн Сага є альтернативним підходом до розподілених транзакцій, розробленим для управління довготривалими транзакціями, які не можуть бути завершені за один крок. На відміну від 2PC, який гарантує сильну узгодженість (властивості ACID), патерн Саги спрямований на випадкову узгодженість, дозволяючи системам працювати з більшою гнучкістю та стійкістю.
Як працює патерн Саги
Сага складається з серії локальних транзакцій, кожна з яких оновлює один сервіс або базу даних. Кожна транзакція в сазі може або успішно виконатися, або зазнати невдачі незалежно від інших.
Якщо транзакція не вдається, то компенсуючі транзакції ініціюються для скасування змін, виконаних попередніми транзакціями, що забезпечує поступове досягнення системою узгодженого стану.
https://burakneis.com/saga-orchestration-implementation/
Основні компоненти Саги
- Локальна транзакція: Кожен етап саги є локальною транзакцією, яка виконує частину загального бізнес-процесу. Це може бути оновлення бази даних або взаємодія з зовнішніми системами.
- Компенсуюча транзакція: Якщо локальна транзакція не вдається, виконується компенсуюча транзакція для відміни змін, зроблених попередніми етапами.
- Координація: Саги можна координувати двома способами:
- Хореографія: Кожен сервіс знає, коли викликати наступний сервіс у сага-процесі і як обробляти помилки (немає центрального координатора).
- Оркестрація: Центральний координатор визначає хід саги, і сервіси виконують дії згідно з його вказівками.
Властивості патерну Сага
- Випадкова узгодженість: Сага забезпечує, що система в кінцевому підсумку досягне узгодженого стану, навіть якщо транзакцію неможливо завершити за один крок.
- Стійкість: Оскільки кожен етап є незалежним і помилка одного етапу не блокує інші, система має більшу стійкість до відмов.
- Гнучкість: Патерн Сага дозволяє більш детально контролювати відмови та компенсуючі дії.
Висновок
Розподілені транзакції є необхідними для забезпечення узгодженості та надійності даних між кількома системами чи сервісами. Двухфазне підтвердження (2PC) та Патерн Сага є двома основними стратегіями для обробки таких транзакцій, кожна з яких має свої переваги та компроміси.
Вибір між 2PC та патерном Сага зазвичай залежить від вимог до узгодженості, масштабованості, стійкості до відмов та продуктивності в розподіленій системі. Розуміння цих протоколів і їхнього впливу на поведінку системи є ключовим для проєктування надійних і ефективних розподілених систем.
Якщо вам сподобалася ця стаття, поділіться нею з іншими, кому це може бути корисно. Слідкуйте за мною для нових статей.
https://www.linkedin.com/in/itherohit/
Перекладено з: Distributed Transactions, 2PC and Saga Pattern