Erlang: global
Dec. 27th, 2010 10:45 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
netch80Erlang'овский global - нечто, мягко говоря, очень своеобразное. Чтобы зарегистрировать имя, он:
* бежит по всем известным нодам, расставляя свой лок;
* модифицирует имя на каждой ноде отдельно;
* бежит по тем же нодам, снимая лок.
(Это я не учитываю варианты типа - нашли конфликт, удаляем все регистрации)
Если происходит конфликт в процедуре установки лока, он снимает свои локи, ждёт случайное время (от 0 до 8 секунд) и повторяет снова. И так до посинения (мы как-то насчитали несколько часов ожидания). Никакого преимущества у ранее пытавшегося нет, и реальный приоритет определяется сочетанием случайностей. Сейчас при одновременном рестарте многих приложений регистрация на старте может длиться десятки и сотни секунд.
Может, в устойчивой среде это и хорошо. Но представим себе разорванный кластер, который соединился снова. Одно имя зарегистрировано двумя => конфликт => одного удаляют (или обоих, тоже возможно). Значит, поздний конфликт возможен? Таки более чем. Что мешает положиться на изначальную неконфликтность и срубать только по достижению конфликта?
Да, я знаю про CAP-теорему и что любая попытка решения будет крива. Но чисто по-человечески решение с выделенным ведущим и остальными, клонирующими его данные, проще даже в устойчивой среде. А для наших условий, похоже, самым эффективным является ранее выявление конфликта только на исходной ноде запроса (этого достаточно для 99... с кучей девяток процентов случаев) и дальше "разливка" уже ленивым образом.
В R12, кроме того, ещё периодически регистрации терялись молча, без каких-то признаков проблемы. В R14 такого уже, к счастью, не наблюдается.
* бежит по всем известным нодам, расставляя свой лок;
* модифицирует имя на каждой ноде отдельно;
* бежит по тем же нодам, снимая лок.
(Это я не учитываю варианты типа - нашли конфликт, удаляем все регистрации)
Если происходит конфликт в процедуре установки лока, он снимает свои локи, ждёт случайное время (от 0 до 8 секунд) и повторяет снова. И так до посинения (мы как-то насчитали несколько часов ожидания). Никакого преимущества у ранее пытавшегося нет, и реальный приоритет определяется сочетанием случайностей. Сейчас при одновременном рестарте многих приложений регистрация на старте может длиться десятки и сотни секунд.
Может, в устойчивой среде это и хорошо. Но представим себе разорванный кластер, который соединился снова. Одно имя зарегистрировано двумя => конфликт => одного удаляют (или обоих, тоже возможно). Значит, поздний конфликт возможен? Таки более чем. Что мешает положиться на изначальную неконфликтность и срубать только по достижению конфликта?
Да, я знаю про CAP-теорему и что любая попытка решения будет крива. Но чисто по-человечески решение с выделенным ведущим и остальными, клонирующими его данные, проще даже в устойчивой среде. А для наших условий, похоже, самым эффективным является ранее выявление конфликта только на исходной ноде запроса (этого достаточно для 99... с кучей девяток процентов случаев) и дальше "разливка" уже ленивым образом.
В R12, кроме того, ещё периодически регистрации терялись молча, без каких-то признаков проблемы. В R14 такого уже, к счастью, не наблюдается.
