这是一个创建于 364 天前的主题，其中的信息可能已经有所发展或是发生改变。
想问下大佬们 40M 的字符串适合放到 redis 缓存吗？如果不适合的话怎么解决呢
 |
1
Conantv2 364 天前
体积不是问题，问题是数据组织形式。大型业务开机就加载几十个 GB 内容进内存，直接内存读写，定期落盘。只要内存够，没什么不能放。
|
 |
2
night98 364 天前
只要不是每次都从 redis 读然后返回就行了，可以启动时读到本地内存然后直接本地内存返回，发生变更就通过消息方式更新本地内存的内容就行
|
 |
3
seers 364 天前 via Android
不知道你什么业务场景，要放这么大
|
 |
4
gwy15 364 天前  1
40M 的字符串光是读取就可能造成瓶颈，按照 1G 的网卡的话，光走网络就要 0.34s ，10G 网卡也 33ms ，这就没有多高的 QPS ，如果你 redis 上有其他的读写的话肯定是要造成波动的，非常不合适。
|
 |
5
kuituosi 364 天前
memcache
|
 |
6
Chad0000 364 天前 via iPhone 1
|
 |
7
crysislinux 364 天前 via Android
不适合肯定是不适合的，不过可以压缩一下，如果是一个大的 JSON 数组，压缩率很高的，估计压完不到 2MB
|
 |
8
lsk569937453 364 天前
网络传输是个问题
|
 |
9
zhuzhibin 364 天前 via iPhone
大 key 吃带宽 如果你的上下行带宽拉满当我没说
|
 |
10
Nazz 364 天前 via Android
这么大不放文件里
|
 |
11
GGGG430 363 天前
1) 拆分, 一个拆分成多个小 key, 再维护一个大 key 到小 key 的映射
2) 使用 memcache(多线程) 最好也加上本地缓存 |
 |
12
YongXMan 363 天前
放进去不是问题，问题是这个 key 的使用方式是怎样的，每次全量读写？读写 qps 多少？如果操作类型是 substr 这种局部查询没啥问题，否则这一个 key 20 qps 就能把万兆带宽打满了，😄
|
 |
13
qianzanqi 363 天前
适合，太适合了。只是不保证 redis 集群的 sla 而已，redis 挂了导致你们服务出问题是你们全责
|
 |
14
victorc 363 天前
不合适，这么大的数据，qps 一高，redis 必挂
|
 |
15
xuanbg 363 天前
主要看你怎么用。如果多台机器共享，那么除了 redis ，你也基本没有什么更简单的解决方案。如果单机，redis 适合整存零取或者零存零取的读写方式。整存整取的话，没必要脱裤子放屁。和数据的大小没什么关系，无论数据多大，总得读写，无非就是策略的问题，尽量避免过高的 IO 时间。
|
 |
18
dilu 362 天前
最大的问题反而在网络传输上吧，如果可以最好还是放在本地缓存，后台起个协程定时刷新就行了。
|
Select Language