Вы правы, что нет необходимости реализовывать определенный алгоритм выбора лидера в Paxos, как описано в Paxos Made Simple .Вам просто нужно рандомизировать тайм-ауты, чтобы увидеть прогресс от лидера, и появится стабильный лидер.Больше ничего не требуется, вы просто повторно отправляете сообщения и тайм-аут на лидера, и вы запускаете Prepare.Я опишу это подробно здесь .
Тем не менее, вы можете выбрать собственный механизм выбора лидера, который вы предпочитаете, например,
- Один, где вы можете доказать, что не будет бесконечных поединков лидеров
- Одиноптимизирован для среднего времени восстановления
- Один оптимизирован для гарантии того, что восстановление произойдет в течение определенного времени
- Один оптимизирован для простоты и минимального кода
Ключевым моментом здесь являетсячто вы можете оптимизировать скорость обнаружения сбоев и скорость, с которой клиенты испытывают работающую систему после сбоев.Если у вас есть быстрое обнаружение сбоев, ваше среднее время восстановления будет меньше.Если ведущие поединки невозможны, это поможет вам гарантировать, что система восстановится в течение определенного периода времени (например, от количества обращений к сообщениям).
Paxos для сборщиков систем: обзор гласит:
Paxos работает только так, как его протокол выборов лидера
Подтверждениеважность выбора лидера протокола выборов для обеспечения жизнедеятельности.Они также спрашивают:
Какие жизненные свойства гарантирует [имплиментация Паксоса]?
также
Мы также выявляем важные теоретическиеразличия, связанные с жизнью, которые возникают из-за того, как каждый указывает детали Паксоса;В частности, мы сосредоточены на выборе алгоритма выборов лидера
и
Каждый протокол выборов лидера требует разного уровня стабильности, чтобы оставаться на одном лидере (который являетсянеобходимо гарантировать живучесть).
До конца статьи говорится:
Эти детали являются критически важными компонентами для создания высокопроизводительных-доступный механизм репликации на основе Paxos.
Они приравниваются к высокой доступности для жизни.Учитывая, что случайные тайм-ауты не дают никаких гарантий избегать бесконечных лидерских поединков, они фактически исключаются из рассмотрения в статье, поскольку она пытается оптимизировать жизнь Паксос.
Поскольку авторы не говорят, почему они выбрали протокол выборов лидера, который они сделали, нам остается только догадываться, почему именно они считают это лучшим.Если мы посмотрим на все их диаграммы, все они связаны с пропускной способностью и не означают время восстановления или максимальное время восстановления.Я нахожу это разочаровывающим.В газете они упускают возможность поделиться своим пониманием того, почему они выбрали именно тот протокол о выборах лидеров, который они сделали.Они могли бы использовать что-то вроде jepsen , которое тестирует реальные базы данных с открытым исходным кодом при комбинации сетевых разделов и сбоев.Они могли бы затем предоставить экспериментальные доказательства того, что их алгоритм выбора лидера лучше, чем альтернативы при различного рода сбоях или сетевых разделах.
Раздел 3 дает четкий намек на их мышление:
мы заметили, что для всех систем существует шкала требований к стабильности сети, вытекающая непосредственно из выбора лидера.протокол.Каждый протокол выборов лидера требует разного уровня стабильности, чтобы оставаться на одном лидере (который необходим для обеспечения жизнеспособности)
Они также говорят:
Сильный L1 требует, чтобыпрогресс будет достигнут даже перед лицом (быстро) меняющегося большинства.Мы полагаем, что ни один Paxos-подобный алгоритм не сможет удовлетворить это требование.Если большинство меняется слишком быстро, то оно никогда не будет достаточно стабильным, чтобы завершить протокол выборов лидера.
Таким образом, они обсуждают как стабильность сети, так и устойчивость к сбоям, а также то, как разные алгоритмы выбора лидера работают по-разному в зависимости от типов нестабильности.Они прямо говорят, что ни один алгоритм Paxos не дает живости с быстро меняющимися разделами.Таким образом, они неявно говорят, что они оптимизируют жизнеспособность при достаточно стабильных сетевых разделах.
Это разумная оптимизация.Сети могут и делают странные вещи, но не так часто, как прикладные процессы имеют ошибки на диске, ошибки памяти или ошибки, которые приводят к возникновению аварийных циклов.Вы хотите использовать Paxos, чтобы гарантировать, что независимо от того, насколько сумасшедшими или причудливыми являются ваши сетевые разделы, вы не получите искажений.Тем не менее, для выборов лидеров вы, вероятно, можете предположить, что сеть более стабильна, чем работающие на ней серверы.Вы можете выбрать механизм выбора лидера, который быстро восстанавливается для достаточно стабильной сети, где процессы часто выходят из строя и перезапускаются.
ИМХО, практические сборщики систем должны использовать случайные таймауты по умолчанию.Рандомизированные тайм-ауты - самая простая вещь, которая может работать, но они не гарантируют, что они не будут бесконечными поединками лидера.Это просто невероятно.Тем не менее, рандомизированные тайм-ауты очень привлекательны с точки зрения простоты и минимального кода, и поэтому менее вероятно, что они будут содержать ошибки.Вот почему алгоритм Рафта использует их.Существует огромное количество практических алгоритмов, стохастических по своей природе.
Практически вы можете жить со случайными таймаутами, так как простейшая вещь, которая может работать, зависит от вашего варианта использования.Это очень типичный вариант использования для репликации только метаданных, а не основных данных, с использованием алгоритма строгой согласованности.Есть много в конечном итоге непротиворечивых систем, которые полагаются на строго согласованную конфигурацию, но имеют высокопроизводительную прямую запись.Поэтому часто можно создавать системы, в которых произошел сбой лидера Paxos, но система все еще работает и принимает операции чтения или записи с различными гарантиями.В таких системах использование «случайных» тайм-аутов для выборов лидеров с экспоненциальной отсрочкой может быть «достаточно хорошим». Corfu - это пример высокопроизводительного строго согласованного движка, который использует Paxos для отображения того, какие диапазоны записи реплицируются на какие узлы.Тем не менее, клиенты пишут напрямую на несколько узлов, используя цепную репликацию, а не через лидера.Он гарантированно будет правильным, если каждый узел будет иметь единообразное представление о членстве в кластере.Тем не менее, эти изменения медленно через Paxos и большие объемы записей Корфу могут продолжаться во время выборов лидера Paxos, так что случайные тайм-ауты могут быть достаточно хорошими.
Можно сказать: «Хорошо, если я смогу использовать выборные выборы лидера для восстановления быстрее, чем я».Тем не менее, этот пользовательский механизм - это больше кода для написания и отладки.Поэтому я бы сказал, что если вы можете жить со случайными тайм-аутами, а не со сложным механизмом выборов лидеров, то вам, вероятно, следует.