从SQL Server生成事件

Question

我正在寻找一个最佳实践或示例,说明如何为给定SQL Server 2008 R2 db上的所有更新事件生成事件.为了更具描述性,我正在开发一个POC,我基本上将更新事件发布到队列(在我的情况下是RabbitMq),然后可以被各种消费者使用.这将是通过事件源实现CQRS仅查询数据模型的第一部分.通过放置在que上,任何人都可以订阅这些事件以复制到任意数量的仅查询数据模型中.这部分内容清晰明确.我遇到的问题是确定从SQL服务器生成事件的最佳方法.我已经获得了一些想法,例如监视事务日志和SSIS.但是,我不完全确定这些选项是否可以建议甚至是可行的.

有没有人对这种事情有任何经验,或者对如何进行这样的冒险有任何想法？任何帮助或指导将不胜感激.

Answer 1

你不能监控日志,因为即使当你将能够理解它,你必须被回收日志的问题之前,你有机会读它.除非日志以某种方式标记为不被截断,否则它将被重用.例如,启用事务复制时,将固定日志,直到复制代理读取该日志,然后才会截断日志.

SSIS是一个非常广泛的概念,并且说'使用SSIS来检测变化'类似于说'我将使用编程语言来解决我的问题'.细节是你如何使用SSIS？无论是否有SSIS,都无法可靠地检测任意模式上的数据更改.即使是专门设计用于检测变化的数据模型也存在问题,特别是在检测删除时.

然而,有可行的替代方案.您可以部署Change Data Capture并委派给引擎本身来跟踪更改.消费这些检测到的变化并将它们发布给消费者(如果你喜欢的话,通过RabbitMQ)是 SSIS擅长的东西.但是你必须明白SSIS对于连续的实时任务并不好.它被设计为在批次上定期运行,因此当SSIS作业运行时,您的更改通知消费者将收到峰值通知,并且会有很长的延迟(分钟).

对于实时方法,Service Broker是一个更好的解决方案.一种可能性是SEND来自触发器的Service Broker消息,但我不推荐它.更好的设计是让应用程序本身SEND在进行数据修改时通过显式消息发布更改.使用SQL Server 2012可以将Service Broker消息多播到其他SQL Server使用者(包括SQL Server Express).SSB消息传递是完全事务性的(如果事务回滚,则不会发送消息),并且不需要与消息存储库资源管理器进行两阶段提交.但要通过RabbitMQ进行广播,您需要桥接通信,即.RECEIVESSB消息并将它们转换为RabbitMQ通知.