Azure 200刀试用号 Azure微软云Redis缓存测评

你有没有在深夜改完代码，兴冲冲部署上Azure，结果首页加载慢得像在煮一锅老火靓汤？点开Application Insights一看——哦，原来不是数据库拖后腿，是Redis缓存自己在那儿打太极。

别急，这不是你的错。Azure Redis Cache（现在叫Azure Cache for Redis）表面看着光鲜：一键部署、自动备份、TLS加密、地理复制……但真把它当“即插即用”的U盘使，不出三天，你就会收到三条微信——一条来自运维同事：“连接池爆了”，一条来自前端：“首屏TTFB翻了三倍”，还有一条来自财务：“上个月账单里Redis占了47%”。

所以，我们决定不看文档，不抄参数，直接拿一台干净的Ubuntu 22.04、一个.NET 8 Web API、一个Python压测脚本，外加三杯已凉透的美式，实打实跑一遍Azure Redis——从创建那一刻起，掐表计时，记日志，抓包，看监控，甚至故意往里面塞个12MB的JSON大Key试试它会不会翻白眼。

第一步：不是点‘创建’就完事，而是选对‘人设’

Azure Redis有三个档位：Basic（单节点，无SLA）、Standard（主从，99.9% SLA）、Premium（集群+持久化+VNET集成+Redis Modules）。别被‘Basic’俩字骗了——它连连接数限制都写在官网小字里：1000连接上限，且不支持SSL。我们一开始图省事选了Basic，结果本地Postman连得欢，K8s Pod一上线就报Connection refused。查了半小时才发现：AKS默认走TLS，而Basic版压根没开6380端口，只留了个6379明文端口，还被NSG默默拦了……

结论：除非你在做Demo或内部工具，否则请直奔Standard起步。我们最终选了C1规格（2.5GB内存，10K吞吐），理由很朴素：比B2便宜30%，但支持TLS+自动故障转移+地理复制预留位——这仨，任何一个在凌晨三点救过命。

第二步：连接，不是‘加个ConnectionString’就完事

.NET SDK里一行代码：services.AddStackExchangeRedisCache(o => o.Configuration = "xxx.redis.cache.windows.net:6380,password=xxx,ssl=True,abortConnect=False"); 看着很帅，但上线后发现：每小时总有几秒缓存命中率掉到60%。

抓包一看，罪魁祸首是SSL握手超时重试。Azure Redis的TLS证书由微软托管，但某些老旧客户端（比如StackExchange.Redis v2.0以下）在证书链验证时会卡顿。我们升级到v2.7.11 + 启用sslProtocols=Tls12后，平均握手时间从320ms降到22ms。

更隐蔽的坑是连接池泄漏。某次发版后，Redis连接数曲线像坐过山车——白天平稳，凌晨飙升。排查发现是某个定时任务里new了一个IDatabase却没复用ConnectionMultiplexer。Azure控制台里“当前连接数”指标瞬间拉到992（离1000红线仅一步之遥），紧接着所有请求开始排队。解决方案？一句话：ConnectionMultiplexer必须全局单例，且注册为Singleton生命周期。别信“我每次用完就Close()”，它关不干净。

第三步：压测？别光看QPS，要看‘抖动’和‘尾部延迟’

Azure 200刀试用号 我们用redis-benchmark -h xxx.redis.cache.windows.net -p 6380 -a 'xxx' -t set,get -n 100000 -c 50跑了个基础测试，QPS 38,200，看起来很美。但这是理想环境下的‘平均值’。

换成真实业务场景：模拟100并发用户，每秒随机读写3个Key（含1个Hash结构），持续5分钟。用latency-monitor打开后发现——99分位延迟高达412ms，而平均才18ms。进一步查Azure Metrics发现：每到整点，CPU使用率会跳一次尖峰（+35%），对应后台在做RDB快照。虽然Premium版可关快照，但Standard版不行。解决方案？把关键业务Key的过期时间错开整点，或接受那几秒“温柔卡顿”。

第四步：高可用？别只信‘主从自动切换’

Azure说“故障转移<5秒”。我们主动触发了一次Failover（在Portal点‘重启主节点’），监控显示：应用层有2.7秒缓存不可用窗口，期间所有GetAsync()返回null，SetAsync()抛出TimeoutException。为什么不是0？因为StackExchange.Redis的默认SyncTimeout是1000ms，而故障期间它会尝试重连3次，每次间隔300ms……加起来刚好2.7秒。

修复方案很简单：AbortOnConnectFail=false + ConnectRetry=3 + ConnectTimeout=3000，再配合业务层兜底（如缓存穿透时查DB并回填）。记住：云服务的SLA是“基础设施不挂”，不是“你的代码不报错”。

第五步：钱去哪儿了？那些藏在账单里的‘幽灵费用’

一个月账单$217，其中$112是Redis。拆开一看：$89是实例费，$18是网络出口流量（主要来自Log Analytics推送监控数据），还有$5是“高级诊断日志”——我们根本没开！查后发现：Azure Monitor默认启用‘Metrics’收集，而‘Diagnostic Settings’里勾选了‘CacheRequests’，每万次请求收$0.0001。10亿次？就是$10k。赶紧关掉，换Prometheus+Azure Monitor Agent轻量采集。

最后送你三条‘保命口诀’

• 大Key是头号公敌：用redis-cli --bigkeys每月扫一次；Hash结构别塞超过1000个field；List长度超5000就分片。
• 别信‘自动缩容’：Azure Redis不支持自动降配。内存长期<30%？手动降级，省下的钱够买两箱红牛。
• 监控必盯三个指标：Connected Clients（突增=泄漏）、Cache Hits（跌穿90%=热点失效或穿透）、Evicted Keys（非零=内存真不够了，不是错觉）。

写完这篇，我顺手把生产环境Redis的maxmemory-policy从allkeys-lru改成volatile-lru，又删掉了三个常年不用的KeySpace。然后泡了杯新咖啡——这次是热的。

毕竟，云不是魔法，是管道。而管道工，得亲手拧紧每一颗螺丝。