Короткий ответ: это очень сильно зависит от архитектуры вашего приложения.
Похоже, вы думаете об этом, используя плохой анти-шаблон проектирования - пытаясь решить проблему масштабируемой обработки и аварийного отказа.восстановление одновременно в том же слое.Если каждый узел обрабатывает только часть данных, это не может быть отказоустойчивым для других узлов.Многие люди попадают в эту ловушку, так как масштабирование и DR могут быть реализованы с использованием типа федерации ... но не путайте механизм с целью.Я с уважением сообщаю, что вам нужно подумать об этой проблеме немного по-другому.
Способ решения этой проблемы заключается в двух совершенно отдельных слоях:
Уровень 1 - приложение.Разработайте высокоуровневый дизайн для вашего приложения, как будто нет требований к DR.Не обращайте внимания на тот факт, что может быть еще один экземпляр этого приложения в другом месте, который будет использоваться в DR.Сосредоточьтесь на функциональных аспектах и аспектах производительности вашего приложения - какими должны быть отдельные подсистемы, если таковые должны быть масштабированы по причинам рабочей нагрузки.Это приложение в целом обрабатывает 100% данных - решите, нужен ли в самом приложении подход горизонтального масштабирования / объединения - который не относится к требованию DR.
Уровень 2 -DR.Теперь подумайте о вашем приложении как о чёрном ящике.Сколько экземпляров черного ящика вам понадобится для удовлетворения ваших требований доступности и как вы будете поддерживать необходимую степень синхронизации между этими экземплярами?Каковы требования к производительности для восстановления после сбоев и восстановления (время доступности, допустимая потеря данных, если таковая имеется, сколько времени потребуется для запуска и запуска следующего аварийного переключения)?
Вернуться к уровню 1 - выберите реализациюподход для вашего высокоуровневого проекта, который использует подход восстановления и инструменты, которые вы определили на уровне 2. Например, если вы будете использовать подход DB «ведущий-ведомый» для синхронизации данных между узлами DR, сохраните все, что вы хотите сохранить, при отработке отказа вслой БД, а не в локальных файлах приложений или в памяти.Эти варианты зависят от выбранной вами структуры DR.
Дизайн уровня приложения и слоя DR взаимосвязан, но если вы выберете правильные инструменты и подходы, они не обязательно будут тесно связаны.Например, в Amazon Web Services вы можете использовать балансировку IP-нагрузки для пересылки запросов в экземпляр отказоустойчивого приложения, и если вы храните все соответствующие данные (включая сеансы и другие временные данные) в базе данных и используете возможность собственной репликации СУБД, это довольно просто..
Итог:
- Не путайте узлы масштабирования производительности (внутренние приложения) с узлами DR (целые приложения)
- Используйте свой выборПодход DR для принятия решений о реализации на уровне приложений
Удачи