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

[pppwww]

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

[Conantv2]

体积不是问题，问题是数据组织形式。大型业务开机就加载几十个 GB 内容进内存，直接内存读写，定期落盘。只要内存够，没什么不能放。

[night98]

只要不是每次都从 redis 读然后返回就行了，可以启动时读到本地内存然后直接本地内存返回，发生变更就通过消息方式更新本地内存的内容就行

[seers]

不知道你什么业务场景，要放这么大

[gwy15]

40M 的字符串光是读取就可能造成瓶颈，按照 1G 的网卡的话，光走网络就要 0.34s ，10G 网卡也 33ms ，这就没有多高的 QPS ，如果你 redis 上有其他的读写的话肯定是要造成波动的，非常不合适。

[kuituosi]

memcache

[Chad0000]

@night98 #2
@gwy15 #4

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

这样字符串变化不频繁的话没什么影响。

[crysislinux]

不适合肯定是不适合的，不过可以压缩一下，如果是一个大的 JSON 数组，压缩率很高的，估计压完不到 2MB

[lsk569937453]

网络传输是个问题

[zhuzhibin]

大 key 吃带宽 如果你的上下行带宽拉满当我没说

[Nazz]

这么大不放文件里

[GGGG430]

1) 拆分, 一个拆分成多个小 key, 再维护一个大 key 到小 key 的映射
2) 使用 memcache(多线程)
最好也加上本地缓存

[YongXMan]

放进去不是问题，问题是这个 key 的使用方式是怎样的，每次全量读写？读写 qps 多少？如果操作类型是 substr 这种局部查询没啥问题，否则这一个 key 20 qps 就能把万兆带宽打满了，😄

[qianzanqi]

适合，太适合了。只是不保证 redis 集群的 sla 而已，redis 挂了导致你们服务出问题是你们全责

[victorc]

不合适，这么大的数据，qps 一高，redis 必挂

[xuanbg]

主要看你怎么用。如果多台机器共享，那么除了 redis ，你也基本没有什么更简单的解决方案。如果单机，redis 适合整存零取或者零存零取的读写方式。整存整取的话，没必要脱裤子放屁。和数据的大小没什么关系，无论数据多大，总得读写，无非就是策略的问题，尽量避免过高的 IO 时间。

[pppwww]

@Chad0000 嗯，目前看起来这种方法要更优一些，还是需要尽量减少访问 redis 的次数

[pppwww]

@night98 确实，现在就是考虑使用这种方案，用楼下大佬说的版本号来实现下

[dilu]

最大的问题反而在网络传输上吧，如果可以最好还是放在本地缓存，后台起个协程定时刷新就行了。