Я уже пытался найти что-то в StackOverflow, но ни один из уже отвеченных вопросов не может помочь мне в моем случае использования.Дело не только в том, какой рецепт использовать или нет, но больше в том, чтобы сосредоточиться на деталях реализации.Правильно ли я делаю вещи или нет: o
Я пытаюсь добиться совместного использования конфигурации между несколькими узлами, но дело не просто в том, что одна и та же конфигурация распределяется между моими узлами, а в том, чтобы разделить этот конф между узлами.Допустим, конфигурация выглядит следующим образом:
topicA themeB topicC topicD
И я запускаю 3 узла, это будет выглядеть примерно так: узел A - тема A, тема B узел B - тема C узел C - тема D
Все узлы, когда они запускаются, имеют статический конфигурационный файл со всеми темами, затем я использую zookeeper, чтобы они знали о количестве других доступных узлов, а затем запускаю алгоритм, который разделит темы междудоступные узлы.Алгоритм одинаков для всех узлов и является полностью детерминированным (результаты будут одинаковыми для всех узлов).
Для большей ясности: узлы A, nodeB и nodeC имеют всю статическую конфигурацию следующим образом:
topicA topicB topicC topicD
Затем они видят друг друга через zookeeper, теперь у них есть следующая информация о узлах: nodeA nodeB nodeC
Они запускают алгоритм, а затем nodeAсвязанный с topicA и topicB, то есть, как nodeA знает, что он должен обрабатывать только topicA и topicB
Я мог бы использовать рецепт выбора лидера, но, имхо, это могло бы усложнить ситуацию.
Если вдаваться в подробности, это немного сложнее. Идея состоит в том, что когда узел получает событие ZK (узел удален / добавлен), перед выполнением ребалансировки он должен сначала остановить свои задания и дождаться, пока все доступные узлы не остановят свои действия.работы, а также.У меня не может быть двух узлов, работающих над одной и той же темой, это обязательно.
Поэтому я добавил еще один механизм ZK следующим образом: Когда узел получает событие (узлы добавлены / удалены), он останавливает свою работу, затем обновляетмаркер остановки с текущей отметкой времени в ZK, когда он закончил свою работу.Также всякий раз, когда узел удаляется или добавляется, все узлы будут обновлять маркер общего времени ZK (называемый lastupdatedmarker).Все они имеют один и тот же маркер времени.Затем узел ожидает, пока все доступные маркеры остановки узла окажутся выше последнего маркера обновления, что означает, что все они прекратили свою работу и готовы восстановить баланс в конфигурациях.
Тогда одна проблема с этим заключается в том, что если ядобавить или удалить узел после того, как один узел обновил свой маркер остановки, но перед конвергенцией я мог бы пропустить изменение, что привело бы к узлу ожидания навсегда.Для этого я добавил флаг ShouldRebalance, который устанавливается в значение true, когда событие узла ZK (добавлено / удалено) происходит в течение этого небольшого периода времени.
Кажется, что оно работает правильно ... но я уверен, что тамнедостатки этого дизайна и начинают думать, что я, возможно, не все делаю правильно.я читал разные рецепты для куратора, они кажутся действительно более надежными, но не уверен, что справятся с этим вариантом использования со 100% -ной корректностью.
Какие-нибудь советы?
С уважением,
Yann