2 Phase Commit — различия между версиями
Yeputons (обсуждение | вклад) |
Yeputons (обсуждение | вклад) |
||
| Строка 2: | Строка 2: | ||
'''Алгоритм двухфазного коммита''' — классический централизованный оптимистичный алгоритм распределённого консенсуса из баз данных для подтверждения [[Транзакции в распределённых системах|распределённых транзакций]]. | '''Алгоритм двухфазного коммита''' — классический централизованный оптимистичный алгоритм распределённого консенсуса из баз данных для подтверждения [[Транзакции в распределённых системах|распределённых транзакций]]. | ||
| − | После того, как мы завершили транзакцию, её надо атомарно подтвердить на всех участниках. | + | После того, как мы завершили транзакцию, её надо атомарно подтвердить на всех участниках (participants). |
У каждой транзакции есть выделенный координатор (transaction coordinator). | У каждой транзакции есть выделенный координатор (transaction coordinator). | ||
Алгоритм работает в две фазы: | Алгоритм работает в две фазы: | ||
| Строка 10: | Строка 10: | ||
При этом проблемы двух генералов на практике обычно нет: после того, как координатор принял решение о транзакции, он будет его доносить до всех любопытствующих узлов. | При этом проблемы двух генералов на практике обычно нет: после того, как координатор принял решение о транзакции, он будет его доносить до всех любопытствующих узлов. | ||
| + | |||
| + | Всего на коммит требуется $3N$ сообщений ($N$ — количество участников транзакции) и задержка порядка $3\cdot RTT$ (round-trip time). | ||
== Ограничения == | == Ограничения == | ||
Версия 00:15, 4 июня 2019
Алгоритм двухфазного коммита — классический централизованный оптимистичный алгоритм распределённого консенсуса из баз данных для подтверждения распределённых транзакций.
После того, как мы завершили транзакцию, её надо атомарно подтвердить на всех участниках (participants). У каждой транзакции есть выделенный координатор (transaction coordinator). Алгоритм работает в две фазы:
- Запрос (request): координатор спрашивает каждого участника: "готов ли ты очень быстро и гарантированно завершить транзакцию?". Если кто-нибудь ответил "нет", то отменяем транзакцию. Если кто-то отвечает "да", то он должен уметь обеспечить завершение транзакции даже если упадёт и поднимается (например, все данные уже в журнале).
- Завершение: координатор принимает решение о закреплении (commit) или отмене (rollback) транзакции и записывает его в свою надёжную память, после чего рассылает всем решение. После рассылки можно сообщить о фиксации транзакции, подтверждения от участников ждать не нужно (но тогда может быть проблема с тем, что следующие чтения из СУБД будут возвращать старые данные, пока не закоммитили).
При этом проблемы двух генералов на практике обычно нет: после того, как координатор принял решение о транзакции, он будет его доносить до всех любопытствующих узлов.
Всего на коммит требуется $3N$ сообщений ($N$ — количество участников транзакции) и задержка порядка $3\cdot RTT$ (round-trip time).
Ограничения
Так как это алгоритм консенсуса, к нему применима FLP.
Если у нас есть отказы узлов или связи, то 2PC будет ждать, пока связь не восстановится:
- Если отказ произошёл на первой фазе, то координатор может отменить транзакцию по таймауту.
- После того, как координатор перешёл на вторую фазу, он не имеет права успокоиться, пока не донесёт своё решение до всех узлов.
- Если узел отказал, а потом восстановился, то он спрашивает координатора, какое решение было принято. Если "да", то обязан закрепить транзакцию (т.е. координатор должен хранить все подтверждённые транзакции, которые подтвердили не все узлы).
- Если отказал координатор, то, если узел ответил "да", он не имеет права забить на транзакцию, пока координатор не восстановится.
Но алгоритм классический, простой, на практике неплохо работает, потому что сложно только с отказами координатора и отказами узлов на второй фазе (когда решение о коммите уже принято), а такое бывает не так часто.
