这是一个创建于 1010 天前的主题，其中的信息可能已经有所发展或是发生改变。
大概几百万到一千万个 key
第 1 条附言 2023-02-22 08:56:58 +08:00
已经了解到, 尽量去使用值类型和切片就能缓解 GC 压力了, 谢谢各位. 可以完全使用切片去实现一个 HashMap, uint32 模拟前后指针实现链表, 使用[]byte 作为 KV, 这应该是目前最安全便利的方案了.
 | 1 selca 2023-02-21 13:14:13 +08:00 挪到 redis 去，让 redis 自己优化 |
 | 3 zoharSoul 2023-02-21 13:19:10 +08:00 没得优化, 等堆外吧. 估计下个版本就出了 |
 | 4 fioncat 2023-02-21 13:36:06 +08:00  5 提供一种思路，如果是容器应用，可以外挂一个 redis sidecar 来储存。通过 socket 进行通信。 同一个 network namespace 下的 socket 通信开销几乎可以忽略的。 我们通过这种方案解决过缓存占用问题，要知道 redis 的优化肯定会比你自己做好的。 |
 | 7 8355 2023-02-21 13:54:32 +08:00 同楼上 本质上还是本机应用 开销忽略不计 这样也好维护管理 可用性更高 |
 | 8 Nasei 2023-02-21 14:12:08 +08:00 这个量级的 key fastcache 也满足不了吗 |
 | 9 Nazz OP @Nasei 感觉 freecache 比 fastcache 好. 还在想要不要自研, slice 的 hashmap 和 map + heap 的 ttl 我都造过轮子 |
 | 11 qieqie 2023-02-21 14:28:48 +08:00 via iPhone cgo |
 | 12 dqzcwxb 2023-02-21 14:35:14 +08:00 你可以参考 caffeine 实现一个比较完善的本地缓存,如果只需要最简单的 LRU 那么只需要 Linkedhashmap 的数据结构就可以完成 |
 | 13 Masonnn 2023-02-21 15:37:15 +08:00 蹲一下 |
 | 15 zeonll 2023-02-21 16:46:46 +08:00 如果使用 redis side car 的话，还得加一个 redis 的监控？ |
 | 16 biubiuF 2023-02-21 16:51:44 +08:00 via Android 用大数组存 kv |
 | 17 cheng6563 2023-02-21 17:26:11 +08:00 不如直接用 unix socket 算了，性能高得很。 |
 | 20 ToughGuy 2023-02-21 17:46:24 +08:00 leveldb 有 cgo 的封装及原生实现，但是不知道可靠性与原生的 leveldb 相比如何。 |
 | 21 sampeng 2023-02-21 19:01:53 +08:00 rocksdb 。 |
 | 22 PiersSoCool 2023-02-21 19:51:19 +08:00 问问是什么样业务 这么时延敏感吗 gc 要多久 |
 | 23 777777 2023-02-21 20:06:06 +08:00 1 https://go.dev/doc/gc-guide 看一遍官方文档，你就会了 |
 | 24 kaf 2023-02-21 20:21:32 +08:00 https://github.com/bluele/gcache 是要实现这个？ |
 | 25 securityCoding 2023-02-21 20:40:02 +08:00 我工作的原则就是不做任何 gc 优化 233 ，不管是 java 还是 go ，横向拓展就好 233 |
| 26 Nazz OP @securityCoding key 太多了还是要优化的 |
| 27 Nazz OP @PiersSoCool 不做任何优化太浪费 CPU 和内存 |
 | 29 kiddult 2023-02-21 21:05:29 +08:00 直接用现成的 bigcache 、freecache 那类就行，虽然多多少少有点坑，胜在能用 |
 | 30 fuxiaohei 2023-02-21 21:06:42 +08:00 1 最近有文章的 Ristretto 可以看看 |
 | 34 lesismal 2023-02-22 00:17:43 +08:00 如果是通用缓存基础设施，用已有的那几个就可以了。但通用缓存都是走了一道序列化的，如果追求性能，表现会差一些。 如果不是通用缓存则不需要序列化，性能可以最大化，但要根据具体业务结合 kv 类型定制去指针化了。 |
| 35 lesismal 2023-02-22 00:23:16 +08:00 1 可以搜下几位专家的一些帖子看看，结合自己的数据类型定制+测试优化下就差不多了： 真实环境下大内存 Go 服务性能优化一例 曹大带我学 Go （ 11 ） 从 map 的 extra 字段谈起 |
| 37 OP @lesismal 有空自己写一个玩玩 带 TTL 的 ConvurrentMap 和切片实现的 HashMap 我都实现过 |
 | 38 janxin 2023-02-22 08:30:44 +08:00 arena 试过了吗？ |
 | 41 CloveAndCurrant 2023-02-22 10:17:00 +08:00 使用 arena 自己手动管理内存，不走 go 的 gc |
 | 42 grzhan 2024-10-21 08:35:08 +08:00 fastcache 的方案是 mmap 自己申请管理 kv 的内存，也绕过了 gc 。 但是它的 hash -> idx （ bucket.m ） 索引本质是个 int->int 值类型的 map ，如果特别关注 gc 的话可能还是有一点优化的空间。 |
Select Language