巧妙设计多级缓存,为数据库减负巧妙设计多级缓存,为数据库减负
自古兵家多谋,《谋攻篇》,“故上兵伐谋,其次伐交,其次伐兵,其下攻城。攻城之法,为不得已”,可见攻城之计有很多
种,而爬墙攻城是最不明智的做法,军队疲惫受损、钱粮损耗、百姓遭殃。故而我们有很多迂回之策,谋略、外交、军事手段
等等,每一种都比攻城的代价小,更轻量级,缓存设计亦是如此。
一、为什么要设计缓存?
其实高并发应对的解决方案不是互联网独创的,计算机先祖们很早就对类似的场景做了方案。比如《计算机组成原理》这样提
到的CPU缓存概念:它是一种高速缓存,容量比内存小但是速度却快很多,这种缓存的出现主要是为了解决CPU运算速度远大
于内存读写速度,甚至达到千万倍的问题。
传统的CPU通过fsb直连内存的方式显然就会因为内存访问的等待,导致CPU吞吐量下降,内存成为性能瓶颈。同时又由于内
存访问的热点数据集中性,所以需要在CPU与内存之间做一层临时的存储器作为高速缓存。
随着系统复杂性的提升,这种高速缓存和内存之间的速度进一步拉开,由于技术难度和成本等原因,所以有了更大的二级、三
级缓存。根据读取顺序,绝大多数的请求首先落在一级缓存上,其次二级...
故而应用于SOA甚至微服务的场景,内存相当于存储业务数据的持久化数据库,其吞吐量肯定是远远小于缓存的,而对于java
程序来讲,本地的JVM缓存优于集中式的Redis缓存。
关系型数据库操作方便、易于维护且访问数据灵活,但是随着数据量的增加,其检索、更新的效率会越来越低。所以在高并发
低延迟要求复杂的场景,要给数据库减负,减少其压力。
二、给数据库减负
1.缓存分布式,做多级缓存
读请求时写缓存
写缓存时一级一级写,先写本地缓存,再写集中式缓存。具体些缓存的方法可以有很多种,但是需要注意几项原则:
不要复制粘贴,避免重复代码;
切忌和业务耦合太紧,不利于后期维护;
评论0
最新资源