Советы по масштабируемости для большого игрового сайта

Question

Я создаю веб-сайт, где игроки могут играть в пошаговую игру за виртуальные кредиты (например, покерный сайт, но другой).Настройка, которую я придумал:

• Один сервер данных, который содержит все учетные записи игроков со связанными данными (база данных + служба).База данных и API могут быть разделены на два сервера, если это поможет.
• Один или несколько веб-серверов, которые обслуживают веб-сайт и при необходимости подключаются к серверу данных.
• Один сервер лобби, где игроки могут найтиЕще и настройте игры (возможно несколько, но менее удобно для пользователя)
• Несколько игровых серверов, на которых запущена игра (все правила и тому подобное находятся на сервере, клиент - просто пульт дистанционного управления и просмотра),с одним балансировщиком нагрузки.
• Игровой клиент

Клиент будет сделан с Flash, веб-сервер будет использовать PHP.Все остальное - Java.

Связь

• Игрок заходит на сайт.Веб-сервер отправляет имя пользователя / пароль на сервер данных, который создает сеансовый ключ (например, файл cookie)
• Игрок запускает клиент.Клиент подключается к лобби-серверу, передавая сеансовый ключ.Сервер лобби проверяет этот ключ на сервере данных
• Как только лобби создано и игра должна начаться, сервер лобби выбирает игровой сервер из балансировщика нагрузки и настраивает игру на этом игровом сервере.
• Лобби-сервер сообщает клиентам подключиться к игровому серверу, и игра начинается.
• Когда игра заканчивается, игровой сервер сообщает серверу лобби.Сервер лобби проверит счет и обновит кредиты на сервере данных.

Протоколы :

• Java to Java: RMI
• PHP или Flash to Java: пользовательский двоичный протокол через сокет.Этот протокол поддерживает закрытие сокета в режиме ожидания, в то же время поддерживая виртуальное соединение живым и возобновляемым.

Если у клиента есть его желания, сайт должен будет поддерживать тысячи одновременных игроков.С этой информацией, вы можете увидеть какие-либо узкие места в моей настройке?Лично меня немного беспокоит существование только одного сервера данных, но я не уверен, как это разделить.Другие замечания по масштабируемости (или другие) также приветствуются.

Answer 1

В вашей архитектуре имеется множество отдельных сервисов, которые критически важны для ЛЮБОЙ части системы, чтобы работать для ЛЮБОГО пользователя.Я считаю, что эти SPOF с.

• Возможно, вы захотите рассмотреть sharding (или горизонтальное разбиение) для вашего сервера данных.
• Рассмотримнесколько лобби-серверов.Флэш-клиент может по-прежнему маскировать их как одно лобби, если вы хотите.Лично мне не нравится играть в игры с людьми, с которыми я не могу говорить ни на каком языке, который я не понимаю.Кроме того, мне не нравится присоединяться к лобби-серверу, который находит n-тысячу игр и никого не знает.Сделайте несколько лобби особенными (когда вы задумаетесь над этим, вы действительно сможете).Там нет реального использования для лобби с 10000 человек.Если вы все еще хотите пройти через это, вы все равно можете попробовать разделить, исходя из предположения, что игрок фильтрует по определенным параметрам (уровень противника, тип игры и т. Д.), Пытаясь разделить лобби по одному или даже нескольким критериям.
• Балансировщику нагрузки на самом деле не требуется достаточно энергии, чтобы быть физическим сервером.Почему бы не воспроизвести его на всех серверах лоббирования?Все, что нужно знать, это доступность / сервер.Предполагая, что у вас есть 10000 игровых серверов (что, я думаю, в данном случае - чертовски много) и частота обновления в 1 секунду (что здесь более чем достаточно), все, что вы синхронизируете, - это 10000 целых чисел в секунду (предположим, вы можетепредставлять доступность в виде числа (которое, я полагаю, вы можете)).Если вы придумаете что-то лучше, чем соединить каждый игровой сервер с каждым лобби-сервером, это даже не потребует слишком большого количества соединений на одном компьютере.

В этом типе приложений, я думаю, горизонтальное разбиениехорошая идея, потому что, с одной стороны, это может быть легко сделано и повышает надежность системы.Предположим, что ваши SPOF разделены, а не избыточны.Это проще и, возможно, дешевле.Если часть SPOF выходит из строя (скажем, 1 из 20 ваших независимых и физически распределенных серверов данных), это плохо, потому что 5% ваших игроков заблокированы.Но, вероятно, он скоро встанет.Если ваш SPOF избыточен, вероятность того, что что-то не получится, ниже.Но если это произойдет, ВСЕ заблокированы.Это проблема, потому что все будут пытаться подключиться к Интернету одновременно.Как только ваш SPOF вернется, на него будет на порядок больше запросов, чем обычно.И вы все равно можете использовать горизонтальное разбиение и избыточность одновременно, как это предлагается для службы балансировки.

Answer 2

Проработав пару игр на фейсбуке, я бы сказал:

Подумайте о масштабируемости для тысяч игроков, но вам нужно собрать десятки тысяч игроков, чтобы усилия по масштабированию для этих игроков окупились.

То есть, планируйте заранее, но подумайте о том, чтобы получить 1 игрока, прежде чем планировать систему для тысяч одновременно действующих игроков.

Я подозреваю, что описанная вами установка будет работать довольно хорошо для вашей первоначальной пользовательской базы. Во время сборки избегайте таких вещей, как: Требование к серверу входа в систему для связи с сервером лобби. Сделайте так, чтобы каждый сервер стоял отдельно, главное, что вас убьет, это взаимозависимость между службами.

Но самое главное, чтобы сделать это наиболее удобным для вас способом. Если у вас будет достаточно пользователей, чтобы облагать налогом вашу систему, это будет действительно хорошо. Вы можете нанять администратора базы данных, чтобы выяснить, как масштабировать , когда у столько пользователей.