Специфікація XA
XA — це специфікація інтерфейсу (тобто функція інтерфейсу) між транзакційним проміжним програмним забезпеченням і базою даних, визначеною X/Open DTP, яка використовується транзакційним проміжним програмним забезпеченням для повідомлення бази даних про початок, завершення, фіксацію, відкат тощо транзакцій. Функції інтерфейсу XA надають постачальники баз даних.
Угода про подання другого порядку та угода про подання третього порядку були виведені з цієї ідеї. Можна сказати, що двоступеневі коміти насправді є ключем до реалізації розподілених транзакцій XA (точніше: двоступеневі коміти переважно забезпечують атомарність розподілених транзакцій: тобто всі вузли або виконують усе, або нічого)
2PC
Двофазний коміт — це алгоритм, розроблений для підтримки узгодженості транзакційних комітів для всіх вузлів на основі розподіленої системної архітектури у сфері комп'ютерних мереж і баз даних. Часто двоетапне фіксування також називають протоколом. У розподіленій системі кожен вузол може знати успіх чи невдачу власної операції, але не може знати успіх чи невдачу операцій інших вузлів. Коли транзакція охоплює кілька вузлів, для підтримки характеристик ACID необхідно ввести компонент, який виконує роль координатора для контролю результатів усіх вузлів (які називаються учасниками) і врешті-решт інструктує ці вузли фактично подавати результати (наприклад, записувати оновлені дані на диск тощо). Отже, ідею алгоритму двоетапного подання можна підсумувати так: учасники повідомляють координатора про успіх або невдачу операції, а потім координатор вирішить, чи подавати операцію, чи скасувати її на основі інформації про зворотний зв'язок усіх учасників.
Так звані два етапи: перший етап — етап підготовки (етап голосування) і другий етап — етап подання (етап виконання).
Етап підготовки
Координатор транзакцій (менеджер транзакцій) надсилає повідомлення Prepare кожному учаснику (менеджеру ресурсів), і кожен учасник або безпосередньо повертає помилку (наприклад, невдалу перевірку дозволу), або виконує транзакцію локально, записує локальні журнали повторення та скасування, але не комітує і досягає стану «все готово, винен лише східний вітер».
Етап підготовки можна додатково поділити на такі три етапи:
1) Координаційний вузол запитує всі вузли-учасники, чи можуть вони провести голосування, і починає чекати відповіді від кожного вузла-учасника.
2) Учасник-вузол виконує всі транзакційні операції до початку запиту, а потім записує інформацію про скасування та повтор у журнал. (Примітка: якщо успішно, кожен учасник уже виконав операцію транзакції)
3) Кожен вузол-учасник відповідає на запит, ініційований координатором. Якщо операція транзакції вузла учасника дійсно успішно виконана, вона повертає повідомлення «Погодитися»; Якщо транзакційна операція вузла учасника фактично не виконується, вона повертає повідомлення «скасовано».
Етап здачі
Якщо координатор отримує повідомлення про невдачу або тайм-аут від учасника, він надсилає повідомлення про відкат безпосередньо кожному учаснику. Інакше надішліть повідомлення Commit; Учасники виконують операції фіксації або відкат відповідно до інструкцій координатора, щоб звільнити всі ресурси блокування, використані в процесі транзакції. (Примітка: ресурси блокування мають бути випущені на фінальному етапі)
Далі окремо розглядається процес подання у двох випадках.
Коли відповідне повідомлення, отримане координаторним вузлом від усіх вузлів-учасників, є Agree:
Етап здачі
Якщо координатор отримує повідомлення про невдачу або тайм-аут від учасника, він надсилає повідомлення про відкат безпосередньо кожному учаснику. Інакше надішліть повідомлення Commit; Учасники виконують операції фіксації або відкат відповідно до інструкцій координатора, щоб звільнити всі ресурси блокування, використані в процесі транзакції. (Примітка: ресурси блокування мають бути випущені на фінальному етапі)
Далі окремо розглядається процес подання у двох випадках.
Коли відповідне повідомлення, отримане координаторним вузлом від усіх вузлів-учасників, є Agree:
1) Координаційний вузол надсилає запит на «фіксацію» всім вузлам-учасникам.
2) Учасник-вузол офіційно завершує операцію та звільняє ресурси, зайняті протягом періоду транзакції.
3) Вузол учасника надсилає повідомлення «Готово» координатору.
4) Координаційний вузол завершує транзакцію після отримання зворотного зв'язку «Виконано» від усіх вузлів-учасників.
1) Координаційний вузол надсилає запит на «відкат» всім вузлам-учасникам.
2) Вузол учасника використовує раніше написану інформацію про скасування для проведення відкату та звільнення ресурсів, зайнятих протягом періоду транзакції.
3) Учасник-вузол надсилає повідомлення «відкат завершено» координатору.
4) Координаційний вузол скасовує транзакцію після отримання зворотного зв'язку "Rollback Complete" від усіх вузлів-учасників.
Коміти фази 2, здається, забезпечують атомарні операції, але, на жаль, коміти другого етапу все одно мають кілька недоліків:
1. Проблема синхронного блокування. Під час виконання всі вузли-учасники блокують транзакції. Коли учасник займає публічний ресурс, інші сторонні вузли мають бути заблоковані від доступу до публічного ресурсу.
2. Єдина точка відмови. Через важливість координатора, якщо координатор не справляється. Учасники продовжать блокувати блокування. Особливо на другому етапі, якщо координатор не справляється, усі учасники все ще перебувають у стані блокування ресурсів транзакцій і не можуть продовжувати виконання транзакційних операцій. (Якщо координатор поклав слухавку, ви можете переобрати координатора, але це не вирішить проблему блокування учасника через відсутність координатора)
3. Непослідовність даних. На другому етапі другого етапу коміту, коли координатор надсилає запит на коміт учаснику, виникає виняток локальної мережі або координатор провалюється під час процесу запиту на фіксацію, через що лише деякі учасники приймають запит на підтвердження. Після отримання запиту на коміт ці учасники виконують операцію фіксації. Однак інші машини, які не отримують запит на коміт, не можуть виконати транзакційний коміт. Внаслідок цього узгодженість відділу даних відбувається у всій розподіленій системі.
4. Проблеми, які не можна вирішити на другому етапі: координатор падає після відправлення повідомлення про фіксацію, і єдиний учасник, який отримує це повідомлення, також вибуває. Тож навіть якщо фасилітатор обирає нового фасилітатора через виборчу угоду, статус угоди залишається невизначеним, і ніхто не знає, чи була вона подана.
3PC
Трифазний фікс, також відомий як протокол трьохфазного фіксування, є вдосконаленою версією двофазного фіксу (2PC).
На відміну від двоступеневих коммітів, у триступеневих коммітах є дві зміни.
1. Введіть механізм тайм-ауту. Водночас у фасилітатора та учасників вводиться механізм тайм-ауту.
2. Вставити підготовчий етап у перший і другий етапи. Це гарантує, що стан усіх вузлів-учасників залишається послідовним до фінального етапу фіксації.
Іншими словами, окрім запровадження механізму тайм-ауту, 3PC знову розділяє етап підготовки 2PC на два, так що існує три етапи: CanCommit, PreCommit і DoCommit на трьох етапах коміта.
Етап CanCommit
Етап CanCommit у 3PC насправді дуже схожий на етап підготовки у 2PC. Координатор надсилає запит на комміт учаснику, який повертає відповідь «Так», якщо той може це зробити, або «Ні».
1. Запит про транзакцію Фасилітатор надсилає учаснику запит на CanCommit. Запитайте, чи можете ви виконати операцію транзакційного фіксування. Потім почніть чекати відповіді від учасників.
2. Зворотний зв'язок Відповідь Після отримання запиту CanCommit учасник поверне відповідь «Так» і переведе стан готовності, якщо вважає, що транзакція може бути виконана гладко. Інакше зворотний зв'язок — ні.
Фаза до Commit
Фасилітатор вирішує, чи запам'ятовувати операцію PreCommit транзакції на основі відповіді учасника. Залежно від відповіді, є два варіанти.
Якщо зворотний зв'язок, який фасилітатор отримує від усіх учасників, є відповіддю «Так», тоді виконується попереднє виконання угоди.
1. Надіслати запит на PreCommit Фасилітатор надсилає запит на PreCommit учаснику і переходить до етапу підготовки.
2. Транзакція до завершення Після отримання запиту PreCommit учасник виконує операцію транзакції та записує інформацію про скасування та повторення у журналі транзакцій.
3. Зворотний зв'язок у відповідь. Якщо учасник успішно виконує операцію транзакції, відповідь ACK повертається під час очікування фінальної інструкції.
1. Надіслати запит на переривання Фасилітатор надсилає запит на скасування всім учасникам.
2. Перервати транзакцію Після того, як учасник отримує запит ABORT від координатора (або після тайм-ауту, запит від координатора не отримано), переривання транзакції виконується.
Цей етап реального транзакційного фіксації також можна поділити на наступні дві ситуації.
Виконати коміт
1. Надіслати запит на коміт. Координація отримує відповідь ACK, надіслану учасником, після чого він переходить зі стану до коміту до стану коміту. та надіслати запит на doCommit усім учасникам.
2. Подача транзакції Після отримання запиту doCommit учасник виконує формальний транзакційний коміт. і звільнити всі ресурси транзакцій після завершення коміту транзакції.
3. Відповідати на відгуки Після подання транзакції надішліть координатору відповідь у форматі Ack.
4. Завершити транзакцію Після того, як координатор отримає відповідь ACK від усіх учасників, транзакція завершена.
Якщо координатор не отримує ACK-відповідь від учасника (це може бути не відповідь ACK від отримувача, або відповідь може закінчитися), транзакція переривання виконується.
1. Надіслати запит на переривання Фасилітатор надсилає запит на скасування всім учасникам
2. Відкат транзакції Після отримання запиту ABORT учасник використовує інформацію про скасування, зафіксовану у Фазі 2, для виконання операції відкату транзакції та звільняє всі ресурси транзакції після завершення відкату.
3. Результати зворотного зв'язку Після завершення відкату транзакції надсилайте ACK-повідомлення координатору
4. Переривати транзакцію Після того, як координатор отримує повідомлення ACK від учасника, транзакція переривається.
Різниця між 2PC і 3PC
Порівняно з 2PC, 3PC головним чином вирішує проблему однієї точки відмови та зменшує блокування, оскільки якщо учасник не отримує повідомлення від координатора вчасно, він виконує коміт за замовчуванням. Замість того, щоб постійно тримати транзакційні ресурси і бути у стані блокування. Але цей механізм також спричиняє проблеми з узгодженістю даних, оскільки відповідь на скасування, надіслана координатором, не отримує учасник вчасно через мережеві причини, після чого учасник виконує операцію фіксації після очікування тайм-ауту. Це створює невідповідності даних з іншими учасниками, які отримують команду скасування і виконують відкат.
|
Опубліковано 17.03.2021 10:15:10
|
|
|
