1

请在来自横向扩展发布者（使用 DB 订阅存储）的多个发布和具有横向扩展订阅者（使用分发者）的多个订阅的上下文中考虑以下问题，其中使用自动 MSI 的初始部署、升级等定期进行安装和卸载.

  1. 使用 DB 订阅存储，如果 DB 出现故障会怎样？如果需要访问订阅数据库才能发布消息，它将如何传递？它会迷路吗？对 Bus.Publish 的调用会引发异常吗？
  2. 假设您不需要停机部署：如果您想将特定发布的订阅数据库移动到不同的服务器怎么办？你如何管理这样的过渡？
  3. 同样的问题也适用于订阅方的分销商：如果您想移动分销商端点怎么办？我能想到的一种情况是，如果您有多个订阅使用单个分发服务器，那么如果您想将其中一些订阅移动到另一个分发服务器以减少负载可能会很困难。
  4. 对于这样的设置（最初和持续升级），安装/卸载场景会是什么样子？似乎您需要一些特殊的安装/卸载脚本来部署“逻辑发布”和订阅数据库，以及“逻辑订阅”和分发者。发布者实例不需要任何特殊的安装/卸载逻辑（因为它们只是使用配置的订阅数据库开始发布消息，然后在卸载时停止）。除了分发者端点的正确配置之外，订阅者工作节点在安装时不需要任何特殊的东西，但需要卸载逻辑以确保将它们从工作节点的分发者列表中删除。
4

2 回答 2

0

对于您的第一个问题，关于订阅数据库的高可用性，您可以使用集群进行故障转移。如果数据库关闭，那么 Bus.Publish 将抛出异常，是的。建议将订阅数据库与应用程序数据库分开，以避免在升级应用程序时将其关闭。这不必是单独的数据库服务器，同一数据库服务器上的单独数据库就可以了。

关于移动服务器，这通常在 DNS 级别进行管理，在一段时间内您将同时运行这两个服务器，直到通信结束。

关于分销商的第三个问题 - 不要在不同的发布商或订阅者之间共享分销商。

根据经验，建议在进行此类维护活动时不要添加/删除订阅者。这通常会大大简化事情。

于 2010-08-01T07:25:17.357 回答
0
  1. 最终发布者将失败，消息将在内部队列中建立。您必须根据消息大小以及您希望等待数据库出现的时间来计划处理此问题所需的磁盘大小。从那里它取决于您可以处理多少停机时间。您可以使用数据库镜像或集群来减少数据库的停机时间。
  2. 镜像和集群技术也可以帮助解决这个问题。取决于您是否要进行手动或自动故障转移以及您在哪里进行（远程站点？）。
  3. 集群 MSMQ 可以在这里为您提供帮助。如果您想删除分发服务器并将其移动到集群中，您就可以了。另一种可能性是通过 HTTP 公开您的分销商，并在软件或硬件负载平衡解决方案之后对它们进行负载平衡。在负载均衡器后面，您可以更自由地移动东西。
  4. 听起来你已经很好地掌握了这个:)
于 2010-07-29T17:59:01.037 回答