Netty 4 - EventLoopGroup - EventLoop - EventExecutor - Сближение темы

Я изучаю код Netty 4.0.0.Alpha5, чтобы узнать, как обрабатывается threading. Я также прочитал введение в новую модель Threading Netty 4 в http://netty.io/wiki/new-and-noteworthy-in-4.0.html#wiki-h2-34.

Как я понимаю, цели заключаются в следующем:

  • Связывание потоков, привяжите канал к одному потоку (EventLoop). Я предполагаю, что этот подход был предпринят для уменьшения промахов в кэше и улучшения ситуации на оборудовании NUMA.

Итак, мне интересно, правильна ли моя интерпретация или нет. И если я прав, то возникает следующий вопрос:

  • Наличие возможно длинного канала ChannelHandler (например, операции с базой данных) в ChannelPipeline может блокировать EventLoop (Thread) и поэтому блокирует все другие каналы, назначенные одному и тому же EventLoop (Thread). Является ли это толкование истинным?
  • Пытаясь избежать этой проблемы, я могу использовать EventExecutor для длинного канала ChannelHandler, но в соответствии с документацией (см. ссылку выше) канал снова привязан к одному потоку в своем EventExectuor и, следовательно, может снова блокировать другие Каналы, которые назначил ту же тему (внутри EventExecutor). Я что-то пропустил или это правда?

Я просто пытаюсь понять, почему все так и есть, и получить некоторую информацию о намерениях проекта Netty 4.

ОТВЕТЫ

Ответ 1

Верно оба вопроса. Назначив обработчик группе событий, отличной от I/O, вы можете предотвратить блокирование потока ввода-вывода за счет длительных операций, таких как доступ к базе данных. Вы можете указать EventExecutorGroup с большим размером в зависимости от того, что делает обработчик. Это не очень отличается от того, что делает обычный пул потоков. Если пул потоков занят, любая попытка выполнить долго выполняющуюся задачу будет поставлена ​​в очередь.

Ответ 2

Ваши две точки также верны с Netty 3.

Netty 3 имел концепцию босса и рабочих потоков. Поток босса отвечал за принятие новых подключений, которые он затем выгружал бы в рабочий поток. Количество рабочих потоков настраивалось при создании NioServerSocketChannelFactory.

Теперь Netty 4 заменил эти боссы и рабочие потоки соответственно родительским циклом событий и циклом дочерних событий. Но основная идея осталась прежней: чтобы избавиться от модели нить за соединение, вы должны выделить более одного соединения с потоком.
Поэтому, когда вы создаете сервер, будет установлен фиксированный пул из N потоков, предназначенных для обработки соединений. Если количество подключений ниже N, то в потоке не будет более одного соединения. С другой стороны, если у вас более N соединений, некоторые потоки будут управлять несколькими подключениями. Это делается круговым способом, проверьте MultithreadEventExecutorGroup.next()