Преминавам през известно преосмисляне на мащабните мултиплейър игри в ерата на Facebook приложенията и облачните изчисления.
Да предположим, че трябва да създам нещо върху съществуващи отворени протоколи и искам да обслужвам 1 000 000 играчи едновременно, само за да обхвана проблема.
Да предположим, че всеки играч има опашка от входящи съобщения (за чат и какво ли още не) и средно още една опашка от входящи съобщения (гилдии, зони, инстанции, търг, ...), така че имаме 2 000 000 опашки. Играчът ще слуша 1-10 опашки наведнъж. Всяка опашка ще има средно може би 1 съобщение в секунда, но определени опашки ще имат много по-висока скорост и по-голям брой слушатели (да речем, опашка за „локация на обект“ за екземпляр на ниво). Нека приемем, че латентността на системната опашка е не повече от 100 милисекунди, което е добре за умерено ориентирани към действие игри (но не и игри като Quake или Unreal Tournament).
От други системи знам, че обслужването на 10 000 потребители на една 1U или блейд кутия е разумно очакване (ако приемем, че не се случва нищо друго скъпо, като симулация на физика или какво ли още не).
И така, с кръстосана клъстерна система, където клиентите се свързват към шлюзове за връзка, които от своя страна се свързват със сървъри за опашки за съобщения, ще получим 10 000 потребители на шлюз със 100 шлюзови машини и 20 000 опашки за съобщения на сървър за опашки със 100 машини за опашки. Отново, само за общ обхват. Броят на връзките на всяка MQ машина ще бъде малък: около 100, за да се говори с всеки от шлюзовете. Броят на връзките на шлюзовете ще бъде много по-висок: 10 100 за клиентите + връзки към всички сървъри на опашка. (Освен това добавете някои връзки за сървъри за симулация на света на играта или какво ли още не, но засега се опитвам да запазя това отделно)
Ако не исках да създам това от нулата, трябваше да използвам някаква инфраструктура за съобщения и/или опашка, която съществува. Двата отворени протокола, които мога да намеря, са AMQP и XMPP. Предназначеното използване на XMPP е малко повече като това, от което тази игрова система би се нуждаела, но режийните разходи са доста забележими (XML, плюс подробните данни за присъствие, плюс различни други канали, които трябва да бъдат изградени отгоре). Действителният модел на данни на AMQP е по-близък до това, което описвам по-горе, но всички потребители изглеждат големи корпорации от корпоративен тип и работните натоварвания изглежда са свързани с работния процес, а не с актуализация на играта в реално време.
Някой има ли дневен опит с тези технологии или техни реализации, който можете да споделите?
