asp.net - 跨服务器场的 Web 用户的 WF 工作流？

Question

我们希望使用 Windows Workflow 来引导我们的 Web 用户沿着导航路径前进。

我们有一个服务器场，因此这转化为每个用户的长时间运行的工作流；多个服务器必须知道的。

到目前为止，我们的原型(prototype)是 WorkflowApplication 和 SQL Persistence Provider 的使用。这可行，但我们担心所有 SQL Server 事件及其性能。

我们发现有人创建了一个 AppFabric 缓存持久性提供程序 (blog post here)，这对我们很有吸引力，因为这意味着将我们的工作流水合到 RAM 而不是 SQL；但他们明确表示它没有经过生产测试。

有什么建议、想法或建议吗？

Answer 1

不幸的是，与大多数与性能相关的问题一样，除了:用您的真实场景进行测试并查看之外，没有其他好的答案。

我们将纯 SQL 持久性用于购物车风格的工作流程，并且其性能没有问题。我们甚至提取了几个提升的属性，这增加了一些存储开销。但是，我的负载不是您的负载，我的工作流程也不是您的工作流程，因此这并不意味着它适用于您的场景。

对于网络农场场景，我要给出的一个建议是，您确保将 sqlWorkflowInstanceStore/@instanceLockedExceptionAction 设置为归属于 AggressiveRetry .这样做的原因是，在农场场景中，通常您具有将请求路由到 diff 的模式。因此，如果两个调用连续快速进入，则工作流的第一个请求可能会发送到服务器 A，第二个请求可能会发送到服务器 B。服务器 A 可能已经响应，但由于持久性与响应异步，它可能当第二次调用进入服务器 B 时，服务器 B 仍然保持不变。服务器 B 第一次可能不会获得锁，因为服务器 A 正在完成持久性，因此它将进入重试例程。如果不指定 AggressiveRetry ，然后 BasicRetry将被使用，并且使用一种非常缓慢的线性算法，这将表现为您的工作流程看起来很糟糕的服务性能。 AggressiveRetry另一方面，将使用一种算法，它会“退避”更多的失败。由于服务器 A 很可能很快就会完成，因此您通常会在前几次尝试中获得锁定。

就 AppFabric Cache 实现而言，我个人不会使用该确切实现，因为它不能保证任何持久性。缓存可能会关闭，缓存可能需要清除其 LRU 对象，其中可能包括您的工作流实例等。如果有的话，我建议使用缓存通读实现，其中所有写入/锁定调用都是针对 SQL 完成的，但是用于反序列化工作流的实际数据可能来自缓存。这显然不会产生那么大的影响，但是......仍然比从 SQL 服务器读取要好。另一种可能性是 AppFabric Cache 1.1 添加了缓存读/写提供程序。因此，现在您理论上可以将上面链接的实现与缓存读/写提供程序实现结合使用，该实现实际上在幕后进行 SQL 存储调用，并且从应用程序的角度来看可能具有两全其美，因为它只会永远处理缓存，提供程序将异步写入 SQL 存储。