想问下大佬 40M 的字符串适合放到 redis 缓存吗?

2023-11-11 23:16:09 +08:00
 pppwww

想问下大佬们 40M 的字符串适合放到 redis 缓存吗?如果不适合的话怎么解决呢

3061 次点击
所在节点    Redis
18 条回复
Conantv2
2023-11-11 23:19:06 +08:00
体积不是问题,问题是数据组织形式。大型业务开机就加载几十个 GB 内容进内存,直接内存读写,定期落盘。只要内存够,没什么不能放。
night98
2023-11-11 23:24:11 +08:00
只要不是每次都从 redis 读然后返回就行了,可以启动时读到本地内存然后直接本地内存返回,发生变更就通过消息方式更新本地内存的内容就行
seers
2023-11-11 23:25:13 +08:00
不知道你什么业务场景,要放这么大
gwy15
2023-11-11 23:25:49 +08:00
40M 的字符串光是读取就可能造成瓶颈,按照 1G 的网卡的话,光走网络就要 0.34s ,10G 网卡也 33ms ,这就没有多高的 QPS ,如果你 redis 上有其他的读写的话肯定是要造成波动的,非常不合适。
kuituosi
2023-11-11 23:38:19 +08:00
memcache
Chad0000
2023-11-12 05:01:44 +08:00
@night98 #2
@gwy15 #4

大可以本地缓存,字符串本身加上版本号一起存储,同时在 Redis 另外加一个 key 保存这个版本号。这样使用端只需要先检查版本号,如果与本地不一致才去拿真正的字符串并更新本地缓存。

这样字符串变化不频繁的话没什么影响。
crysislinux
2023-11-12 08:37:34 +08:00
不适合肯定是不适合的,不过可以压缩一下,如果是一个大的 JSON 数组,压缩率很高的,估计压完不到 2MB
lsk569937453
2023-11-12 09:02:16 +08:00
网络传输是个问题
zhuzhibin
2023-11-12 09:36:06 +08:00
大 key 吃带宽 如果你的上下行带宽拉满当我没说
Nazz
2023-11-12 09:55:22 +08:00
这么大不放文件里
GGGG430
2023-11-12 11:27:54 +08:00
1) 拆分, 一个拆分成多个小 key, 再维护一个大 key 到小 key 的映射
2) 使用 memcache(多线程)
最好也加上本地缓存
YongXMan
2023-11-12 12:19:24 +08:00
放进去不是问题,问题是这个 key 的使用方式是怎样的,每次全量读写?读写 qps 多少?如果操作类型是 substr 这种局部查询没啥问题,否则这一个 key 20 qps 就能把万兆带宽打满了,😄
qianzanqi
2023-11-12 15:41:12 +08:00
适合,太适合了。只是不保证 redis 集群的 sla 而已,redis 挂了导致你们服务出问题是你们全责
victorc
2023-11-12 17:53:01 +08:00
不合适,这么大的数据,qps 一高,redis 必挂
xuanbg
2023-11-13 08:19:54 +08:00
主要看你怎么用。如果多台机器共享,那么除了 redis ,你也基本没有什么更简单的解决方案。如果单机,redis 适合整存零取或者零存零取的读写方式。整存整取的话,没必要脱裤子放屁。和数据的大小没什么关系,无论数据多大,总得读写,无非就是策略的问题,尽量避免过高的 IO 时间。
pppwww
2023-11-13 10:35:47 +08:00
@Chad0000 嗯,目前看起来这种方法要更优一些,还是需要尽量减少访问 redis 的次数
pppwww
2023-11-13 10:37:33 +08:00
@night98 确实,现在就是考虑使用这种方案,用楼下大佬说的版本号来实现下
dilu
2023-11-13 10:49:32 +08:00
最大的问题反而在网络传输上吧,如果可以最好还是放在本地缓存,后台起个协程定时刷新就行了。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/991060

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX