我正在寻找一个最佳实践或示例，说明我如何能够为给定 SQL Server 2008 R2 db 上的所有更新事件生成事件。为了更具描述性，我正在开发一个 POC，我基本上会将更新事件发布到一个队列（在我的例子中是 RabbitMq），然后可以由各种消费者使用。这将是通过事件溯源实现 CQRS 仅查询数据模型的第一部分。通过放置在 que 上，任何人都可以订阅这些事件以复制到任意数量的仅查询数据模型中。这部分很清楚并且定义相当明确。我遇到的问题是确定从 SQL 服务器生成事件的最佳方法。我得到了一些想法，例如监控事务日志和 SSIS。但是，我不完全确定这些选项是否可行甚至可行。
有没有人对这种事情有任何经验或对如何进行这样的冒险有任何想法？任何帮助或指导将不胜感激。
您无法监视日志，因为即使您能够理解它，也存在在您有机会阅读之前日志被回收的问题。除非日志以某种方式标记为不被截断，否则它将被重用。例如，当启用事务复制时，日志被固定直到被复制代理读取，然后才被截断。
SSIS 是一个非常广泛的概念，说“使用 SSIS 检测变化”类似于说“我将使用编程语言来解决我的问题”。详细信息是您将如何使用 SSIS？无论是否使用 SSIS，都无法可靠地检测任意模式上的数据更改。即使是专门设计用于检测更改的数据模型也存在问题，特别是在检测删除方面。
然而，有可行的替代方案。您可以部署变更数据捕获并委托给引擎本身以跟踪变更。使用这些检测到的更改并将它们发布给消费者（如果您愿意，可以通过 RabbitMQ）是SSIS 擅长的事情。但是您必须了解，SSIS 不适合连续的实时任务。它被设计为定期批量运行，因此当 SSIS 作业运行时，您的更改通知使用者将收到峰值通知，且延迟时间很长（分钟）。
对于实时方法，更好的解决方案是Service Broker。一种可能性是SEND来自触发器的 Service Broker 消息，但我不推荐它。更好的设计是让应用程序本身SEND在进行数据修改时通过显式发送消息来发布更改。借助 SQL Server 2012，可以将Service Broker 消息多播到其他 SQL Server 消费者（包括 SQL Server Express）。SSB 消息传递是完全事务性的（如果事务回滚，则不会发送消息）并且不需要使用消息存储资源管理器进行两阶段提交。但是要通过 RabbitMQ 广播，您需要桥接通信，即。RECEIVESSB 消息并将它们转换为 RabbitMQ 通知。