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

Question

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

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

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

Коммуникации

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

Протоколы:

• Java для Java: RMI
• PHP или флэш в Java: Пользовательские двоичный протокол через гнездо. Этот протокол поддерживает закрытие сокета в режиме ожидания при сохранении виртуального соединения и его возобновлении.

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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