先分享下我基于MAP实现的一个本地缓存
本地缓存
优势:
1,易用,只是比map多了个过期时间,有超时的概念
2,用软引用,可防止对JVM的堆对象造成out memory
3, 相对集中缓存不需要进行网络开销,消除RPC
缺点:
1,用的是堆内存。会对JVM的垃圾回收造成影响
2,大小控制只能是通过KEY值的存储数量控制,无法通过控制内存占用大小
3,缺少监控方面的设计
4,没有缓存的移除,定期清除失效缓存
5,缓存穿透的问题,当缓存失效时间时,大量访问到了缓存的传统,压到数据库去了
对于3,4问题可以用google的guava
对于1,ehcache可以用JAVA的直接内存.
对于直接内存这部分不好实现,JAVA只提供了个ByteBuffer.allocateDirect(capacity)的方法去应用直接内存,也就意味着要存入直接内存必须先把整个对象序列号成byte再放入直接内存。
但这样每次都需要序列号与反序列化的开销,而且得全量加载的堆内存引起垃圾回收。ehcache有直接用native方法实现
踩过的坑:
缓存失效
当缓存出现失效, 瞬间大量访问压到了DB,造成DB的压力
解决:
1,不用失效时间来触发缓存的更新
1, 后台定时刷新最新内容到本地缓存,不依靠失效时间来触发。
2, 结合广播通知模式(如 redis)+本地缓存更新进行更新缓存,而不是通过失效来触发(目前系统主要就是这个模式,待加上案例分享)
当然,两种进行结合效果更好,
WEB服务器不停监控redis的访问,同时定时轮询,覆盖缓存中的内容
2,通过控制进入DB操作的线程数进行控制
如, 通过重入锁的,tryLock的condition,condition,阻塞超时方法,通知等进行控制(待加上案例分享)
缓存穿透
当访问不存在的KEY时,一直传入到数据库层面去,压到DB,造成DB的压
解决:
1, 添加计数器,如当一个KEY的次数达到了10次后, 在缓存总加入该KEY,进行null的返回
2, 是否符合KEY的规则 + Bloom Filter, 用redis的bitmap存数组,对已存在的值进行hash存入(如果是ID,直接存,不需要hash,准确率100%)。 如果访问的有bit位置为0的,必定不存在
返回同一对象地址
本地缓存读取后的修改,会相互影响的问题
解决:
如果需要修改,返回对象需要进行深度clone
欢迎关注我的公众号,重现线上各种BUG, 一起来构建我们的知识体系