Azure Service Bus是否内置作业元数据缓存能力？相关实现方案问询

Azure Service Bus状态存储能力说明 #

Azure Service Bus是纯消息中转组件，不内置任何轻量数据库或KV缓存能力。它的设计定位是实现异步消息的收发、排队、投递，没有提供针对作业ID、状态这类需要随机查询、反复更新数据的存储和检索能力，你在官方文档中未找到相关功能是因为该能力确实不存在，也不建议用队列转存的方式模拟元数据存储，和你提到的访问逻辑限制冲突。

可行的替代方案 #

• 首选方案：使用Azure托管Redis服务，不需要你自行在VM上部署维护，开通即可直接使用，和你的App Service、Service Bus都属于Azure内网资源，访问延迟低。Flask端仅需安装redis依赖包即可快速实现作业状态的写入、查询、更新操作，完全匹配同类场景的技术选型。
• 低成本方案：使用Azure Table Storage，这是Serverless模式的轻量NoSQL存储，按实际使用量付费，成本极低，支持以作业ID为分区键实现毫秒级的查询和状态更新，Flask端通过azure-data-tables包即可完成所有元数据操作，适合对缓存能力要求不高的场景。
• 极简方案：如果作业状态仅需在处理完成后写入一次、无需中途更新，也可以直接将元数据以JSON格式存入Azure Blob Storage，以作业ID作为Blob名称实现快速检索，操作门槛和成本最低。

App Service并行运行Flask与Redis的可行性说明 #

Azure App Service的单部署实例默认仅支持运行一个主业务进程/容器，无法稳定同时运行Flask服务和Redis服务。即使你通过自定义启动脚本强行同时启动两个进程，也会触发App Service的健康检查异常，或是出现资源抢占导致服务不稳定，非常不建议采用该方案。

内容的提问来源于stack exchange，提问作者T-Man-Stan