2.7.8 gm snapshot

[lingfengcoder]

No description provided.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[areyouok]

感谢你的工作。我知道有的人面临这个问题，一直没有提供解决方案，包括以下几个原因：

1. 最早的时候jetcache希望做成一个通用的缓存包装方案（当时只提供了tair和redis的实现），只有所有cache系统都能支持的功能才能做。事实上大家主要用redis，所以后来我也做了一点妥协，比如2.7的失效通知（这也是提了很久的需求，其实我一直都知道）就是基于redis的pub/sub功能实现的。
2. 个人时间原因。
3. 没有相对完美的方案。

特定场景下对于一些特定的需求，我认为多fork发展自己的分支是非常好的，所以你的补丁是非常有意义的。但如果要集成进来作为通用解决方案，它还存在一些问题：

1. 时间复杂度是O(N)，对于key特别多的情况，性能会存在问题。对于客户端，可能造成用户的方法迟迟不能返回，对于redis服务端，会增加不少压力。
2. 迭代不是原子性的，如果有并发的写入，会删不干净。这个问题可能不那么大，只要把删除开始时间点以前的数据都删掉也行。
3. 没有提供lettuce等客户端的实现。

其实还可以有其它方法，比如在CacheValueHolder里面增加一个createTime字段，需要删除的时候按时间戳广播一个失效通知，这样时间复杂度可以做到O(1)

[lingfengcoder]

hi
我又想了下，”CacheValueHolder里面增加一个createTime字段，需要删除的时候按时间戳广播一个失效通知“ 这个方案具体实施起来有一点疑问：1.副本在收到prefix和createtime可以选择去删除或者在获取缓存的时候标记失效，这就需要有一个map去存储prefix和createtime，但问题是，什么时间删除这些prefix和createtime，如果不管势必会有内存压力（其实还好，但是不够优雅）；2.想到可以设置一个prefix的最大存活时间，但是又不能获取所有prefix下的子集的最大存活时间。所以有其他更好的方案吗
谢谢

[areyouok]

hi 我又想了下，”CacheValueHolder里面增加一个createTime字段，需要删除的时候按时间戳广播一个失效通知“ 这个方案具体实施起来有一点疑问：1.副本在收到prefix和createtime可以选择去删除或者在获取缓存的时候标记失效，这就需要有一个map去存储prefix和createtime，但问题是，什么时间删除这些prefix和createtime，如果不管势必会有内存压力（其实还好，但是不够优雅）；2.想到可以设置一个prefix的最大存活时间，但是又不能获取所有prefix下的子集的最大存活时间。所以有其他更好的方案吗 谢谢

1. createTime放在每一个CacheValueHolder里面
2. deleteAll的时候将当前时间戳放到redis里面，key类似于"${cacheNamePrefix}_delete_time"
3. get以后如果发现CacheValueHolder里面的createTime小于${cacheNamePrefix}_delete_time"的时间戳，那么这次get的内容是无效的
4. jvm启动以后是没有这个delete时间戳的，所以每个cache第一个get的时候，要去多读一次${cacheNamePrefix}_delete_time。以后的增量更新可以走广播