跨App Services共享Azure Redis Cache实例的可行性咨询

结论先行：完全支持共享，这也是小规模多应用场景下性价比最高的部署方案，没有平台层面的限制。
实际部署的时候注意几个核心点就行：

• 连通性配置：确保所有要接入的App Service和Redis实例在同一个Azure区域，在Redis的防火墙规则里放通对应App Service的出站IP即可；如果用私有端点部署，只要保证所有App Service能通过私有网络访问到Redis的端点就行，没有接入应用数量的硬性限制。
• 数据隔离：不用怕不同应用的缓存数据互相冲突，最简单的方案是给每个应用的缓存键设置统一前缀，比如订单系统的键全加order_svc:前缀，内容系统的键全加content_svc:前缀，逻辑上就能完全区分。如果需要权限层面的隔离，直接用Redis自带的ACL功能给每个App Service分配独立的访问账号，限制每个账号只能操作对应前缀的键，就能避免误操作其他应用的缓存。
• 规格匹配：选Redis规格的时候不用按应用数量算，直接统计所有接入应用的总缓存容量、峰值QPS、预期连接数总和，匹配对应档位的实例就行。通常几个仅跑数个实例的小型App Service，总需求基本不会超过基础档/标准档最小规格的负载上限，成本比给每个应用单独买Redis实例低一半以上。
• 常见避坑：不要跨区域部署共享Redis，跨区域的公网/跨VNet延迟会把缓存的性能优势完全抵消；平时用的时候注意监控Redis的内存占用、CPU负载、连接数指标就行，如果后续某个应用的缓存需求暴涨，随时可以把这个应用的连接字符串改成独立的Redis实例完成拆分，业务侧几乎没有改造成本。

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