【问题标题】:WCF service running a background thread to speed up execution timeWCF 服务运行后台线程以加快执行时间
【发布时间】:2011-12-28 13:12:48
【问题描述】:

我有一个为多个客户提供服务的每次调用 WCF 服务。我希望通过运行一些后台进程来加速服务,这样它们就不会阻塞或减慢服务的主要功能。

一个例子是主函数需要返回一组数据,而后台线程需要根据参数记录一些统计数据。

代码:

Public Function GetAccountDetails(id As Integer) As AccountDetails

    Dim retVal As New AccountDetails
    Dim a As New Accounts
    retVal = a.GetAccountDetails(id)

    Dim t As New Thread(New ThreadStart(Sub()
                                             Dim s As New Statistic
                                             s.StatisticType = StatisticType.GetAccount
                                             s.Parameter = id.ToString
                                             s.Record()
                                        End Sub))
    t.Start()

    Return retVal

End Function

如果我使用这个后台线程来记录统计数据,它不会阻止主线程将数据返回给客户端。

它在测试场景中运行良好,但我的问题是,在将数据返回给客户端之前让这个线程执行而不加入它有什么危险吗? 统计数据可能会丢失吗? 服务器端会不会有潜在的内存问题?

谢谢。

【问题讨论】:

  • 我不完全理解为什么你想这样做......在每次调用的场景中,每个传入的请求都有自己的、单独的服务类实例- 完全独立于其他请求正在做什么。我认为通过在服务类中使用后台线程来增加更多复杂性没有任何好处......
  • 不允许客户端直接记录统计信息,只有服务可以。没有公开的服务。服务必须记录统计数据,这是一种加快数据返回客户端速度的方法——让后台线程完成客户端不需要知道的工作。

标签: vb.net multithreading wcf web-services thread-safety


【解决方案1】:

这种方法是一种“延迟写入”模式,并不罕见。

主要问题是:

  • 您不会获得统计表的连贯视图,它总是滞后于实际使用情况。这种“最终一致性”通常非常适合日志记录或统计信息,但不适用于需要在事务上正确的更新。

  • 在统计信息表更新期间没有处理错误的机制:调用服务将继续,很高兴没有意识到问题。对于您的情况,这可能不是问题:如果您要做的只是登录并继续,那么您可以继续使用相同的策略

  • 如果您的服务变得非常繁忙,您将产生大量的线程来淹没您的服务器。

最后一点可以通过引入一个队列(类似 MSMQ 很好)来获取统计更新请求​​消息和一个可以处理请求的工作服务来解决。然后,您可以一次性限制处理的更新数量。这确实增加了架构(和测试!)的复杂性,但使您的系统更具可预测性,尤其是当您的流量不是单一的一致流时。

【讨论】:

  • 感谢您的回答。第一个问题无关紧要,因为我们在第二天整理统计数据——确切的时间不需要很精确。在统计级别处理错误也不让我担心。第三点很有趣,我会密切关注——我预计不会有任何直接的问题,因为服务箱目前根本没有过度工作。谢谢。
  • 不客气。最后一件事:记住你的s.Record() 方法需要是线程安全的。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-02-05
相关资源
最近更新 更多