具有Pub / Sub OnChange的持久性DataCache

Question

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

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

基本上用例是：

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

   1.1。 更新频率目前的范围是从1到10秒的1个Feed。但是后来我们可能会获得更多可伸缩性的东西。

   1.2。的卷即可。每个Feed大约有100K行（即使值没有改变，它仍然会在Feed中）

2. 值必须保持不变。一旦发生这种情况，就需要通知C＃服务器偶数。理想情况下与事件。由于Feed将包含理想情况下未更改的数据，因此服务器事件应与delta相关，而不仅仅是OnStuffChanged。

实施

因为系统正在使用SQL服务器，所以一些非技术人员已经签署了使用sql server进行实现的方法。这种闻到我不好的气味！但无论如何做了一些研究，发现了SqlDependency API上的Wrapper。

然而，我看到appi带有行李，形式为长约束（http://msdn.microsoft.com/en-us/library/ms181122%28v=sql.105%29.aspx）。我还看到MS说它对于次级演出来说并不是那么有效（目前情况不是这样，但可能会在将来发生）。

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

  

“当网络基础设施既不快速可靠，也不是通知量非常高时，查询通知可能不是应用程序的最佳选择，因为必须以亚秒响应时间接收通知。”< / p>

并建议alternatives to query notification，例如：

1. 在更新触发器之后（我不是触发器的忠实粉丝）在受监控的表上，其操作是使用SQL Server服务代理向需要通知的更新发送消息。 / LI>
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）中针对数据模型的事后想法。有显式程序用于通知订阅者并让您的应用程序明确地调用它们。不要混淆你的数据模型和yoru消息传递模式，你只会引入不必要的耦合。

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

顺便说一下，这些十字军东征（亲或反对，我不在乎......）最好与原型进行斗争。