Можно ли определить одну сагу, которая будет обрабатывать много сообщений

Question

Моя команда рассматривает вопрос о том, можем ли мы использовать общественный транспорт в качестве основного решения для саг в RabbitMq (против NServiceBus). Я признаю, что наш опыт использования таких решений, как masstransit и nserviceBus, минимален, и мы начали внедрять обмен сообщениями в нашей системе. Поэтому я извиняюсь, если мой вопрос будет простым или даже глупым. Однако, просматривая документацию по общественному транспорту, я заметил, что не уверен, что это возможно для решения одного из наших случаев.

Случай выглядит так: Один из наших компонентов выдаст до 100 сообщений, которые будут быть «отправлен» в очередь. Эти сообщения являются результатом одной операции в системе. Все сообщения будут иметь один и тот же коррелированный идентификатор и наш внутренний идентификатор публикации (тоже одно и то же).

1) можно определить сагу одного экземпляра (по коррелированному идентификатору), которая будет ждать, пока не получит все сообщения из очереди, а затем обработать их как один пакет?

2) в противном случае, есть ли решение для обеспечения обработки всех отправленных сообщений? (Пакет согласованности?) Я предполагаю, что коррелированный Id будет служить способом для создания существующего экземпляра саги (singleton). В идеальном случае я хотел бы завершить экземпляр саги, когда система обработает каждое сообщение, принадлежащее одной группе (одной публикации)

Я тоже смотрю на CompositeEvent, но не уверен, что Я мог бы использовать его, чтобы «гарантировать», что каждое сообщение было обработано, и затем я позволил бы завершить сагу для указанного c коррелированного идентификатора.

Можете ли вы объяснить, как это могло быть достигнуто? И на какой механизм мне следует обратить внимание, чтобы связать id большого количества сообщений с одинаковым идентификатором с одной сагой, а затем завершить, если будут использованы все сообщения MSG?

Заранее благодарен за любой ответ

Answer 1

То, что вы описываете, это как работает корреляция по идентификатору. Это как из коробки.

Итак, вкратце - при правильной настройке корреляции для ваших сообщений все сообщения с одинаковым идентификатором корреляции будут обрабатываться одним и тем же экземпляром саги.

По второму вопросу - если вы не опубликуете sh отдельное событие, которое сообщит саге о том, какие сообщения она должна ожидать, как она узнает об этом? Вы можете определенно запланировать длительное время ожидания, пытаясь и предполагая, что в течение времени ожидания все сообщения будут получены сагой, но это ненадежно.

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

Answer 2

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

Пакетный образец

Каждый экземпляр саги имеет уникальный идентификатор корреляции, и до тех пор, пока эти сообщения могут быть соотнесены с этим единственным экземпляром, MassTransit будет управлять параллелизмом (optimisti c или pessimisti c, и в зависимости от механизма хранения саги).

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