使用 CQRSish 模式横向扩展、多读取数据库
我正在使用 CQRS 样式模式（无事件源），我只是将读取和写入分为 2 个单独的应用程序边界。
目前，该应用程序针对一个 SQL 2008 数据库运行。我想添加多个读取数据库来分配工作负载，因为数据量开始变高。
我需要一个 SQL 2008 中的解决方案，可以在其中更新单个数据库，并将更改实时复制/传播到其他节点。这仅需要是单向传播，因为应用程序仅写入单个“主”数据库。
我读过有关点对点事务复制的内容。谁用过这个，更新子节点有多少延迟？
还有其他解决方案吗？
I am using a CQRS style pattern (No Event Sourcing) I simply separate my reads and writes into 2 separate application boundaries.
Right now, the application works against one SQL 2008 Database. I would like to add multiple read databases to distribute the workload as volume is starting to get high.
I need a solution in SQL 2008 where I can update a single database, and have the changes replicated/propigated in real-time to other nodes. This only needs to be a one-way propagation as the application will only be writing to a single "master" database.
I have read about peer-to-peer transactional replication. Anyone who has used that, how much latency is there in updating the child nodes?
Any other solutions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您不在域/命令端使用事件源，那也没有问题。但这不一定会阻止您将读取端的所有事件存储在某种“事件”表中。在此过程中，它允许您销毁视图模型表并根据读取模型数据库中“事件”表中存储的所有事件进行重建。
这样做的原因是为了扩展你的阅读面。当您现有的读取数据库面临压力并且无法再承受负载时，无需尝试从主“读取数据库”进行复制 - 只需在其他硬件上创建另一个数据库实例，并从“事件”表中填充自身即可。然后让这个额外的读取数据库订阅您的域生成的事件。 （一旦您了解发生了什么，您实际上会想要先订阅，然后填充表，这样您就不会错过已发布的事件）
这允许您拥有两个兄弟的读取数据库，但它们不相互通信彼此。他们只是侦听来自域的事件，更新读取的模型表，并将接收到的事件添加到某种本地“事件”表中。
If you're not using event sourcing on the domain/command side, that's fine. But that shouldn't necessarily prevent you from storing all events on the read side in some kind of "events" table. In doing this, it allows you to destroy your view model tables and rebuild from all events stored in the "events" table within your read model database.
The reason for this is to scale your read side. As your existing read DB comes under pressure and can no longer sustain the load, rather than trying to replicate from a master "read database"--simple create another database instance on some other hardware that populates itself from the "events" table. Then have this additional read database subscribe to the events generated by your domain. (Once you understand what's happening, you'll actually want to subscribe first and then populate the table so that you don't miss events that are published)
This allows you to have two read databases that are siblings but which don't talk to each other. They simply listen to events from the domain, update the read model tables, and add the received events to some kind of local "events" table.