Azure Service Bus会话状态可靠性及灾备相关技术问询

背景 #

计划采用Azure Functions配合启用会话的Azure Service Bus作为编排器，运行以Service Bus主题/Azure Function为步骤的Sagas工作流（事务）。已知启用会话的Service Bus触发器函数中，Service Bus会负责选择并锁定Azure Function消费者（可来自应用服务计划的100个实例），同一会话的消息不会被两个消费者接收。

问题1：会话锁机制失效导致会话状态损坏的场景 #

• 消费者异常退出未释放锁：如果Azure Function实例在处理会话消息时突然崩溃、被强制回收（比如应用服务计划实例缩放、资源限制导致进程终止），且未能在锁过期前主动完成处理并释放锁，Service Bus会在锁超时后重新投递消息。若原实例的处理进程未完全终止，可能出现两个实例同时处理同一会话消息的情况，引发状态冲突。
• 锁超时设置不合理：如果会话消息的处理时间超过Service Bus的锁超时时间，且未及时续期，Service Bus会判定消费者失效，将消息重新分发给其他实例。此时原实例可能仍在处理该消息，新实例又开始处理同一条消息，造成会话状态不一致。
• 手动操作失误：比如通过工具手动解锁或重新投递会话消息，绕过正常锁机制，可能导致同一会话的消息被多个消费者同时接收。

问题2：Premium层+区域冗余+主题分区下，服务器宕机的会话状态风险及应对措施 #

在启用区域冗余和主题分区的Premium层级下，Service Bus服务器/VM宕机通常不会导致会话状态丢失：

• 区域冗余会将会话元数据（包括会话锁、会话状态）同步到多区域副本，单个区域服务器宕机后，副本会接管服务，会话状态得以保留。
• 主题分区会将消息和会话分散到多个分区，单个分区所在服务器宕机时，其他分区不受影响，会话状态会在分区恢复后正常加载。

但存在极端风险场景：

• 多区域同时故障：概率极低，但如果所有冗余区域的服务器同时故障，可能导致会话状态丢失。
• 分区数据不可恢复损坏：若分区底层存储出现无法修复的损坏，且无及时备份，可能丢失该分区内的会话状态。

额外保障措施：

• 会话状态外部持久化：将会话核心状态数据（如当前步骤、已完成操作）存储到外部异地冗余存储（如Azure Cosmos DB、Azure SQL Database），不依赖Service Bus自身的会话状态存储。即使Service Bus异常，也可从外部存储恢复状态。
• 启用Service Bus异地灾难恢复：配置Geo-disaster recovery，将命名空间复制到备用区域，主区域故障时可手动或自动切换到异地副本，确保会话和消息的连续性。
• 监控会话锁状态：通过Azure Monitor监控会话锁的过期、续期情况，及时发现异常并触发告警，避免锁问题引发的状态冲突。

问题3：区域中断灾备场景下的会话状态与消息安全保障 #

• 配置异地灾难恢复（Geo-DR）：为Service Bus命名空间启用Geo-DR，将主区域命名空间数据复制到备用区域。主区域中断时，切换到备用区域继续处理会话和消息。切换后会话状态会从备用副本恢复。
• 会话状态外部持久化：将会话核心业务状态存储到支持异地复制的外部存储，Service Bus仅作为消息传递和会话编排载体，不依赖其存储状态。主区域Service Bus不可用时，备用区域的Functions可从外部存储读取会话状态，继续执行工作流。
• 消息异地复制与TTL设置：启用Geo-DR后，消息会同步到备用区域命名空间，切换后消费者可继续接收未处理消息。同时设置合理的消息TTL，确保消息在区域恢复前不会过期。
• 跨区域部署Functions：将Azure Functions部署到主备两个区域，主区域中断时流量切换到备用区域实例，结合外部存储的会话状态，无缝继续处理工作流。

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