Golang Go语言中local cache需要在集群的服务器之间做同步吗?怎么做?

发布于 1周前 作者 wuwangju 来自 Go语言

问个问题,用 golang 的 local cache 库(如 groupcache 、bigcache 等)的时候,有两种方案:
1 、local cache 通过某种机制同步到集群的每台机器上;(不太确定要怎么实现,我看开源的都没有提供相应的能力,个人感觉如果有这种需求直接用 redis 就好了)
2 、不管这个,每台服务器维护自己的 cache;(不知道这种方案是不是有什么坑)

有线上环境用过 local cache 的大佬吗?能一起讨论一下这个问题吗?
Golang Go语言中local cache需要在集群的服务器之间做同步吗?怎么做?

12 回复

要看需求怎么样,比如有没有 redis ,如果已经有 redis 可以考虑带有 client side caching 的[rueidis]( https://github.com/redis/rueidis). 如果不想用 redis 而且实时同步要求不高的话可以考虑用普通的 local cache 设个比较短的 ttl ,比如 1 分钟。但这样会有 1 分钟的数据不一致。或者说你的数据量太大,而且没有特别热点的数据,由于本地缓存容量有限因此命中率会极低,只能上 redis 或者类似的远程 kv 。如果你考虑使用 local cache ,欢迎试用我的[Theine]( https://github.com/Yiling-J/theine-go)

更多关于Golang Go语言中local cache需要在集群的服务器之间做同步吗?怎么做?的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


本地缓存性能来说应该是 redis 高的、缺点就是多节点就必须多份缓存。缓存一致性问题
比如 guava cache 过期就异步 load 也可以。具体看怎么用吧。我觉得读多写少、数据不大用本地缓存还不是不错的。
否则要么就 redis 吧 省事。

你都用 local cache 了,怎么还考虑分布式的问题。如果真的想比较强命中,上游可以做一个哈希获取下游地址的策略,通过 cache key 大概率会走到同一台机器。这个问题是对 k8s 比较不友好

我自己想了一下,其实可以先存 redis 里面,然后监听 redis 的变更,订阅变更事件,同步更新 local cache 的数据,查询优先查 local ,查不到就查 redis ,并且查完存 local ,这样应该就是一个多级缓存的概念了,这个其实也是我想要的效果

你说的其实就是 rueidis 做的事情。但是如果你准备自己开发的话,我建议可以同时存到 redis 和本地而不是下一次 redis 读出来再存。大部分 memory cache 都能限制最大数量所以没什么问题。

太脆弱,如何保证肯定不出错是个问题,有个变更事件没接到或者挂了想再一致太难,缓存的作用是在超大量的时候提高大部分效率,而不是在小流量下加速所有请求,这种没意义,本地缓存的真正价值是读取延时纳秒级,就算过期时间 10 毫秒,假如每秒 10000 次调用,其加速也是巨大的,如果每秒 10 次调用,你再怎么搞也毫无意义,redis 延时毫秒级,数据库几十毫秒,你本地缓存搞个分布式不是把纳秒级延时生生搞到毫秒级了么,这完完全全是负优化,别钻牛角尖啊

本地缓存要么是很长时间不变的,比如各种 secret ,或者集群状态缓存之类不断上报的,要么是读取频率超高,比如数十毫秒过期还能有 10 比 1 命中率的,否则没啥用的价值,redis 缓存怎么也得有 4 比 1 的命中率才有用的价值吧,否则一味搞缓存真的是负优化,纯粹就是给自己找麻烦

本地缓存不需要做强一致性,也没办法做到强一致性,一般存到本地缓存的数据,对一致性的要求不能太高,要允许一段时间的数据更新信号和处理的时间差

参考楼上,你这脑回路就不太对。要是那么好做人人都能写一个分布式缓存

本地缓存搞啥分布式,分布式那不就是 redis 吗?

使用 redis 的消息订阅,一旦某个实例要同步,发送消息广播, 各个实例收到消息, 更新本地 cache , 达到服务器之间同步的需求

在Golang中,关于local cache是否需要在集群的服务器之间做同步,这取决于你的应用需求和业务场景。如果集群中的每个服务器都需要访问到最新的数据,并且数据的一致性非常重要,那么就需要实现local cache的同步。

实现local cache同步的方法有多种,以下是一些常见的策略:

  1. 基于消息队列的同步:可以利用Kafka等消息队列,通过订阅或分配特定的topic-partitions,确保每个服务器都能接收到数据更新的通知,并据此更新自己的local cache。
  2. 分布式锁:使用分布式锁(如基于Redis的分布式锁)来确保在更新cache时只有一个服务器能进行操作,从而避免数据冲突。
  3. 广播机制:在某些场景下,可以通过广播机制将数据更新的通知发送到集群中的每个服务器。

在实际应用中,选择哪种同步策略需要根据具体的业务场景、数据一致性要求、系统性能等因素进行权衡。同时,也需要注意同步过程中可能出现的网络延迟、数据丢失等问题,并采取相应的措施进行应对。

总之,local cache的同步是一个复杂的问题,需要根据实际情况进行具体的设计和实现。

回到顶部