Спецификация на XA
XA е спецификацията на интерфейса (т.е. интерфейсна функция) между междинния софтуер за транзакции и базата данни, дефинирана от X/Open DTP, която се използва от междинния софтуер за транзакции, за да уведоми базата данни за началото, края, потвърждаването, връщането назад и др. на транзакции. XA интерфейсните функции се предоставят от доставчици на бази данни.
Второто споразумение за подаване и третото споразумение за подаване са изведени от тази идея. Може да се каже, че двустепенните commits всъщност са ключът към реализирането на XA разпределени транзакции (по-точно: двустепенните commit-и основно гарантират атомичността на разпределените транзакции: т.е. всички възли или правят всичко, или нищо)
2PC
Двуфазният коммит се отнася до алгоритъм, предназначен да поддържа консистентност в транзакционните комити за всички възли, базиран на разпределена системна архитектура в областта на компютърните мрежи и бази данни. Често двустепенното потвърдяване се нарича и протокол. В разпределена система всеки възел може да знае успеха или неуспеха на собствената си операция, но не може да знае успеха или неуспеха на операциите на другите възли. Когато една транзакция обхваща няколко възела, за да се поддържат ACID характеристиките на транзакцията, трябва да се въведе компонент, който действа като координатор, който да контролира резултатите на всички възли (наречени участници) и в крайна сметка да инструктира тези възли да подават резултатите (например да записват актуализирани данни на диск и др.). Следователно алгоритъмната идея за двуетапното подаване може да се обобщи така: участниците ще уведомят координатора за успеха или неуспеха на операцията, а след това координаторът ще реши дали да представи операцията или да я прекрати въз основа на обратната връзка на всички участници.
Така наречените два етапа са: първият етап: етап на подготовка (етап на гласуване) и вторият етап: етап на подаване (етап на изпълнение).
Етап на подготовка
Координаторът на транзакциите (мениджър на транзакции) изпраща съобщение Prepare на всеки участник (мениджър на ресурси), и всеки участник или връща директно неуспех (като проверка на неуспешно разрешение), или изпълнява транзакцията локално, записва локални логове за повторение и отмяна, но не комитира и достига състояние "всичко е готово, само източният вятър се дължа".
Етапът на подготовка може да се раздели допълнително на следните три стъпки:
1) Координаторният възел пита всички участващи възли дали могат да извършат гласуване и започва да чака отговор от всеки участник.
2) Участващият възел извършва всички транзакционни операции, докато заявката бъде инициирана, и записва информацията за отмяна и повторение в лога. (Забележка: Ако е успешно, всеки участник вече е извършил транзакционната операция)
3) Всеки участващ възел отговаря на запитването, инициирано от координатора. Ако транзакционната операция на участващия възел е реално успешно изпълнена, тя връща съобщение "Съгласен"; Ако транзакционната операция на участващия възел наистина се провали, се връща съобщение "прекратено".
Етап на предаване
Ако координаторът получи съобщение за неуспех или таймаут от участник, той изпраща съобщение за връщане директно на всеки участник. В противен случай изпратете съобщение за Commit; Участниците извършват коммит или операции по връщане на назад според инструкциите на координатора, за да освободят всички заключващи ресурси, използвани в процеса на транзакция. (Забележка: Ресурсите за заключване трябва да бъдат освободени в последния етап)
След това процесът на подаване се обсъжда отделно в два случая.
Когато съответното съобщение, получено от координаторния възел от всички участващи възли, е Agree:
Етап на предаване
Ако координаторът получи съобщение за неуспех или таймаут от участник, той изпраща съобщение за връщане директно на всеки участник. В противен случай изпратете съобщение за Commit; Участниците извършват коммит или операции по връщане на назад според инструкциите на координатора, за да освободят всички заключващи ресурси, използвани в процеса на транзакция. (Забележка: Ресурсите за заключване трябва да бъдат освободени в последния етап)
След това процесът на подаване се обсъжда отделно в два случая.
Когато съответното съобщение, получено от координаторния възел от всички участващи възли, е Agree:
1) Координаторният възел изпраща заявка "commit" към всички участващи възли.
2) Участващият възел официално завършва операцията и освобождава ресурсите, заети през целия период на транзакцията.
3) Участващият възел изпраща съобщение "Готово" към координаторния възел.
4) Координаторният възел завършва транзакцията след получаване на обратната връзка "Готово" от всички участващи възли.
1) Координаторният възел изпраща заявка за "rollback" към всички участващи възли.
2) Участващият възел използва предварително написаната информация за отмяна, за да извърши връщане назад и да освободи ресурси, заети през целия транзакционен период.
3) Участващият възел изпраща съобщение "rollback завършено" до координаторния възел.
4) Координаторният възел анулира транзакцията след получаване на обратната връзка от съобщението "Rollback Complete" от всички участващи възли.
Фаза 2 комити изглежда осигуряват атомарни операции, но за съжаление етап 2 все още имат някои недостатъци:
1. Проблем със синхронното блокиране. По време на изпълнение всички участващи възли блокират транзакции. Когато участник заема публичен ресурс, други възли на трети страни трябва да бъдат блокирани от достъп до публичния ресурс.
2. Единствена точка на отказ. Поради важността на координатора, след като координаторът се провали. Участниците ще продължат да блокират запушването. Особено във втория етап, ако координаторът се провали, всички участници все още са в състояние на заключване на транзакционните ресурси и не могат да продължат да завършват транзакционните операции. (Ако координаторът прекъсне, можете да го преизберете, но това не може да реши проблема, че участникът е блокиран заради работата на координатора)
3. Несъответствие на данните. Във втория етап на втория етап на commit, когато координаторът изпраща заявка за commit към участника, възниква изключение в локалната мрежа или координаторът се проваля по време на процеса на заявка за потвърдяване, което кара само някои участници да приемат заявката за потвърждение. След получаване на заявката за потвърждение, тези участници ще изпълнят операцията за потвърждение. Въпреки това, други машини, които не получават заявка за комит, не могат да изпълнят транзакционния комит. В резултат на това консистентността на отдела за данни се случва в цялата разпределена система.
4. Проблеми, които не могат да бъдат решени във втория етап: Координаторът слиза след изпращане на commit съобщение, а единственият участник, който получава това съобщение, също е долу. Така че дори ако фасилитаторът избере нов фасилитатор чрез изборното споразумение, статусът на сделката е несигурен и никой не знае дали тя е подадена.
3PC
Трифазният commit, известен още като трифазен commit протокол, е подобрена версия на двуфазния commit (2PC).
За разлика от двустепенните комити, има две промени при тристепенните комити.
1. Въведете механизъм за тайм-аут. В същото време се въвежда механизъм за тайм-аут както при фасилитатора, така и при участниците.
2. Вмъкнете подготвителен етап в първия и втория етап. Това гарантира, че състоянието на всички участващи възли е последователно до финалния етап на потвърждение.
С други думи, освен въвеждането на механизъм за тайм-аут, 3PC отново разделя етапа на подготовка на 2PC на две, така че има три етапа: CanCommit, PreCommit и DoCommit в трите етапа на комита.
Етап CanCommit
Етапът CanCommit в 3PC всъщност е много подобен на етапа подготовка на 2PC. Координаторът изпраща заявка за коммит на участника, който връща отговор "Да", ако може да се ангажира, или отговор "Не".
1. Запитване за транзакция Фасилитаторът изпраща заявка CanCommit към участника. Попитай дали можеш да изпълниш транзакционна commit операция. След това започнете да чакате отговор от участниците.
2. Обратна връзка за отговор След получаване на заявката за CanCommit, участникът ще върне отговор "Да" и ще влезе в състояние готовност, ако смята, че транзакцията може да бъде изпълнена гладко. В противен случай обратна връзка – Не
Фаза преди Commit
Фасилитаторът решава дали да запомни операцията PreCommit на транзакцията въз основа на отговора на участника. В зависимост от отговора има две възможности.
Ако обратната връзка, която фасилитаторът получава от всички участници, е отговор "Да", тогава се извършва предварителното изпълнение на транзакцията.
1. Изпратете заявка за предварително потвърдяване Фасилитаторът изпраща заявка за предварително потвърдяване на участника и преминава към етапа Подготовка.
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 ч.
|
|
|
