Старая резьба ввода-вывода на модель клиента или модель реактора NIO?

Я пишу серверную сеть многопользовательской игры. Игра представляет собой РПГ, и она имеет максимальную максимальную мощность в 2000 игроков, но она практически не рассчитана на около 300 игроков, хотя она может быть выше или ниже. В течение самого долгого времени, каждый раз, когда мне приходилось заниматься сетью, где это касалось множества клиентов, я привязался к NIO, потому что не требовал использования сотен потоков. Недавно я столкнулся с презентацией в PowerPoint, где подробно описал две модели, и это почти заставило модель с потоком за клик выглядеть выше NIO. Я также нашел места, где указано, что старый IO может фактически превзойти и NIO.

Я еще не написал ни одного контента, поэтому для меня не было бы проблем начинать с самого начала, если бы мне пришлось изменить весь сетевой дизайн. На меня нет давления. Первоначально я разрабатывал реализацию шаблона реактора с помощью NIO (выберите событие, отправьте обработчик для обработки события).

Вся моя реализация реакторов предназначена для использования одного потока. Поскольку я читал, что старый IO может превзойти, это фактически поставило меня в дилемму. Я не хочу разрабатывать сложную систему NIO, которая использует несколько потоков, чтобы полностью использовать преимущества всей мощности процессора, но я также склоняюсь к идее о том, что одно приложение использует более 300 потоков. Какой дизайн подходит для моей цели? Преимущество потока на клиента заключается в том, что он действительно использует жгуты всей мощности процессора по своей природе, но в то же время он борется с системой. Не говоря уже о том, что размер стека в одном потоке занимает много памяти (при умножении на пару сотен раз). Должен ли я придерживаться схемы реактора?

Я знаю, что этот вопрос немного неоднозначен, но я чувствую, что мне нужно задать вопрос конкретно для моей ситуации, потому что я не мог найти вопрос на этом сайте или на веб-сайте, где он затрагивает проблему моего рода. Был один об игре, но игра предназначалась для обработки десятков тысяч игроков.

Спасибо большое! Если вам нужно какое-либо разъяснение, пожалуйста, спросите!

Ответы

Ответ 1

Я не хочу разрабатывать сложную систему NIO, которая использует несколько потоков, чтобы полностью использовать преимущества всей мощности процессора, но я также склоняюсь к идее о том, что одно приложение использует более 300 потоков. Какой дизайн подходит для моей цели?

Наши JVM работают с гораздо большим количеством 500 потоков постоянно (сейчас они сидят на ~ 700) с пиками в 1000-х годах. Я не вижу причин думать, что 800 нитей каким-то образом "съеживаются" достойно. Я начну беспокоиться, когда вы достигнете 10 000 потоков (в качестве номера шаров) - может быть, меньше, если вы работаете под 32 бит. Вам, безусловно, придется выделять больше памяти, когда вы попадаете в 1000, но что-то под потоками 1k не должно быть проблемой. Здесь хорошая страница номера создания потоков.

NIO наиболее эффективен, когда у вас есть большое количество подключений с редким IO. Он решает множество проблем, когда речь заходит о асинхронной связи, и есть что-то, что вы можете сделать с NIO, что "старый IO" не может выполнять с функциональной точки зрения (прерывистые каналы и неблокирующий IO, например), но один обработчик потока гораздо более простая модель, и я не удивлен, что она может превзойти реализации NIO во многих конфигурациях. С NIO вы выполняете много операций в коде Java, которые выполняются для вас в JVM или даже в ядре в собственном коде. Мультиплексирование потоков и обработка готовых IO - это все, что вы получаете "бесплатно" (с точки зрения сложности) с помощью модели "старого IO".

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