提供了基于golang-lru的本地缓存实现

[xuhaidong1]

3

BuildinMapCache：

• 和大明之前写的差不多，采用轮询删除+懒删除的key过期策略

LRUCache：

• 注入的Cache负责存储键值对和key过期淘汰管理；
• lru策略部分选取了golang-lru中有锁但无过期时间管理的lru实现，lru部分只保存key的副本，负责操作因容量不够产生的淘汰，不负责过期淘汰。
• golang-lru提供了扩容缩容方法，我先搬过来了，如果注入的cache不限容量的话可以自由使用，如果有不妥的话可以删掉这功能
• 需要注意的是 考虑到以下场景，分别对注入cache和lru都注册了回调：

1. 场景1:主动删除注入cache中的key--需要同步删除lru副本中的key；
2. 场景2:执行lru淘汰--需要同步删除注入cache中的key；
3. 场景3:过期淘汰--需要同步删除lru副本中的key；

• 由于lru注册的回调就会产生循环回调，最后都以回调cache/lru删除不存在key结束，感觉不优雅，恳请大佬们指导
• buildinMapCache和lruCache均写了单测，lruCache写了并发测试，暂没发现死锁或数据不一致情况。 接口变更：增加了如下方法

  Delete(ctx context.Context, key string) error
  OnEvicted(fn OnEvictedFunc)

  增加别名type OnEvictedFunc func(key string, val any)

[flycash]

这边合并一下最新代码，然后拆成两个合并请求。一般来说，我们都认为一个功能点一个合并请求比较方便 review 以及后期追溯提交历史。

这边你先提交 lru-cache 的封装。一个个来

[xuhaidong1]

好的，我先把localcache放到lrucache的单测里面去吧，如果只用gomock测试封装的lrucache的话测并发有些困难，我可以保证的是测试所用的localcache和封装的lrucache没有强耦合，都是接口调用。

[flycash]

这边你不需要跟你的实现没有关系的并发问题。也就是说，你可以认为 lru-cache 是安全的。除非你自己本身引入锁之类的机制，那么可以稍微测试一下。

并发的测试用例很难设计，尽力就好。