Проблема доступности

Question

Архитектура: Группа клиентов отправляет сообщения на сервер, который находится за VIP. Очевидно, этот сервер представляет риск доступности.

Клиент следит за ресурсом, а сервер отвечает за принятие мер в зависимости от того, о каком статусе ему сообщает большинство клиентов, и, следовательно, о необходимости только 1 сервера / лидера.

Я подумываю добавить еще один сервер в качестве резервной копии для VIP, который включается только при сбое первого сервера. Однако при создании резервной копии у нее не будет никакой информации для обработки, и она будет терять время, ожидая, когда клиенты сообщат, и ожидая требуемые пороговые значения и т. Д.

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

Solution1: Я подумал о том, чтобы сервер перенаправлял информацию о состоянии клиента на сервер резервного копирования, и в случае сбоя при запуске сервера резервного копирования он может получить его оттуда.

Есть ли другой способ сделать это? Я думал о наличии общего / общего места для хранения информации о состоянии, откуда оба сервера могут читать информацию о состоянии клиента. Но это не работает, так как общее пространство - это тоже единственная точка отказа.

Answer 1

Существуют различные продукты распределенного кэширования, которые делают то, о чем вы здесь говорите. Некоторые из них поставляются с серверами приложений, такими как dynacache WebSphere и Object Grid. Фактически ObjectGrid может использоваться в JSE, нет необходимости в сервере приложений.

В этих продуктах распределенного кэша используются различные модели push и pull с сообщениями pub-sub для обеспечения согласованности между экземплярами. Работая в IBM, я фанат ObjectGrid, но, более важно, я не изобретаю колеса. Я полагаю, что эти вещи могут быть довольно сложными, и, следовательно, поиск чего-то готового может сэкономить нагрузку - здесь есть ссылки на различные открытые решения .

Answer 2

Очень сильно зависит от того, насколько доступным должно быть ваше решение (сколько 9). Существует спектр решений.

Облегченный можно создать вокруг Memcache : чрезвычайно быстрое распределенное состояние. Например, он широко используется в Google AppEngine.

Answer 3

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

Этот подход обычно используется большинством баз данных; если вы используете один из них в качестве своего бэкэнда, вы сможете получить поддержку для этого с небольшим количеством работы.

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