背景
我们有一个大的（1500万）物品表，全天频繁更新（平均每天300K变化）。待处理的更改存储在临时表中，作业全天运行以从此表中读取更改，进行更新，并将更改标记为已处理。
许多其他应用程序使用items表中的数据来执行各种任务。通常，这些任务是预定的和密集的，因为它们涉及将实时数据与旧快照进行比较，并相应地更新其他系统。例如，我们在易趣上列出项目，并将实时项目数据与我们现有的列表进行比较，看看我们是否需要插入任何新的易趣列表，删除我们已售出的商品，更新数量等。因为数据太大，大多数这些应用程序很少运行，大部分时间都会过时。
我的问题：
我们正在考虑使用Service Broker实现发布者/订阅者模式。目标是在项目更改时发布消息，其他各种系统（如我们的eBay应用程序）可以订阅。这将使我们能够更接近实时地进行更细粒度的更新，而不是涉及查询所有数据的大型且不频繁的更新，而不仅仅是更改的内容。但是，在使用Google之后，似乎这不是一个常见的数据库模式，而且会引发危险信号。这不是Service Broker的有效用法（虽然我在发布Pub / Sub时在 Pro Sql Server 2008 Service Broker 中找到了一小部分）？这个问题通常如何解决？这似乎是一个普遍的问题。
TL; DR：
目标：当单个项目发生变化时，以动态，松散耦合的方式更新各种系统。
问题：使用Service Broker实现的发布/子样式解决方案是否可以在高容量设置中实现？
答案 0 :(得分：3)
这是非常常见的集成模式。
我不熟悉SQL Server Service Broker，但是如果你看看任何集成中间件堆栈--TIBCO，Oracle，webMethods，Mule，Informatica等 - 它们都提供了一个“数据库适配器”来执行你描述的任务。
一般模式是数据库中的更新会触发消息发布。这可以通过数据库表中的触发器或通过适配器“轮询”表进行新的更新来完成。这两种方法都有利有弊。
这种模式的主要好处是（正如您所怀疑的）更频繁和及时地更新其他系统 - 一种更“实时”的业务方式。此外，如果您执行到规范消息格式的转换，那么您将在系统之间获得更松散的耦合，因此在需要更改/更新系统时更少痛苦。
答案 1 :(得分：0)
这不是一种常见的数据库模式，因为大多数关系数据库都没有能力开箱即用。如果它没有Service Broker，也会使用Sql Server。
Service Broker talks about how Service Broker handles the challenges that most companies turn to NoSQL solutions for.
的开发人员之一我的理解是，Service Broker旨在完全满足您的需求。它甚至可以使用External Activation到run custom applications when the data has changed。
答案 2 :(得分：0)
通常这些类型的问题最终会变得比数据库集中的pub / sub实现提供的更大（范围）。如果我可以提出建议，请考虑使用全面的服务总线：
nServiceBus（免费达到一定规模，相当便宜）
您获得了一个坚实的发布/订阅框架，但易于使用，并且拥有庞大的客户，文章和示例用户群。