Как реализовать 2ПК в кластере Zookeeper?

У меня есть вопрос относительно реализации протокола двухфазной фиксации в кластере zookeeper для координации определенной транзакции между несколькими клиентскими соединениями. Сейчас у меня есть следующая идея:

  • Координатор C узел транзакции регистрации /app/tx
  • регистрировать узел обработки для каждой вовлеченной стороны /app/tx/%d (Ni)
  • установить наблюдателей на каждом узле вовлеченной стороны Ni
  • уведомить каждого Ni о новой транзакции tx
  • Ni проверяет, создан ли его узел
  • Ni устанавливает транзакцию для подготовки () / прерывания ()
  • C получает результат от всех сторон и решает прервать / продолжить
  • если продолжить, каждый Ni выполняет запрос
  • Ni уведомляет C сообщение ОК / сбой
  • C решает прервать | зафиксировать
  • C уведомляет всех о результате.
  • tx совершено

Но я не уверен, что это правильное направление? И я не уверен, как это реализовать на python kazoo или на любом другом языке (Java)? Было бы неплохо, если бы вы могли мне помочь, предоставив фрагмент или исправив мой алгоритм? Кроме того, как расширить этот протокол для связи между сотрудниками зоопарка? Скажем, мы поддерживаем несколько разных кластеров zookeeper, которые заключены в зоны или любую другую абстрактную сущность, и мы хотели бы выполнять такие явные транзакции в определенной зоне с использованием двухфазной фиксации?


person Rustem K    schedule 08.07.2014    source источник
comment
Похоже, вы использовали стандартный рецепт zookeeper.apache.org/doc / trunk / и добавил больше сложности (C должен делать больше вещей). Я думаю, что узлы могут сами решить, следует ли совершать транзакцию или нет, так как они следят за всеми локациями ZK   -  person Christopher Swenson    schedule 03.11.2014


Ответы (1)


Важная корректировка вашего алгоритма на основе 2PC с использованием Zk,

  • Координатор C регистрирует транзакцию node / app / tx
  • Координатор уведомляет клиентов о транзакции
  • Координатор устанавливает WATCH в / app / tx, когда под ним создаются узлы.
  • Каждый клиент создает эфимерный узел / app / tx / node_i с решением о подготовке / прерывании.
  • Клиент устанавливает часы на узле
  • Координатор решает зафиксировать / прервать выполнение после ожидания тайм-аута или создания всех узлов
  • Координатор изменяет значение эфимерных узлов для каждого клиента для фиксации / прерывания.
  • Клиенты фиксируют / прерывают транзакцию
  • Клиенты обновляют значение узла на подтвержденное
person dark_src    schedule 20.05.2017