Способность отказоустойчивости CometD - коммутатор VM во время перезапуска - PullRequest
Новая
       57

Способность отказоустойчивости CometD - коммутатор VM во время перезапуска

0 голосов
/ 11 октября 2019

У меня есть реализация чата, работающая с CometD.

На внешнем интерфейсе у меня есть Клиент, у которого clientId = 123 и он разговаривает с VirtualMachine-1

Соединение с длинным опросом между VirtualMachine-1 и клиент делается через clientId. Когда соединение устанавливается во время рукопожатия, VirtualMachine-1 регистрирует 123 clientId как свой собственный и принимает его данные.

По какой-то причине, если VM-1 перезапущен или FAILS. Соединение между клиентом и VM-1 с длительным опросом разрывается (поскольку VirtualMachine-1 не работает, периодические импульсы не будут работать, поэтому он будет отключен).

В этом случае CometD loadBalancer перенаправит клиентсвязь с новой VirtualMachine-2. Однако, поскольку VirtualMachine-2 имеет другой clientId, он не может понять «123», исходящий от клиента.

Мой вопрос - каково поведение cometD в этом случае? Как он перенаправляет трафик с VM-1 на новую VM-2, чтобы успешно пройти процесс установления связи?

1 Ответ

1 голос
/ 11 октября 2019

Когда клиент CometD перенаправляется на второй сервер с помощью балансировщика нагрузки, второй сервер не знает об этом клиенте.

Клиент отправит сообщение /meta/connect с clientId=123 ивторой сервер ответит 402::unknown_session и advice: {reconnect: "handshake"}.

Получив совет для повторного рукопожатия, клиент отправит сообщение /meta/handshake и получит новый clientId=456 от второго сервера. .

После рукопожатия хорошо написанное приложение CometD подпишется (даже для динамических подписок ) на все необходимые каналы и в конечном итоге будет восстановлено для работы, как прежде, почтипрозрачно.

Сообщения, публикуемые клиенту при переключении с одного сервера на другой, полностью теряются: CometD не реализует никаких постоянных функций.

Однако, сохраняющиеся сообщения до тех пор, пока клиент не подтвердил их,возможно: CometD предлагает несколько слушателей, которые вызываются реализацией CometD, и через этих слушателей приложениеication может сохранять сообщения (или другую информацию) в своем собственном постоянном (и, возможно, распределенном) хранилище: Redis, RDBMS и т. д.

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

Вы также хотите прочитать о функциях кластеризации CometD в памяти .

...