Предотвращение мозга разделения, голосов и [закрытого] кворума
// Start the child process. Process p = new Process(); // Redirect the output stream of the child process. p.StartInfo.UseShellExecute = false; p.StartInfo.RedirectStandardOutput = true; p.StartInfo.FileName = "YOURBATCHFILE.bat"; p.Start(); // Do not wait for the child process to exit before // reading to the end of its redirected stream. // p.WaitForExit(); // Read the output stream first and then wait. string output = p.StandardOutput.ReadToEnd(); p.WaitForExit();Код от MSDN.
3 ответа
Теория:
Это выборы лидера, являющиеся формой проблемы консенсуса , также иногда называемой проблемой двух генералов . При некоторых наборах предположений (полная асинхронность и сообщения могут быть потеряны) это оказалось невозможным, и доказательство особенно элегантно.
Интуиция этой проблемы такова: представьте, что существует некоторый алгоритм, который позволяет достичь консенсуса в некотором фиксированном количестве сообщений. Поскольку сбои допустимы, мы можем отбросить одно сообщение из протокола, и оно все равно должно работать. Мы можем повторять этот процесс до тех пор, пока не будет совсем никаких сообщений, что явно невозможно.
На практике мы преодолеваем это, используя детекторы отказов для моделирования синхронной системы.
Наиболее широко известный алгоритм решения консенсуса - это Paxos , который может выдержать отказ до половины участвующих узлов. Paxos имеет репутацию очень сложного в реализации, поскольку даже небольшое недоразумение в деталях протокола нарушает его правильность.
Практические решения:
Хотя проблема в целом довольно сложна, наладить работающие системы намного проще. Существуют готовые реализации Paxos или эквивалентных алгоритмов. Apache Zookeeper - лучшее, что мне известно. Я уверен, что для вашей конкретной проблемы это будет самый быстрый путь. Существуют и другие реализации Paxos, и также возможно создать что-то на инструментах виртуального IP для резервирования сети, таких как Wackamole . Я считаю, что высокопроизводительные версии большинства коммерческих баз данных предлагают функции кворума в качестве (дорогостоящего) варианта.
Кроме того, для многих приложений допустимо немного ослабить корректность или иным образом скорректировать проблему, чтобы разрешить гораздо более простые решения.
Например, если единственная точка отказа допустима, потому что восстановление, вероятно, будет быстрым, тогда проблема тривиальна: пусть только один специальный узел выполняет работу.
Другой подход может заключаться в построении системы вокруг идемпотента. действия, так что дублирующая обработка станет допустимой.
Наконец, вы можете разделить рабочую нагрузку на пул неизбыточных систем: здесь сбои задерживают обработку до восстановления, но только для элементов на этом узле, а не для всей рабочей нагрузки.
Такого рода компромиссы настолько проще, что часто оказываются лучшим выбором. Нужно взвесить полезность полного решения и сложность его реализации и посмотреть, действительно ли оно ценно.
Я не понимаю, что такое обмен сообщениями pub-sub.
Если они получают какие-то рабочие объекты из внешнего источника, и вы хотите, чтобы только один из них обрабатывал работу, вы можете взять пространство хеш-значений, 2 ^ 64, разделить пространство на количество узлов, каждый узел, занимающий кусок. Каждый узел может хэшировать рабочие объекты по мере их поступления и определять, принадлежит ли он им.
Посмотрите, как это делают протоколы маршрутизации (OSPF и IS-IS), и посмотрите, работает ли это для вас . Они выбирают лидера (и в случае OSPF,