NServiceBus Outbox模式与SQL结合的部署及配置疑问

1. Outbox表的存储位置及相关配置 #

• Outbox表必须与业务数据同库：这是Outbox模式解决分布式事务问题的核心——通过本地事务将业务数据与待发送消息写入同一个数据库，从根源上避免跨库分布式事务。如果将Outbox表放到ServiceBus数据库，业务数据保存与Outbox写入操作依然跨库，会再次触发分布式事务，完全失去使用Outbox模式的意义。
• 订阅数据的存储位置：NServiceBus的订阅关系表默认存储在ServiceBus数据库中，因为订阅是跨服务的全局关联信息，与单个服务的业务库无关，这个设计是合理的。
• NServiceBus分库配置实现：可以配置Outbox表在业务数据库，其他NServiceBus相关表（如订阅表、Saga表等）在ServiceBus数据库。只需要为Outbox单独指定业务库的连接字符串，同时为NServiceBus的持久化组件配置指向ServiceBus数据库的连接字符串即可。
• servicename_Outbox表的存储位置：该表必须存放在对应服务的业务数据库中，确保业务操作与Outbox写入在同一个本地事务内提交。若放到ServiceBus数据库，依然会产生跨库操作，需要分布式事务，违背Outbox模式的设计初衷。

2. ServiceBus轮询Outbox表的识别与配置 #

• 轮询逻辑说明：并非由ServiceBus全局轮询所有服务的Outbox表，而是每个服务独立轮询自身业务库中的Outbox表。NServiceBus会自动关联当前服务对应的servicename_Outbox表，完成待发消息的读取、发送与标记处理。
• 显式配置支持：可以在NServiceBus的配置中明确指定Outbox的连接字符串（即对应服务的业务库连接串），同时支持自定义Outbox表名称、轮询频率、批量处理消息数量等参数。每个服务的Outbox配置相互独立，ServiceBus仅负责接收并分发最终发送过来的消息，不参与Outbox的轮询过程。

内容的提问来源于stack exchange，提问作者Bola