В недавнем интервью меня попросили спроектировать распределенную очередь сообщений. Я смоделировал ее как многораздельную систему, в которой каждый раздел имеет набор реплик с одним первичным и одним или несколькими вторичными для обеспечения высокой доступности. Записи от производителя обрабатываются основным и реплицируются синхронно, что означает, что сообщение не фиксируется, если его не применил кворум набора реплик. Затем он определил потенциальную проблему доступности, когда основной набор реплик умирает (что означает, что производитель, записывающий в этот раздел, не сможет писать до тех пор, пока для набора реплик не будет выбран новый основной) и спросил меня о решении, где производитель пишет одно и то же сообщение на несколько серверов (отдавая предпочтение доступности, а не согласованности). Затем он спросил меня, в чем будет разница, если клиент будет писать на 2 сервера против 3 серверов, вопрос, на который я не ответил. В общем, я думал, что это скорее вопрос о четных и нечетных, и я предположил, что это как-то связано с кворумами (то есть большинством), но не смог понять, как это повлияет на чтение данных потребителем. Излишне говорить, что этот вопрос стоил мне работы и до сих пор продолжает озадачивать меня. Я был бы признателен за любые решения и / или идеи и / или предложения для одного.
почему производитель должен писать на нечетное количество серверов в случае распределенной очереди сообщений
Ответы (1)
Хорошо, вот что я понял из вашего вопроса о новой системе:
У вас больше не будет первичной реплики, поэтому вам не нужно ее выбирать, и вместо этого вы будете работать просто в системе на основе кворума, чтобы иметь более высокую доступность? - если это правильно, то, возможно, это даст вам некоторое закрытие :) - в противном случае не стесняйтесь поправлять меня.
Предполагая, что вы читаете и записываете из/в несколько случайных узлов, и эти узлы не реплицируют данные самостоятельно, решение заключается в принципе кворумов. В простых случаях это означает, что вам нужно всегда писать и читать как минимум в/из n/2 + 1 узлов. Таким образом, если вы будете писать на 3 узла, у вас может быть до 5 серверов, а если вы будете писать на 2 узлах, у вас может быть только до 3 серверов.
Чуть более сложный кворум основан на правилах:
R + W > NW > N / 2- (R - кворум чтения, W - кворум записи, N - количество узлов)
Это даст вам еще несколько вариантов для
- со скольких серверов нужно читать
- сколько серверов вообще можно иметь
Насколько я понимаю вопрос, это то, что я бы использовал для формулировки ответа, и я не думаю, что разница между 2 и 3 имеет какое-либо отношение к четным или нечетным числам. Как вы думаете, это тот ответ, который искал ваш интервьюер, или я что-то упустил?
Обновление:
Чтобы уточнить мысли в комментарии, какое значение будет принято.
В кворуме, как я описал, вы примете самое последнее значение. Можно определить с помощью простых логических часов. Кворумы гарантируют, что вы получите хотя бы один элемент с самой последней информацией. А в случае разделения сети или сбоя, когда вы не можете прочитать кворум, вы будете знать, что невозможно гарантировать получение самого последнего значения.
С другой стороны, вы предложили прочитать все пункты и принять наиболее распространенный. Я не уверен, одно только это гарантирует, что у вас всегда будет самая последняя вещь.
