Azure槽交换：预热期间两槽是否拥有相同粘性设置？

核心问题解答 #

是的，槽交换过程中确实存在极短暂的时间窗口，源槽和目标槽会同时使用目标槽的特定设置。

根据Azure槽交换的实际流程：

交换启动后，第一步会将目标槽的槽特定配置应用到源槽并重启源槽；此时源槽已加载目标槽的配置，但目标槽仍在运行原有的配置，直到第二步完成路由切换，再将源槽的原配置应用到目标槽并重启目标槽。

对应你的Service Bus场景：交换启动后，staging槽（源槽）会先加载生产槽的Service Bus连接字符串并重启，这一瞬间staging槽会开始消费生产环境的消息，而此时生产槽（目标槽）还在正常消费生产消息——直到路由切换完成，生产槽会加载staging的原配置并重启，停止消费生产消息。所以确实会出现两槽同时消费生产消息的情况。

规避方案 #

以下是几种实用的解决办法：

• 基于槽标识控制消费者逻辑
  在C#代码中读取环境变量WEBSITE_SLOT_NAME，只有当当前槽为生产槽（比如名称为Production）时，才启动Service Bus消费者。即使staging槽在交换过程中加载了生产连接，也会因为槽标识不是生产而不启动消费逻辑。示例代码：

  var slotName = Environment.GetEnvironmentVariable("WEBSITE_SLOT_NAME");
  if (slotName?.Equals("Production", StringComparison.OrdinalIgnoreCase) == true)
  {
      // 启动Service Bus消费者
      StartServiceBusConsumer();
  }
  

• 利用槽交换钩子控制消费者状态
  使用Azure App Service的预交换（PreSwap）和后交换（PostSwap）钩子，在交换前后执行脚本控制消费者：

  • 预交换阶段：调用应用的内部API或设置临时配置（如DISABLE_CONSUMER=true），让staging槽停止消费者；
  • 后交换阶段：移除临时配置，启动新生产槽的消费者，并给原生产槽（现在的staging槽）添加禁用配置，确保只有当前生产槽在消费。

• 分离消费逻辑至独立服务
  将Service Bus消费逻辑从Web应用中拆分出来，部署为独立的Azure Function或Worker Service。这类服务不需要槽交换，可单独部署和管理，彻底避免Web应用槽交换带来的配置冲突问题。

验证建议 #

如果要验证交换过程中的配置变化，可以在代码中添加日志，记录当前槽名、Service Bus连接字符串的获取时间点，触发交换后查看日志时序，就能清晰看到配置切换的窗口。

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