大概几百万到一千万个 key
大概几百万到一千万个 key
|
selcaFeb 21, 2023
1
挪到 redis 去,让 redis 自己优化
|
|
zoharSoulFeb 21, 2023
3
没得优化, 等堆外吧. 估计下个版本就出了
|
|
4
提供一种思路,如果是容器应用,可以外挂一个 redis sidecar 来储存。通过 socket 进行通信。
同一个 network namespace 下的 socket 通信开销几乎可以忽略的。 我们通过这种方案解决过缓存占用问题,要知道 redis 的优化肯定会比你自己做好的。 |
|
8355Feb 21, 2023
7
同楼上 本质上还是本机应用 开销忽略不计 这样也好维护管理 可用性更高
|
|
NaseiFeb 21, 2023
8
这个量级的 key fastcache 也满足不了吗
|
|
9
@Nasei 感觉 freecache 比 fastcache 好. 还在想要不要自研, slice 的 hashmap 和 map + heap 的 ttl 我都造过轮子
|
|
qieqieFeb 21, 2023 via iPhone
11
cgo
|
|
dqzcwxbFeb 21, 2023
12
你可以参考 caffeine 实现一个比较完善的本地缓存,如果只需要最简单的 LRU 那么只需要 Linkedhashmap 的数据结构就可以完成
|
|
MasonnnFeb 21, 2023
13
蹲一下
|
|
zeonllFeb 21, 2023
15
如果使用 redis side car 的话,还得加一个 redis 的监控?
|
|
biubiuFFeb 21, 2023 via Android
16
用大数组存 kv
|
|
cheng6563Feb 21, 2023
17
不如直接用 unix socket 算了,性能高得很。
|
|
ToughGuyFeb 21, 2023
20
leveldb 有 cgo 的封装及原生实现,但是不知道可靠性与原生的 leveldb 相比如何。
|
|
sampengFeb 21, 2023
21
rocksdb 。
|
|
PiersSoCoolFeb 21, 2023
22
问问是什么样业务 这么时延敏感吗 gc 要多久
|
|
23
https://go.dev/doc/gc-guide 看一遍官方文档,你就会了
|
|
kafFeb 21, 2023
24
https://github.com/bluele/gcache 是要实现这个?
|
|
securityCodingFeb 21, 2023
25
我工作的原则就是不做任何 gc 优化 233 ,不管是 java 还是 go ,横向拓展就好 233
|
|
26
@securityCoding key 太多了还是要优化的
|
|
27
@PiersSoCool 不做任何优化太浪费 CPU 和内存
|
|
kiddultFeb 21, 2023
29
直接用现成的 bigcache 、freecache 那类就行,虽然多多少少有点坑,胜在能用
|
|
30
最近有文章的 Ristretto 可以看看
|
|
lesismalFeb 22, 2023
34
如果是通用缓存基础设施,用已有的那几个就可以了。但通用缓存都是走了一道序列化的,如果追求性能,表现会差一些。
如果不是通用缓存则不需要序列化,性能可以最大化,但要根据具体业务结合 kv 类型定制去指针化了。 |
|
35
可以搜下几位专家的一些帖子看看,结合自己的数据类型定制+测试优化下就差不多了:
真实环境下大内存 Go 服务性能优化一例 曹大带我学 Go ( 11 )—— 从 map 的 extra 字段谈起 |
|
janxinFeb 22, 2023
38
arena 试过了吗?
|
|
CloveAndCurrantFeb 22, 2023
41
使用 arena 自己手动管理内存,不走 go 的 gc
|
|
grzhanOct 21, 2024
42
fastcache 的方案是 mmap 自己申请管理 kv 的内存,也绕过了 gc 。
但是它的 hash -> idx ( bucket.m ) 索引本质是个 int->int 值类型的 map ,如果特别关注 gc 的话可能还是有一点优化的空间。 |