Реализация отказоустойчивости в распределенных очередях сообщений

Предположим на картинке ниже, что средняя очередь сообщений выходит из строя. Отправители по-прежнему могут получать сообщения, отправленные с помощью других очередей сообщений.

Но что произойдет, если очередь сообщений умрет после получения сообщения. Как отправитель узнает, было ли сообщение отправлено получателю или нет, чтобы решить, отправлять ли его повторно в другую очередь сообщений?

Аналогично, что произойдет, если получатель умрет после того, как очередь сообщений доставит ему свое сообщение? Как отправитель узнает, был ли выполнен его предполагаемый запрос получателем или нет?

введите здесь описание изображения


message-queue distributed-system distributed fault-tolerance
person user782220    schedule 20.02.2013    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Для начала вам нужно прочитать http://en.wikipedia.org/wiki/Two_Generals%27_Problem. .

Это пример очень известной и очень распространенной проблемы в компьютерных науках. Технически это считается «решенным», поскольку мы знаем ответ; однако короткая история такова: то, о чем вы просите, (строго говоря) невозможно. Существуют протоколы, которые вы можете разработать и которые позволят вам достичь любого уровня уверенности в том, что сообщение было (или не было) доставлено, при условии, что достоверность составляет ‹1,0.

На практике используются варианты двух- и трехфазных протоколов распределенных транзакций, а также различные резервные варианты повторной передачи и ресинхронизации. Особенности зависят от реализации.

Часто выбор состоит в том, чтобы разрешить возможность дублирования и потребовать от Получателя соответствующего ответа. Это выбор TCP, который, если подумать, пытается найти разумный ответ на тот же вопрос.

person Recurse    schedule 20.02.2013
comment
Было бы целесообразно, если бы контекст был WebSockets, чтобы клиентский браузер, тем не менее, опрашивал каждые 10 секунд, чтобы увидеть, не удалось ли это сделать каким-либо отправленным данным? - person user782220; 20.02.2013
comment
Это будет техническая оценка, основанная на количестве отправляемых данных; задержка передачи; наличие повтора операции; транзакционные гарантии доступны на любом конце; и т. д. - person Recurse; 20.02.2013