如何使用分散/聚集模式在MassTransit 3.0中实现传奇

Question

Jimmy Boagard描述了麦当劳快餐连锁店,将其与分散聚集模式进行比较 .

从上面文章中窃取的工作流图像:

初步实施思路:

为所有食品站所能获得的所有类型的FoodOrdered事件建立一个共同界面,然后每个食品站将能够消费/创建其各自的项目并发布共同的完成事件.例如:薯条和汉堡站收到关于薯条顺序的消息,薯条站消耗该命令宣布该传奇正在监听的ItemDoneEvent.

最初的担忧:

由于佐贺不关心食品的完成只是一个事实,即所有的食物都完成了类型这似乎是一个确定的解决方案.然而后阅读警告这里关于队列的共享和注意到,Consumer.Conditional过滤已与MassTransit 3.0去除感觉好像框架说:"坏事(TM)会发生"这种类型的方法.但是我不知道如果不为厨房中的每个食品项目创建消息请求和响应并关联事件,您还能做到这一点.例如:FriesOrdered,BurgerOrdered FriesCooked,BurgerCooked.如果您必须为厨房中的每件物品做这件事,这将非常繁琐？

鉴于上述问题 - 这种类型的工作流程的一个好的传奇示例是什么样的？

Answer 1

将已完成的事件退回到 saga 的问题是，它会在共享资源（即 saga 状态）上产生争用。

吉姆在您引用的那篇文章之后发布了另一篇文章，概述了问题和解决方案。当然，他专门谈论NServiceBus，但问题和概念是相同的。

https://lostechies.com/jimmybogard/2014/02/27/reducing-nservicebus-saga-load/

创建外部存储。为每个工作项目建立记录。让每个工作人员将自己的工作设置为完成，而 saga 使用延迟消息有效地进行轮询，以查看所有工作是否已完成。

那么你仍然在进行分散-聚集，但“聚合器”已被流程管理器模式取代，以减少争用。