Распределенное восстановление - это можно сделать без тайм-аута?
У нас есть приложение для отправки почты, которое получает кучу писем в одном блобе, а затем помещает все эти письма в базу данных. Это может занять до десяти минут. Во время этого процесса состояние рассылки BUILDING
,
Когда это закончено, состояние изменяется на READY
,
Когда сервер выходит из строя (конечно, этого не должно происходить) и перезапускается, он ищет все почтовые сообщения со статусом BUILDING
и помечает их как ERROR
, Это происходит потому, что мы никогда не хотим отправлять неполные рассылки.
Теперь мы хотели бы увеличить масштаб использования второго сервера. Стратегия восстановления выше не работает здесь.
например, сервер 1 BUILDING
рассылка, а сервер 2 вылетает и перезагружается. Теперь сервер 2 увидит BUILDING
рассылки и не знает, была ли она прервана или запущена на другом сервере.
Какова лучшая стратегия восстановления распределенных сервисов?
(Мы подумали о каком-то механизме тайм-аута, где BUILDING
сервер обновляет временную метку каждые несколько секунд, и когда какой-либо сервер перезагружается, он проверяет, есть ли BUILDING
рассылка, которая не обновлялась в течение х минут. Тогда вполне возможно, что эта рассылка была прервана.)
РЕДАКТИРОВАТЬ:
Чего я хотел бы добиться: если какой-либо сервер перезапускается (после сбоя или просто потому, что мы добавили новый почтовый сервер в кластер), он не должен помечать почтовые сообщения как ERROR
если эта конкретная рассылка действительно создается (другим сервером).
Приятно иметь: если это будет работать без сохранения идентификаторов серверов, потому что тогда можно легко добавлять и / или удалять серверы. В противном случае было бы невозможно полностью удалить какой-либо сервер, потому что тогда может быть BUILDING
рассылка с этим конкретным идентификатором сервера. Но этот сервер был удален и больше никогда не запустится. Хотя единственный сервер, который мог установить рассылку ERROR
уйдет
1 ответ
Добавьте к отслеживанию состояния две вещи: временную метку и работающий на ней сервер.
Если сервер запускается и видит что-либо в состоянии сборки для себя, он знает, что это не удалось. И наоборот, если он запускается и видит что-то в состоянии сборки для другого сервера, у него теперь есть информация, которую он должен будет просмотреть позже, чтобы выяснить, есть ли проблема, которую необходимо решить. Вам нужно беспокоиться о одновременной перезагрузке нескольких серверов, чтобы при запуске сервер не мог просто захватить все старые пакеты для всех серверов.
Или вы можете просто использовать службу кластеризации для вашей ОС.