Serverless 里怎么处理需要建立长连接的外部资源?

查看 62|回复 5
作者:FlashEcho   
最近在 Cloudflare Workers 上接外部 Redis / Valkey ,发现传统 Node 服务那套“建一个 Redis client 然后复用连接”的思路不太行
Worker 会冷启动、冻结、恢复或回收,模块级 client 虽然能复用,但不像常驻进程里的连接池那么可靠。实际遇到的现象是:client 看起来 ready ,但 Redis 命令经常 timeout ,后续还会引发一些连带错误。尤其是从 cloudflare 阿姆斯特丹机房到 digital ocean 班加罗尔机房的连接质量差得离谱,已经超时到无法忍受了
我现在的临时处理是:Serverless 侧不直接维护 Redis TCP 连接,改成通过 HTTP 访问 Redis ,把连接池放到更适合常驻运行的地方。现在从 cloudflare 全球机房,到 racknerd 洛杉矶机房的 redis 代理,到 digital ocean 旧金山机房里的真实 redis 。虽然绕路更多了,但是基本不超时了
Worker -> HTTP -> Redis proxy -> Redis
但自建 Redis proxy 也挺麻烦,平台原生的 redis 资源又很贵
想请教大家:Serverless / Edge Runtime 里访问 Redis 、数据库、MQ 这类需要连接的外部资源,大家一般是直接连、HTTP API / proxy ,还是尽量改用平台原生存储?这种情况下有没有什么最佳实践?

serverless, 连接, Redis

tf2   
官方那个 Durable Object 啊
FlashEcho
OP
  
@tf2 #1 DO 更是贵的离谱,本来就是为了节约成本从 KV 迁到外部 redis ,这样成本反而会增加
CupTools   
https://architectingoncloudflare.com/
wudiiiii   
我觉得直接连接比较好,传统服务中用连接池的意义是多个 http 请求打过来可以复用已建立的连接,但是在 serverless 中意义就不大了
cryptovae   
有点本末倒置了,在 Serverless 中,直接就直连,甚至连连接池都不用,拿到链接直接访问,服务退出后释放连接就行,当然,量起来的时候肯定是通过 proxy 维护连接池的
您需要登录后才可以回帖 登录 | 立即注册

返回顶部