Я не уверен, как обратные вызовы «ставятся в очередь» при использовании node.js, что вызывает беспокойство.
У меня есть tcp-сервер, который получает сообщения от клиента node mqtt. Когда сообщение поступает в обратном вызове onMessage клиента mqtt, вызывается метод, который отправляет его всем подключенным TCP-клиентам. Сервер обрабатывает (в пике) около 150 сообщений в секунду по 50 - 300 байт каждое.
Время от времени случаются «таинственные» блокировки. Сервер работает, но сообщения клиентам не доставляются.
Мне пришло в голову, что возможно «новое» сообщение приходит до того, как сервер tcp закончит обслуживать клиентов с «последним» сообщением, и я не уверен, что это может запутать вещи. Я ожидаю, что функция, обрабатывающая «старые» обработчики сообщений, может быть помещена в стек в пользу более поздних поступлений, чтобы продолжить работу, когда все новые сообщения будут обслужены.
На данный момент я не использую никаких мьютексов или других устройств, чтобы предотвратить перекрывающиеся вызовы функции, которая доставляет сообщения. Итак, мой вопрос заключается в том, должен ли я доверять узлу и клиенту mqtt обработку этого уровня обмена сообщениями с возможным перекрывающимся прибытием или мне нужно встроить какое-то регулирование, создание очереди или мьютексирование машины? Если да, будет ли модуль kue логичным выбором?
