Я пишу приложение, которое будет общаться с сетью Ethereum. Я решил разместить свои собственные узлы Parity в облаке с помощью GCP Kubernetes Engine. Я установил 3 реплики узлов для повышения доступности.
Есть ли какие-либо последствия, связанные с общением со случайным узлом с балансировкой нагрузки вместо того, чтобы всегда разговаривать с одним и тем же узлом?
Должен ли я учитывать тот факт, что я не всегда обращаюсь к одному и тому же узлу в коде своего приложения?
Редактировать: после некоторого исследования я думаю, что лучший способ справиться с этим - отправить одну и ту же транзакцию всем узлам одновременно, а не циклическую балансировку нагрузки.
Эта проблема характерна для использования IP-адресации:
Вообще говоря, IP предоставляет услугу доставки без установления соединения для пакетов переменного размера, которая не гарантирует упорядочение, доставку или отсутствие дублирования, а просто является наилучшим способом (хотя некоторые пакеты могут обслуживаться лучше, чем другие). Отправители могут отправлять на адрес назначения без априорной сигнализации, а получатели просто прослушивают уже подготовленный адрес без априорной сигнализации.
и сеансы не предназначены для этого:
При использовании нескольких серверов приложений возникает проблема: что происходит, когда пользователь отправляет запросы на сервер, который не знает о своей сессии? Пользователь вернется на страницу входа, поскольку сервер приложений не может получить доступ к его сеансу: он считается новым пользователем.
Несколько возможных решений можно использовать по отдельности или комбинировать:
Используйте кластерный сервер веб-приложений, где сеанс доступен для всех серверов.
Совместное использование информации о сеансе пользователя в базе данных или файловой системе на серверах приложений
Используйте информацию об уровне IP для поддержания сходства между пользователем и сервером.
Используйте информацию прикладного уровня для сохранения постоянства между пользователем и сервером.
Рекомендации
ivicaa
Dcompoze