我正在开发一个产品数据导入系统,该系统从外部源下载产品数据,将其转换为正确的模式,并存储结果 - 本质上是一个 ETL 系统。系统处理的核心消息类型是“ImportProductCommand”,它指定要导入的产品和来源。然而,导入命令很少单独发送。典型的业务需求是从给定来源导入整套产品。目前,这表示为“ImportProductsCommand”消息,可以指定要导入的多个产品。命令处理程序使用此消息,将其转换为单独的“ImportProductCommand”消息并将它们发送到队列进行处理。各个导入请求的使用者发布“ProductImportedEvent”或“ProductImportFailedEvent”。当接收到“ImportProductsCommand”消息时,服务会为该消息分配一个 GUID 令牌,将该消息放入队列中,然后返回该令牌。然后,该令牌用作关联 ID,以便各个导入请求可以与批量导入请求相关联。有了这个基础设施,就可以确定与给定令牌关联的事件数量,从而确定导入产品或失败导入的数量。缺少的是一个显式事件来指示批量导入已完成。单个导入请求的处理程序不会明确意识到它是批量导入请求的一部分。这当然可以通过了解要导入的产品数量以及计算与特定相关 ID 关联的导入事件的数量来推断。当前的实现利用消息队列系统来处理进程重新启动和失败,但对于批量导入请求不太明确。总的来说,系统需要回答的查询是:
- 给定的批量导入是否完成?
- 对于给定的批量导入,还剩下多少个单独的导入?
- 完成了多少个单独的导入?
- 有多少是错误的?
有哪些最佳实践或建议方法来支持这些查询并仍然利用消息队列系统来实现弹性?目前,将它们联系在一起的是上面提到的令牌,但是没有明确的记录来表示批量导入请求实体,如果有的话,那么单个导入请求处理器将需要知道这样的实体才能更新相应的状态。
所有这些都是使用 C#、NServiceBus 实现的,并作为 IIS WCF 应用程序托管。
这可以实现为NServiceBus 传奇 http://nservicebus.com/Sagas.aspx. 导入产品命令应该由一个处理佐贺(进口产品佐贺),并且 Saga 数据可以在发送导入产品命令. 进口产品传奇应该处理产品进口事件 and 产品导入失败事件。在处理的每个事件上进口产品传奇, 增量产品进口 or 导入失败的产品。还要检查 (ProductsImported + ProdctsFailedToImport) 的总和是否等于 ProdctsToBeImported,如果是,则完成传奇。
ImportProductsSaga 数据需要跟踪发送的 ImportProductCommand 数量和收到的回复,您可以计算待处理的回复等。
Saga 数据如下所示,例如:
public class ImportProductsSataData{
public Guid Id {get; set}
public int ProdctsToBeImported {get; set}
public int ProdctsImported {get; set}
public int ProdctsFailedToImport {get; set}
}
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)