4

（以下问题有点长，所以如果您对持续兑现和通知不感兴趣，请随时按浏览器中的 x 按钮！）

我们的任务是实现一个持久的数据存储，它将保留大量的数字信息。

基本上用例是：

  1. 您将获得包含需要在数据存储中传播的数据更新和插入的提要。

    1.1。当前更新频率范围为 1 到 10 秒的 1 个提要。但稍后我们可能会得到更多，因此可扩展性很重要。

    1.2. 卷。每个提要大约有 100K 行（即使一个值没有改变，它仍然会在提要中）

  2. 这些值需要被持久化。一旦发生这种情况，则需要将事件通知 C# 服务器。理想情况下有一个事件。因为提要将包含理想情况下未更改的数据，所以服务器事件应该与增量一起出现，而不仅仅是OnStuffChanged.

执行

由于系统使用的是 SQL server，一些非技术人员已经签署了使用 sql server 的实施方案。这种味道对我来说很糟糕！但无论如何，做了一些研究，发现了关于SqlDependency API 的 Wrapper。

然而，我看到该 appi 带有一个行李箱，以一长串约束( http://msdn.microsoft.com/en-us/library/ms181122%28v=sql.105%29.aspx) 的形式出现。我还看到 MS 说它在亚秒级性能方面效率不高（目前不是这种情况，但将来可能会如此）。

专门针对性能和可靠性 MS 说

“当必须以亚秒级响应时间接收通知、网络基础设施不是既快速又可靠时，或者当通知量非常高时，查询通知可能不是应用程序的最佳选择。”

并建议查询通知的替代方法，例如：

  1. 在受监视表上更新触发器（我不是触发器的忠实粉丝）之后，其操作是使用 SQL Server 服务代理向需要通知的更新发送消息。
  2. 实现存储和通知的自定义中间件。

（伙计们，谢谢你们的耐心！）

所以重点是我真的觉得除了自定义中间件这些想法都不好。

问题

  • 有没有人亲身体验过SqlDependency和Service Broker？您是否认为我应该开始对 mgmt 进行讨伐以防止技术错误首先发生？
  • 我有点想也许我应该使用类似redis/memcached/mongo数据缓存的东西。它们提供持久性。我确信我可以找到一种方法将它们与关系数据库连接起来，并将更改的/新的数字提供给服务器进行处理。这不是更有意义吗？
  • 也许我只是过度设计了这件事。我是否应该尝试其他建议（建议的类似 stackoverflow 问题`）？

为冗长的帖子道歉！如果您到目前为止还费心阅读，请提前感谢您！

4

1 回答 1

4

不要使用 SqlDependency，它不适合它。SqlDependency 是监控很少变化的数据（例如参考数据）。使用 SqlDependency，您只会收到数据已更改的通知，不知道更改的内容，您必须自己查询。

作为将通知与消费分离的一种手段，Service Broker 本身会更好地满足要求。已经有大规模部署这样做了。使用 SQL Server 2012，您可以进行多播。

但绝对不是通过触发。通知应该是您的应用程序中的一等公民，而不是附加到 atrigger ( ughhh ) 中的数据模型的事后想法。有明确的程序来通知订阅者，并让您的应用程序明确地调用它们。不要混合你的数据模型和你的消息传递模式，你只会引入不必要的耦合。

如果您想采用 NoSQL 方式，那将是完全不同的讨论。Redis 是通常的选择。但不要忽视真正的发布/订阅消息传递产品，例如ZeroMQ。

顺便说一句，这种十字军东征（赞成或反对，我不在乎......）最好与原型作战。

于 2012-07-10T15:47:31.177 回答