3-фазный протокол фиксации

Я читал протокол трехфазной фиксации в Википедии (http://en.wikipedia.org/wiki/Three-phase_commit_protocol), и вот сценарий, который пришел мне на ум, когда 3PC не удастся:

Предположим, что есть два участника A и B и координатор C:

1) C отправил сообщение предварительной фиксации в A, и до того, как он отправит сообщение предварительной фиксации в B, оба A и C одновременно терпят неудачу. 2) Теперь транзакция перезапущена, и B прерывает ее, потому что нет ответа от A. 3) A фиксирует транзакцию, потому что уже получил предварительное сообщение.

Разве это не было изначальной проблемой 2PC, которую должен был решить 3PC? Как 3PC решает проблему? Что мне не хватает. Спасибо.


distributed-transactions
person Abdul Rahman    schedule 29.06.2012    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Обновление:

Участники не совершают коммит до тех пор, пока не получат сообщение doCommit от координатора?

После получения сообщения preCommit участники сначала будут ждать, а если произойдет тайм-аут, они просто перейдут к фиксации.

если координатор выходит из строя после отправки сообщения предварительной фиксации и хотя бы у одного из участников есть сообщение предварительной фиксации, остальные в системе могут просто продолжить и выполнить фиксацию, поскольку им уже известно состояние системы.

Да, как только новый координатор увидит, что его участник уже получил сообщение preCommit, он повторно отправит сообщения preCommit другим участникам.

person xvatar    schedule 29.06.2012
comment
Извините, я немного не понимаю эту часть протокола. Участники не совершают коммитов до тех пор, пока не получат сообщение doCommit от координатора? - person Abdul Rahman; 29.06.2012
comment
Я предполагаю, что, возможно, это произойдет, если координатор и все участники, знающие состояние системы, потерпят неудачу, а затем транзакция прервется после избрания нового координатора (я думаю, в соответствии с тем, что вы сказали). И если координатор выходит из строя после отправки сообщения предварительной фиксации и хотя бы один из участников имеет сообщение предварительной фиксации, остальные в системе могут просто продолжить и выполнить фиксацию, поскольку они уже знают состояние в системе. Таким образом, система никогда не находится в неопределенном состоянии. - person Abdul Rahman; 29.06.2012
comment
Спасибо Кватар. Если участники ждут doCommit от координатора, атомарность может дать сбой в случае, когда координатор отправляет фиксацию некоторым участникам и терпит неудачу до того, как отправит фиксацию другим участникам. Так что я думаю, что это не сработает. Это был бы тот же недостаток, что и у протокола двухфазной фиксации. - person Abdul Rahman; 29.06.2012
comment
@AbdulRahman извините, мой предыдущий ответ был неправильным .. смотрите мое обновление - person xvatar; 02.07.2012

arrow_upward
0
arrow_downward

Если в какой-то момент произойдет сбой координатора, узел восстановления может взять на себя транзакцию и запросить состояние любых оставшихся реплик. Если реплика, которая зафиксировала транзакцию, потерпела крах, мы знаем, что все остальные реплики получили сообщение «подготовка к фиксации» (иначе координатор не перешел бы к фазе фиксации), и поэтому узел восстановления будет в состоянии определить, что транзакция может быть совершена, и безопасно вести протокол до его завершения. Если какая-либо реплика сообщает узлу восстановления, что она не получила сообщение "подготовка к фиксации", узел восстановления будет знать, что транзакция не была зафиксирована в любой момент времени. реплики, и поэтому сможет либо пессимистично прервать, либо перезапустить протокол с самого начала.

--цитируется с http://the-paper-trail.org/blog/consensus-protocols-three-phase-commit/

Поэтому я думаю, что новый координатор будет запрашивать состояние когорт, только когда все живые когорты получат сообщение о предварительной фиксации, тогда новый координатор отправит сообщение о фиксации; в противном случае транзакция будет прервана.

person nrek    schedule 17.03.2013

arrow_upward
0
arrow_downward

3PC допускает только одноточечный сбой, а не многоточечный сбой. На самом деле, чтобы убедиться, что 3PC работает, должны быть выполнены все следующие три условия:

  1. нет сетевых сбоев (т. е. нет сетевого раздела, каждое сообщение будет доставлено в пункт назначения до истечения времени ожидания, если целевая машина работает (не падает))

  2. максимум один участник может выйти из строя (вылететь). Чтобы быть точным, если координатор выходит из строя (вылетает), все когорты не должны выходить из строя

  3. машина-участник может различать тайм-аут и сбой (это не тривиально, подумайте, когда он выходит из строя (т.е. отключается электричество) сразу после тайм-аута, когда он не может ничего записать в постоянное хранилище, чтобы напомнить себе, что это был тайм-аут, а не сбой когда выздоровеет)

Ни одно из этих условий не является практичным. Поэтому я не думаю, что 3PC можно реализовать в реальном мире.

person lambda    schedule 12.07.2015