Дабы избежать холиваров, скажу лишь, что выбор .NET был в большей степени обусловлен тем, что те, кто начинали компанию, имели больший опыт в нём, т.е. технологии были более знакомыми. Ну и рынок .NET разработчиков достаточно большой. А так достойные проекты можно делать на огромном множестве технологий и подходов.

Я больше имел в виду, что в случае с HttpListener придётся самостоятельно регулировать количество запросов, обрабатываемых одновременно, отслеживая количество выполненных и завершенных GetContextAsync методов, и т.д.. В этом ничего очень сложного нет, но IIS пока за нас неплохо справляется :)

Да, всё верно поняли. Предлагаю посмотреть www.youtube.com/watch?v=S7fZFpXFWU8. Там всё более подробно, и про велосипеды, и про масштабируемость :)

У нас местами не слишком реляционная структура, поэтому отдельно по таблицам не всегда будет эффективно, подробности здесь www.youtube.com/watch?v=S7fZFpXFWU8 :). Спасибо за отзыв :)

Целиком в память у нас не поместится, к сожалению

Спасибо, с интересом изучу :)

Было бы интересно узнать о Вашей специфике

У всех свои условия :)

Под железкой имелся в виду целый сервер :).

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

Если синхронно сохранять, то согласованность сохранит и надежность обеспечит. Write-ahead log никто не отменял :)

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

База дает большую гарантию надежности. Несколько раз было, конечно :)

По поводу обработки в одном потоке — вы имели в виду вообще всех пользователей? Логика достаточно тяжелая, одного потока будет мало :). Параллельно обрабатывается много пользователей

Вы наверняка правы, но лучше начинать с замеров и реального профиля нагрузки, и тогда уже принимать решения :)

Дмитрий, спасибо за вопрос. Если в общем, на примере стратегий, то игрок развивает свою базу, и взаимодействует с другими игроками (например, грабит :)). В первом случае он, отправляя посредством клиента команды на сервер, действует по простому сценарию: загрузили пользователя в кэш (если его там нет), заблокировали, выполнили валидацию, изменили состояние, сбросили в базу, разблокировали, оставив в кэше. С огромной вероятностью следующий запрос от этого игрока найдёт его в кэше. Собственно вся статья о том, как совмещать данный сценарий, с, например, необходимостью вытеснения неактивных игроков (которые не играют или с которыми сейчас не играют). Более сложный сценарий возникает, когда мы хотим кого-нибудь ограбить, здесь уже наступает время использовать шину сообщений, по которой необходимые данные и команды будут доставлены другому игроку, и там вариант простого сценария повторится с некоторыми поправками на работу с сообщениями. Т.е. в одной такой «длинной» транзакции все сущности блокируются поочередно, что позволяет избежать взаимоблокировок. Это схоже с моделью актёров, или системы, подобные mpi. Почему сделали так вместо использования распределённых транзакций — можете посмотреть здесь, в большом докладе «обо всём» www.youtube.com/...tch?v=S7fZFpXFWU8&t=1157s. Спасибо :).

Дмитрий, спасибо за интерес к нашей статье. Вы затронули много вопросов, которые не раскрыты в ней. Если хотите узнать больше, пожалуйста, посмотрите видео доклада, в котором наши подходы раскрываются шире youtu.be/S7fZFpXFWU8. И я буду рад обсудить любые возникшие вопросы здесь, или в linkedin. Спасибо :)