我正在尝试在我的组织中重新创建linkedin 的数据总线架构，以用于高度有争议的数据库。我最初的想法是使用 SQL Server 的变更数据捕获 (CDC) 功能来捕获所有事件并将它们发布到外部数据存储区，就像 LI 使用其“引导程序”所做的那样。如果我编写一个服务来不断汇集 cdc 表，我可以将它们写入我的引导数据库，然后使用一些 pub/sub 系统发布事件。
我的问题是，是否有人尝试过这样的事情，如果我前面提到的方法似乎是一种好方法，或者是否有更好的方法来捕获这些事件并发布它们？
谢谢。
编辑：[添加详细信息]
我还没有完全决定辅助数据存储。至少在短期内，它很可能是另一台服务器上的另一个 SQL Server 2008 实例。此辅助存储的主要目的之一是减轻主服务器的负载。我们的主数据库已经变得非常大（> 2.5TB），增加任何额外的负载都是不受欢迎的。如果我可以实现这个架构，那么额外的收获就是从本质上管理复制，从主服务器中承担大部分复制责任。
理想情况下，我什至不想使用 CDC。我觉得这是一项很棒的技术，但它确实将这些更改存储在本地，并且根据我的阅读，它会导致服务器性能受到影响。但是，就目前而言，这似乎是我最好的选择。
编辑2：[进一步的过程细节]
我试图实现的确实与复制非常相似。在这个辅助服务器上，我要做的是从基本数据库的副本和一组用于跟踪更改的表开始。然后，我将有一个服务来监视 CDC 表并将这些事件移动到新数据库，从源中清除它们，并将更改应用到第二个服务器的基本副本。
下一个组件将是一个发布/订阅服务，它将获取所有发布的更改事件，并且任何消费者都可以选择订阅以获取这些更改事件。完整的数据库副本将用于在新消费者上线时“引导”他们，这样他们就可以在开始获取更改事件之前获取完整的、最新的数据库。如果消费者离线并错过事件，跟踪表也将用于获取增量。
客户将能够应用规则来翻译他们认为合适的数据。第一个应用程序将纯粹是创建原始数据库的只读副本。未来的计划包括对数据进行反规范化并转换为其他格式，例如 MongoDb 集合。
如果可以在远程服务器上维护 CDC 表，则可以最简单地实现第一部分。但是，我没有看到任何方法可以做到这一点。
我知道这听起来令人费解，但它会解决一个真正的问题，从linkedin 的解决方案来看，这个问题在当今并不罕见。
希望这会有所帮助。