golang 内存 kv 缓存怎么做 gc 优化？

[Nazz]

大概几百万到一千万个 key

[selca]

挪到 redis 去，让 redis 自己优化

[Nazz]

@selca 要的就是避免网络 IO😂

[zoharSoul]

没得优化, 等堆外吧. 估计下个版本就出了

[fioncat]

提供一种思路，如果是容器应用，可以外挂一个 redis sidecar 来储存。通过 socket 进行通信。
同一个 network namespace 下的 socket 通信开销几乎可以忽略的。
我们通过这种方案解决过缓存占用问题，要知道 redis 的优化肯定会比你自己做好的。

[Nazz]

@zoharSoul 小技巧应该是有的

[Nazz]

@fioncat 可行性不错, 不知道领导满不满意

[8355]

同楼上 本质上还是本机应用 开销忽略不计 这样也好维护管理 可用性更高

[Nasei]

这个量级的 key fastcache 也满足不了吗

[Nazz]

@Nasei 感觉 freecache 比 fastcache 好. 还在想要不要自研, slice 的 hashmap 和 map + heap 的 ttl 我都造过轮子

[Nazz]

@Nasei fastcache 也不错, ttl 部分可以自己撸

[qieqie]

cgo

[dqzcwxb]

你可以参考 caffeine 实现一个比较完善的本地缓存,如果只需要最简单的 LRU 那么只需要 Linkedhashmap 的数据结构就可以完成

[WhereverYouGo]

蹲一下

[Nazz]

@qieqie cgo 太不清真了

[zeonll]

如果使用 redis side car 的话，还得加一个 redis 的监控？

[biubiuF]

用大数组存 kv

[cheng6563]

不如直接用 unix socket 算了，性能高得很。

[Nazz]

@zeonll 有过期时间不加也没事, pod 本身有内存监控

[Nazz]

@cheng6563 还是觉得纯 Go 方案优雅些

[ToughGuy]

leveldb 有 cgo 的封装及原生实现，但是不知道可靠性与原生的 leveldb 相比如何。