锁定老帖子 主题:自定义cache接口实现与缓存框架解耦
精华帖 (0) :: 良好帖 (2) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2010-06-23
J-catTeam 写道 luckaway 写道 那倒也是,实际中put(String key, Object value, Date expireDate)这个不太用的到
我是直接根据有效时间计算出expireDate值的 代码如下 public class MemStore<K, V> implements Storable<K, V> { private static final String DEFAULT_NAME = "default"; /** * cache命名空间,防止key冲突。 不同的name使用不同的{@link SockIO} */ private String name = null; // memcached的server列表 private List<String> serverList = null; // 缓存对象的存活时间 private long liveSecond = 0; private MemCachedClient memCachedClient = null; private SockIOPool pool = null; private boolean initialized = false; /** spring inject */ @Override public void setName(String name) { this.name = name; } public void setServerList(List<String> serverList) { this.serverList = serverList; } public void setLiveSecond(long liveSecond) { this.liveSecond = liveSecond; } } put(String key, Object value, long expireDate)不好么? 跨系统的key是否在这里不好维护 实际项目中不太会用的到,同一个类型的数据,有效时间肯定都是一致的! |
|
返回顶楼 | |
发表时间:2010-06-23
pengzhoushuo 写道 luckaway 写道 slaser 写道 个人觉得缓存实现切换的必要性不大。
主要看做什么项目了, 比如程序以前跑在一台机器上,现在改成集群方式 那就要改成分布式缓存了。 我也碰到这种情况,做一个facebook app,要预留分布式接口,但目前是单机应用。 PS:单机下memcache跟ehcache等缓存比起来差远了,时间比高达100:1,不过前者是跨server的,时间要消耗在网络带宽上.而后者在同个jvm进程内,速度差两个数量级也在情理之中。 恩,java序列化和反序列化的效率也不高,所以java项目尽量还是采用本地cache。 |
|
返回顶楼 | |
发表时间:2010-06-23
我觉得还是需要根据特定的场景,做接口的设计,做出一个大而全的东西,总是不能太贴心。
|
|
返回顶楼 | |
发表时间:2010-06-23
自定义接口的做法等同于创造标准,在没有规范标准的缓存框架中创造标准很难。
但然未必就会失败,能否成功取决于接口定义的功能集是否在全部或者多个第三方缓存框架功能交集中,如果在那么ok这个接口没有问题。 否则,为了用了某个特定缓存框架的功能,必然就在接口上开放这个定义,但无论这个功能无法再其他缓存框架上实现,所谓缓存切换也无从谈起,这个接口的定义反而成为累赘了。 |
|
返回顶楼 | |
发表时间:2010-06-24
yimlin 写道 自定义接口的做法等同于创造标准,在没有规范标准的缓存框架中创造标准很难。
但然未必就会失败,能否成功取决于接口定义的功能集是否在全部或者多个第三方缓存框架功能交集中,如果在那么ok这个接口没有问题。 否则,为了用了某个特定缓存框架的功能,必然就在接口上开放这个定义,但无论这个功能无法再其他缓存框架上实现,所谓缓存切换也无从谈起,这个接口的定义反而成为累赘了。 恩,是需要舍弃一些高级的功能! 虽然缓存没有规范标准,但肯定都是key-value存储方式的!各个框架对扩展功能的支持不一致,我们也可以在适配器里进行实现。 比如ehcache->memcached。但是memcached不支持清空、获取缓存池里的对象等,但是我们又非要用到这些属性,那我们就需要对memcached进行扩展,比如自己再存储一份key集合。 如果扩展的复杂已经超出我们的能力范围,那肯定是切换不了,哪怕是在没有自定义接口的情况下也切换不了 |
|
返回顶楼 | |
发表时间:2010-06-24
虽然换缓存的几率不大,但是我觉得采用这种方式来使用缓存,在代码上会优雅一些。
|
|
返回顶楼 | |
发表时间:2010-06-24
还是不错的,至少表面上解决了以后的扩展的问题,不过实际应用中更换Cache真是个大工程
|
|
返回顶楼 | |
发表时间:2010-06-25
sky3380 写道 slaser 写道 个人觉得缓存实现切换的必要性不大。
比较同意,就数据库一样,更换数据库的几率很小,除非你刚开始就选错了~ 换数据库是常见的事情,可能你们没接触过把 ,尤其是移动的项目,每个省可能有的数据库都不一样,用什么数据库不是我们决定的,而是移动决定的,有的省花了2000万买断了sybase,他会去用oracle吗 |
|
返回顶楼 | |