负载平衡环境中的专用Sitecore CM发布实例

根据我的理解，主要原因是同步和处理事件队列。CM服务器将其本地事件发送到发布服务器，发布服务器将处理这些事件，发布并触发远程事件。如果两个服务器都能够发布，那么事件队列将变得非常难以同步，因为如果没有专用的发布服务器，两个发布事件可能几乎同时从两个CM服务器激发。

性能也是一个考虑因素，但如果只有一个发布服务器，情况也是如此。内容编辑器在运行时会注意到可用性问题。这就是为什么建议最好使用3服务器CM设置：2个CM实例和1个不进行创作的发布实例。这也允许您(在Sitecore 7.2上(设置并行发布，但这并不总是现实的，而且您仍然对其中一个服务器有依赖性，正如您正确地指出的那样。但考虑到事件队列的问题，即使您有10台服务器，我认为您也需要这种依赖关系。

我最近读了一篇关于将创作服务器配置为发布实例的旧文章，其中包含一些非常好的信息。

我只读过这方面的内容，希望有更实际经验的人会很快回答，但当我思考这一问题时，我得出的唯一结论是，如果"错误"的CM实例失败，那么Publishing.PublishingInstance设置必须更新。也许已经准备好了补丁配置(.disabled(，这样您就可以在需要时部署/重命名它，并将其作为灾难恢复计划中的一个步骤。显然需要一些手动干预，正如您所说，这不是"站点关闭"依赖关系。对于我参与过的大多数项目来说，这是可以接受的，在这种情况下，前端服务器始终是优先考虑的。

为了清楚起见，如果您对CM环境进行负载平衡，则必须仅配置该环境中的一个实例才能发布。我不记得原因的确切细节，但这可能是为了性能、消除死锁、最大限度地减少冗余发布混乱和缓存清除，以及其他原因。该实例正在处理来自CMS用户的HTTP请求，但它是该环境中唯一执行发布的实例。我同意，如果发布实例失败，设置必须更改，尽管我必须查看实现，看看是否有某种方法可以回退或应用逻辑来确定发布实例，而不仅仅是使用设置。

这与专用发布实例不同，后者位于CM环境中，但不处于平衡状态。这适用于发布量非常大的场景，以平衡实例的发布开销。

引用Sitecore"缩放指南"文档，第27页

发布CM实例仍然可以是创作实例，或者也可以用作单独负责的专用实例用于出版。后一个选项可用于分离出于性能原因从创作CM实例发布，部署策略或出于其他考虑。发布操作可以从环境中的任何CM实例启动。它们是排队，然后发布实例将它们作为序列

因此，主要出于性能、部署和其他考虑，这也不是"负载平衡"设置，因为sitecore称之为多实例设置，这意味着作者将分别登录到每个实例，而不让负载平衡服务器决定使用哪个CM实例。