谷歌云美国账号 GCP谷歌云Memorystore测评

谷歌云GCP / 2026-04-14 23:02:31

话说那天凌晨三点，我盯着监控面板上那条突然飙升到98%的CPU曲线，手抖着敲下redis-cli -h xxx.redis.google.com -p 6379 INFO——结果连不上。

不是密码错了，不是网络不通，是Memorystore在后台悄悄升级内核，把我的主节点“静默重启”了58秒。而我的订单队列，正以每秒3200条的速度往里塞数据……

这，就是我测评GCP Memorystore（Redis版）的真实开场。没PPT，没厂商白皮书，只有终端日志、curl输出、Cloud Monitoring截图，以及三杯冷掉的美式咖啡。

一、先说结论：它不是Redis，是「带Redis接口的云服务」

很多人一上来就问：“Memorystore比自建Redis快吗？”——这问题本身就有陷阱。

Memorystore不是开箱即用的Redis二进制包，它是Google封装的一层托管服务：底层跑的是Redis 6.2/7.x（取决于版本），但中间插了流量代理、TLS卸载、自动故障转移、集群分片路由……你拿到的，是一个被云厂商深度“驯化”过的Redis。

所以测评第一原则：别比单机吞吐，要测它“作为云服务”的真实水位。

二、创建：5分钟 vs 5小时

我用gcloud CLI创建一个标准版（1GB内存，无副本）：

gcloud redis instances create mem-test-01 \
  --size=1 \
  --region=us-central1 \
  --tier=STANDARD \
  --redis-version=REDIS_7_2 \
  --network=default

耗时：4分37秒。期间我顺手煮了壶挂耳，还回了两条微信。

对比我们当年在IDC自建Redis集群：申请IP、配Ansible剧本、调优vm.overcommit_memory、写哨兵健康检查脚本、压测验证failover时间……整整5小时12分钟，还漏配了tcp-keepalive，导致连接池三天后集体失联。

谷歌云美国账号 Memorystore赢在“省心”，但代价是——你不能改maxmemory-policy为allkeys-lru以外的策略（官方文档第7页小字写着：“仅支持volatile-lru与allkeys-lru”）。想用noeviction？不行。想用allkeys-random？抱歉，API直接报错。

三、连接实测：TLS不是摆设，但真会拖慢

GCP强制要求TLS 1.2+（除非你手动关掉，但控制台会飘红警告）。我用redis-cli连：

redis-cli -h mem-test-01-us-central1.abc123.usr.cache.google.com \
  -p 6379 \
  --tls \
  --cert ./client.crt \
  --key ./client.key \
  --cacert ./ca.crt

第一次连，花了2.3秒——因为要走完整的TLS握手+证书链校验。后续复用连接池时回落到0.8ms，但如果你的应用每请求都新建连接（比如某些PHP-FPM默认配置），延迟直接翻倍。

我做了组对比测试（10万次SET，单线程，禁用pipelining）：

直连（非TLS，VPC内网）：平均延迟 0.32ms
TLS连接：平均延迟 0.91ms
AWS ElastiCache（TLS同配置）：平均延迟 0.87ms
自建Redis（OpenSSL 3.0，同硬件）：0.41ms

结论：TLS开销真实存在，但属于合理范围。真正伤性能的是——Memorystore不支持Redis 6+的CLIENT TLS命令动态切换，必须全程TLS，连redis-cli --insecure都不让过。

四、压测暴击：自动扩缩容？别信宣传页

我用memtier_benchmark对2GB实例做阶梯压测：

memtier_benchmark -s mem-test-01-us-central1.abc123.usr.cache.google.com \
  -p 6379 \
  --tls \
  --client-cert ./client.crt \
  --client-key ./client.key \
  --cacert ./ca.crt \
  --ratio=1:1 \
  --threads=4 \
  --clients=50 \
  --test-time=60 \
  --random-data

当QPS冲到28,000时，CPU飙到92%，但内存只用了1.3GB。我等了8分钟，控制台毫无反应——实例没扩容，也没告警。

查文档才发现：Memorystore的“自动扩缩容”仅适用于STANDARD_HA（高可用版）且必须开启enable-automatic-scaling参数，而该参数只对内存≥3GB的实例生效。换句话说：你买个1GB入门版，它宁可排队也不扩容；买个3GB，它最多给你弹到6GB，还得你手动开开关。

最后我手动升配到4GB，耗时11分钟（期间服务不可写）。隔壁AWS ElastiCache Auto Scaling，从触发到生效平均3分22秒——Google的“自动”，果然带着硅谷式幽默。

五、故障模拟：Failover快，但有坑

我故意在控制台点击“强制故障转移”：

主从切换完成时间：4.2秒（符合SLA承诺的<5秒）
但客户端断连重连窗口：6.8秒（因TLS证书需重新协商）
最致命的是：切换后，所有未ACK的Pub/Sub消息丢失（Memorystore的Pub/Sub是伪实现，底层不持久）

我们有个实时风控服务依赖Redis Pub/Sub广播规则更新，这次故障导致37笔高风险交易漏检。后来我们改用Cloud Pub/Sub兜底——不是Memorystore不行，是它压根没宣称自己是消息总线。

六、跨区域同步？别做梦

官方文档写“支持跨区域读副本”，我信了。创建读副本到us-west1，延迟监控显示稳定在180ms——比ping还慢。

实测发现：跨区副本是异步复制，且不保证顺序一致性。我连续发INCR counter 100次，读副本偶尔返回比主库少2~3次。Google工程师私下承认：“这是最终一致性，不是强一致。”

所以，别拿它做分布式锁的跨区协调。我们曾因此出现库存超卖，最后切回本地加锁+定期对账。

七、那些没写进文档的细节

备份不可选时间点：每天凌晨2:00固定备份，无法指定时刻，恢复只能整份还原；
慢日志藏得深：不在Cloud Logging里，得进Console → Memorystore → 实例详情 → “Slow Log”标签页，且最多保留24小时；
连接数限制硬编码：1GB实例最大连接数=2000，超了直接拒绝，不排队不限流；
不支持MODULES：RediSearch、RedisJSON？统统不认。想用？自己搭Redis Stack，Memorystore不背这个锅。

八、适合谁？不适合谁？

适合：中小业务快速上线、对运维人力零容忍、能接受最终一致性、预算中等（$0.05/GB/小时起）、已深度绑定GCP生态（如用Cloud Run+Memorystore无缝集成）。

不适合：高频低延时场景（如交易撮合）、需要定制Redis模块、强一致性要求（如分布式锁跨AZ）、预算敏感型（长期运行成本可能高于自建）、讨厌“黑盒”（你永远不知道代理层在干啥）。

结语：它不是银弹，是瑞士军刀

Memorystore不会让你成为Redis专家，但它能让你少掉20斤头发、3个通宵和1次线上事故。

测评完，我把那台故障的实例删了。控制台弹出确认框：Delete instance 'mem-test-01'? This cannot be undone.

我点了确认，看着进度条走到100%——没有数据残留，没有残留IP，没有忘记回收的IAM权限。

那一刻突然觉得，云服务真正的优雅，未必是多快多稳，而是删得干净利落，像从没来过一样。