NServicebus 时间敏感的拍卖实现

发布于 2024-12-02 23:59:08 字数 759 浏览 0 评论 0原文

我们正在使用 NServicebus 设计一个必须解决拍卖场景的系统:我们想要向一组可以对某个项目进行投标的公司发送一条消息。收到所有出价后,我们希望将商品发送给出价最高者。

我们最初认为这种场景非常适合 NServicebus:用于发送消息(例如 BidOnItem 或 ItemAvailable)的 Pub/sub、为每个感兴趣的公司订阅该消息的消息处理程序以及用于存储我们收到的不同出价的传奇。我们完成了。

在正常的拍卖中,我们可以设置一个超时时间,比如 5 分钟,然后根据我们收到的最高价格决定谁获得该物品。我们没有那么奢侈。我们遇到的问题是,我们的特定场景有一个棘手的、不可协商的业务需求:拍卖对时间非常敏感。分秒必争。我们想要做的是在所有公司做出回应后立即决定谁获得该物品。通常这会在几秒钟内发生。我们希望在所有订阅者做出回应后立即做出决定。显然,我们仍然会实施超时,但这将是例外而不是规则。如果我们想确定是否每个人都已回复,我们需要类似订阅 BidOnItem 消息的所有端点上的所有处理程序的列表。 NServicebus API 似乎不提供此信息。

我们还必须实现一些未来的要求,这些要求以数据丰富和批准/拒绝决策为中心,如果了解发布/订阅通道上的所有处理程序是否都已响应,这些要求将大大受益。我知道这散发着请求/回复的味道,这是 NServicebus 不鼓励的,因为它会导致耦合,但这个要求感觉像是许多进程的基础,而这些进程很难在核心总线基础设施之外实现。从这个意义上说,它感觉很像 NServicebus 提供的 Saga.ReplyToOriginator。

解决这个问题的“NServicebus方式”是什么?

We are using NServicebus to design a system that has to solve an auction scenario: we want to send out a message to a set of companies that can bid on an item. After we've received all the bids we want to send the item to the highest bidder.

We initially thought this kind of scenario was perfectly suited for NServicebus: Pub/sub for sending out a message (e.g. BidOnItem or ItemAvailable), message handlers that subscribe to that message for each interested company and a saga for storing the different bids we receive and we're done.

In a normal auction we could set a timeout at say 5 minutes and then decide who gets the item based on the highest price we've received. We don't have that luxury. The problem that we've run in to is that our specific scenario has a tricky, non-negotiable business requirement: the auction is very time-sensitive. Seconds matter. What we'd like to do is decide who gets the item as soon as all companies have responded. Usually this will happen in a matter of seconds. We want to decide the second all subscribers have responded. Obviously we'll also still implement a timeout but that will be the exception rather than the rule. If we want to determine if everyone has replied we'd need something like a list of all the handlers at all the endpoints that are subscribed to the BidOnItem message. It appears the NServicebus API doesn't provide this information.

There are some future requirements we have to implement as well centered around data enrichment and approval/rejection decisions that would benefit greatly from knowing whether all handlers on a pub/sub channel have responded. I know this reeks of request/reply which is something NServicebus discourages because of the coupling it causes but this requirement feels like something that's fundamental for a lot of processes that is very hard to implement outside of the core bus infrastructure. In that sense it feels a lot like Saga.ReplyToOriginator which NServicebus does provide.

What would be the "NServicebus Way" to solve this problem?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

月牙弯弯 2024-12-09 23:59:08

在这些拍卖场景中,Pub/Sub 通常不是最佳选择。如果您的传奇会对您的投标人进行请求/响应怎么办?

S:OnAuctionCreated(包含投标人列表,或者您可以在某处获取它们)
foreach bidder in event.Bidders
-bus.Send(RequestBidFrom(投标人))
SetTimeout(X)

S:OnBidResponse
bids.Add(response.Bidder,response.Bid)

if(bids.Count()== Data.TotalBidders)
完成拍卖();

S:超时
完成拍卖()

Pub/Sub is usually not the way to go in these auction scenarios. What if your saga would do reguest/response with your bidders?

S: OnAuctionCreated (carries the list of bidders, or you could fetch them somewhere)
foreach bidder in event.Bidders
-bus.Send(RequestBidFrom(bidder))
SetTimeout(X)

S: OnBidResponse
bids.Add(response.Bidder,response.Bid)

if(bids.Count()== Data.TotalBidders)
CompleteAuction();

S:OnTimeout
CompleteAuction()

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文