1

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

2

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

3

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

4

1

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

5

memcache

6

1

7

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

9

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

10

这么大不放文件里

11

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

12

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

13

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

14

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

15

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

16

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

17

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

18

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