evs писал(а):Про серверные платформы, кластерные сервера, распределение нагрузки знаю. Second life реализована на одном из вида кластеров - grid.
Только я имел ввиду немного другое... Не техническую сторону, а программную. Я конечно понимаю, что техническая сторона очень важна и тесно связана с возможностями сервера, но вот к примеру будет ли Master Server или Photon или Smart Fox Server выдерживать такое кол-во коннектов, если он будет расположен на мощном grid'e.
П.с. Я не обижаюсь и всё это прекрасно понимаю:)
Хорошо, раз вы знаете устройство серверных систем, то должны прекрасно понимать, что сервера "Аля для всего - чего хочешь" - для таких нагрузок не предназначены. Приведу небольшой пример. У одного моего клиента на предприятии всего 50 машин, соответственно 50 пользователей и довольно небольшая нагрузка при работе с базами данных, ему вполне подходит работа с базами MySQL через web интерфейс (php + js). Нагрузку сервера держит машинка на уровне 2го пня, с 64 метрами памяти. У другого клиента более 100 сотрудников с одновременным доступом, вначале стояли те-же MySQL + веб интерфейс, разница вроде небольшая, но только количество запросов к серверу просто феноменальное. Нагрузка на сервер колосальная. Вначале поставили выделенный сервер на 2х ксенонах и 64 гига оперативки, сервер лагал, потом поставили еще один сервер и сделали распределение нагрузки, сервер продолжал лагать дальше. Вместо веб интерфейса разработал им клиентов - вроде стало легче, но производительность не повысилась (ушли только лаги сервера, ибо сняли с него нагрузку по обработке скриптов php). Тогда решили перевести все на MSSQL, производительность возросла, но только временно. Постепенно одни только временные таблицы начали занимать места больше чем база в несколько раз.
Боролись долго и очень серьезно, по этой работе можно книгу писать... Но не в этом суть...
В итоге получилось вот что:
Сервера: 4 шт.
1) Сервер авторизации (малый объем дискового массива, много памяти, служба проверки прав доступа, служба хранения промежуточных данных, служба мониторинга состояний двух предыдущих служб)
2) Сервера баз данных 2 шт с балансировкой нагрузки (Большие дисковые массивы, зеркалирование данных, служба синхронизации данных)
3) Сервер обработки запросов (Много-процессорный сервер с минимальным объемом дискового массива... Службы чтения и записи данных, служба балансировки нагрузки серверов БД)
На машинах у пользователей установлены клиенты...
Работа строится по следующему принципу:
Сервер авторизации хранит базу данных пользователей, их запросов и остальных параметров. Также хранит промежуточные таблицы данных - ответов на запросы.
Пользователь при подключении к серверу авторизации регистрируется, или логинится, потом с помощью клиента посылает или сохраняет данные запросов, которые проходят обработку на сервере обработки запросов, где разделяются на запросы записи или чтения данных, после чего проводится обработка запросов отдельными службами. Служба чтения, проверяет был ли аналогичный запрос от другого пользователя, если да, и с момента последнего обращения данные не изменились - посылает адрес и флаг для доступа к таблице, хранящейся в промежуточных таблицах на сервере авторизации, где проверяются привилегии доступа к отдельным полям, и если они соответствуют привилегиям пользователя пославшего запрос - передаются ему на клиент...
Если запрос уникальный, или с последнего запроса данные изменились, служба чтения выгребает с сервера баз данных данные и передает их серверу авторизации, где опять проверка прав доступа и пересылка (или не пересылка) данных клиенту.
Несколько более сложная система для записи данных, но ее к сожалению описать не могу, это в некоторой степени хлеб насущный и не для меня одного...
В итоге получили систему которая в нынешнем состоянии поддерживает более 1000 пользователей, обрабатывающих, вносящих и читающих огромные массивы данных.
Вот и думайте после этого о производительности и стандартных решениях...