Стоит ли использовать подобный метод балансировки?
Здравствуйте.
Хотелось бы узнать в профессионалов в проектировании архитектур высоконагруженных проектов в подобном подходе:
1. Запрос от пользователя идёт на кластер-балансировщик.
2. Кластер определяет тип запроса (например, что это поисковый запрос - на этом примере рассмотрю).
3. Кластер выбирает самый близкий географически и наименее нагруженный кластер для поисковых запросов, после чего отдаёт ему запрос и ждёт от него ответа.
4. Поисковый кластер, в свою очередь, скармливает запрос сначала кластеру для стемминга запроса (подбирает самый близкий и наименее загруженный).
5. Поисковый кластер кормит запрос самому близкому и наименее загружённому кластеру для классифицирующей нейросети.
6. Поисковый кластер кормит запрос самому близкому и наименее загруженному кластеру с мета-файлами, где выбирается N результатов и они сортируются методом обратной частоты.
7. Поисковый кластер собирает ответ и отдаёт его кластеру-балансировщику.
8. Кластер-балансировщик отдаёт ответ пользователю.
Передаётся строка небольшой длины — от 1 до 10 слов, в ответ приходит JSON-строка с указанным количеством (20-100) элементов и идентификатор последнего обработанного мета-файла (он же служит ID для записи в СУБД).
Сами сервера (участники кластеров) написаны на Python, использую сырые сокеты.
Хотелось бы узнать: пригоден ли данный способ с ориентацией на 10000+ RPS?
Так же я думаю, что играет роль бутылочного горлышка сам кластер балансировки, так ли это?
слишком много перенаправлений
очевидно что балансировщик и все узлы кластера должны стоять в одном месте иначе это полностью теряет смысл, отправляйте тогда поисковый запрос сразу на поисковый сервер ближайший. нахрена тут какой то балансировщик и перенаправление ? просто еще одна точка отказа и дополнительный узел чтобы увеличить время ответа что ли?
Sergey Grigorov, ну можно легко от него избавиться разбив это все под доменам, в итоге просто ненужная вещь, лишние затраты, узкое горлышко, единая точка отказа.
Сложный
Простой
