Ответ 1
Во-первых, ваша диаграмма предполагает, что балансировщик нагрузки действует как прокси-сервер (TCP), что не всегда так. Часто используется прямая маршрутизация (или прямой возврат сервера) или выполняется NAT NAT назначения. В обоих случаях соединение между сервером и клиентом является прямым. Таким образом, в этом случае это, по сути, рукопожатие TCP, которое распределяется между серверными серверами. Для получения дополнительной информации см. Следующее:
Очевидно, что TCP-прокси существуют (HAProxy - один), и в этом случае прокси управляет обеими сторонами подключения, поэтому ваше приложение должно будет иметь возможность идентифицировать клиента по входящему IP/порту (что будет от прокси, а не от клиента). Прокси-сервер будет обрабатывать возврат сообщений клиенту.
В любом случае, это сводится к дизайну приложения, поскольку я бы предположил, что сложный бит имеет общий магазин сеансов (база данных определенного типа или хранилище значений key = > , например Redis), так что, когда ваш сервер приложений говорит "Мне нужно отправить сообщение Фрэнку", он может определить, с какого серверного сервера Фрэнк подключен (от БД), и сигнализирует, что сервер отправит это сообщение. Вы уменьшаете проблему соединений (от одного и того же клиента), перемещаясь по различным серверным серверам, имея постоянные соединения (все балансировки нагрузки могут это сделать) или используя что-то внутренне постоянное, как websocket.
Это, вероятно, огромное упрощение, поскольку у меня нет опыта работы с чат-программным обеспечением. Очевидно, что сами серверы БД могут быть распределены между несколькими машинами, для отказоустойчивости и балансировки нагрузки.