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