Производитель / Потребитель в обработчике команд NServiceBus

Question

Поскольку NServiceBus, похоже, не поддерживает добавление механизма приоритетов в очередь сообщений, я хочу реализовать это сам.

• Командный обработчик (Производитель):

public void Handle(DoAnAction message)
{
  _messageManager.Insert(message);
}

• Один потребитель (другая нить):

public void Run()
{
  DoAnAction message;
  while (true) 
  {
    if (_messageManager.TryDequeue(out message)) 
    {
      doALongCall(message);
    }
    else 
    {
      Thread.sleep(200);
    }
  }
}

Это даже хорошая идея для начала? Мне не нравится идея, что я могу потерять сообщения таким образом.

Обновление : вариант использования: у нас много клиентов, которые могут отправить сообщение DoAnAction. Обработка этого действия занимает некоторое время. Проблема в том, что когда один клиент решает отправить 200 DoAnActions, все остальные клиенты должны ждать 2-3 часа, чтобы все эти сообщения могли быть обработаны (FIFO). Вместо этого я хотел бы обработать эти сообщения в порядке, основанном на клиенте.

Таким образом, даже если клиент A все еще имеет 200 сообщений для обработки, когда клиент B отправит сообщение, он будет поставлен в очередь следующим. Если клиент B отправит 3 сообщения, очередь будет выглядеть следующим образом: B-A, B-A, B-A, A, A, A, ...

Answer 1

Часто я обнаруживал, что настоящая причина для этого исходит с точки зрения бизнеса. В этом случае имеет смысл смоделировать его в коде, чтобы отразить правила и нормы, касающиеся бизнеса.

Представьте, что у вас есть сообщение SendEmail, но вы хотите «расставить приоритеты» для некоторых сообщений в зависимости от клиента, для которого он предназначен. Вы можете по-разному спроектировать вашу систему, чтобы у вас было два типа сообщений: один обычный SendEmail и один с именем SendPriorityEmail, который отправляется в другую конечную точку / очередь. Вам нужно будет указать в своем коде, какое сообщение отправить.

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

Answer 2

Вы можете использовать Sagas , чтобы сделать то, что вы ищете, по сути, имея один экземпляр саги на идентификатор клиента. Сага служит «точкой дросселирования» и может гарантировать, что одновременно обрабатывается только N сообщений для каждого клиента.

Это может снизить пропускную способность ниже максимальной емкости при более низких уровнях нагрузки, но может привести к более «справедливому» распределению, которого вы пытаетесь достичь.

Имеет ли это смысл?