具有 Pub/Sub OnChange 的持久性 DataCache

Question

（以下问题有点长，如果您对持续兑现和通知不感兴趣，请随时按浏览器中的 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 说专门针对性能和可靠性

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

并建议alternatives to query notification 如：

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

（谢谢大家耐心等待！）

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

问题

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

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

Answer 1

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

Service Broker 本身会更符合要求，作为一种将通知与消费分离的方法。已经有large scale deployments 这样做了。使用 SQL Server 2012，您可以使用multicast。

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

如果您想采用 NoSQL 方式，那就是完全不同的讨论了。 Redis is the usual choice。但不要忽视真正的发布/订阅消息产品，例如 ZeroMQ。

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