стратегия расщепления

Question

В проекте реального времени у меня есть стандартный интерфейсный сервис, основанный на событиях, получающий сообщения от брокера очереди сообщений. Этот сервис предназначен для предоставления немногим другим соответствующей информации. По сути, эта служба зацикливается на методе приема, демонтирует пакет (например, protobuf), обновляет / контролирует несколько параметров, выполняет маршалирование в другой формат (например, JSON), а затем pu sh в следующую службу.

Вопрос заключается в следующем: как запустить goroutine для наиболее эффективной общей пропускной способности, с приоритетом для входящих данных?

Сегодня моя точка зрения заключается в том, что наиболее трудоемкой операцией является процесс демаршаллинга / маршаллинга. Таким образом, я бы запустил goroutine следующим образом после получения любых событий (для которых не требуется ACK):

[...]
var rcvBuffer []byte
for {
   err := evt.Receive(ctx, rcvBuffer)
   go convertAndPush(rcvBuffer)
}

[...]
func convertAndPush(rcvBuffer []byte) {
   // unmarshall rcvBuffer
   // control
   // marshall to JSONpack
   JSONpack := json.Marshal(rcvBuffer)
   // fan out to another goroutine communicating with other services...
   pushch <- JSONpack
}

Я сосредоточен на получении пакетов, а не на блокировке процессора из-за запросов ввода-вывода (либо в - или нет), а не блокирование ввода-вывода из-за самых дорогостоящих операций моего приложения, выполняемых ЦП.

Является ли такой способ разработки приложения правильным? Чего мне не хватать?

btw, Функция приема сообщений не запускает процедуру.

Answer 1

+ 1 с подходом Пола Ханкина.

По моему опыту, лучше всего ограничивать параллелизм convertAndPush. Это можно легко сделать, используя семафор или каналы и шаблон рабочего пула. Это также предоставляет переменную для переключения во время нагрузочных тестов (размер рабочего пула).

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