随着互联网的高速发展,市面上也出现了越来越多的网站和app
。我们判断一个软件是否好用,用户体验就是一个重要的衡量标准。比如说我们经常用的微信,打开一个页面要十几秒,发个语音要几分钟对方才能收到。相信这样的软件大家肯定是都不愿意用的。软件要做到用户体验好,响应速度快,缓存就是必不可少的一个神器。缓存又分进程内缓存和分布式缓存两种:分布式缓存如redis
、memcached
等,还有本地(进程内)缓存如ehcache
、GuavaCache
、Caffeine
等。
缓存作为一个数据数据模型对象,那么它有一些什么样的特征呢?下面我们分别来介绍下这些特征。
hitCount
(命中次数)。适用于保证高频数据有效性场景。LRU(least recently used)mq
消息。如果有数据更新mq
会把更新数据推送到每一台机器,这种方式的话实时性会比前一种定时更新的方法会好。但是实现起来会比较复杂。
常见本地缓存有以下几种实现方式:
从上述表格我们看出性能最佳的是Caffeine
。关于这个本地缓存的话我还是强烈推荐的,里面提供了丰富的api
,以及各种各样的淘汰算法。如需了解更加详细的话可以看下以前写的这个篇文章《本地缓存性能之王Caffeine》。
redis
、MemCache
等。分布式缓存的应用在高并发的环境下,比如春节抢票大战,一到放票的时间节点,分分钟大量用户以及黄牛的各种抢票软件流量进入12306
,这时候如果每个用户的访问都去数据库实时查询票的库存,大量读的请求涌入到数据库,瞬间Db
就会被打爆,cpu
直接上升100%
,服务马上就要宕机或者假死。即使进行了分库分表也是无法避免的。为了减轻db的压力以及提高系统的响应速度。一般都会在数据库前面加上一层缓存,甚至可能还会有多级缓存。缓存常见问题缓存雪崩指大量缓存同一时间段集体失效,或者缓存整体不能提供服务,导致大量的请求全部到达数据库
对数据CPU
和内存造成巨大压力,严重的会造成数据库宕机。因此而形成的一系列连锁反应造成整个系统奔溃。
解决这个问题可以从以下方面入手:redis
节点下线,缓存还是可以用。一般稍微大点的公司还可能会在多个机房部署Redis。
这样即使某个机房突然停电,或者光纤又被挖断了,这时候缓存还是可以使用。key
的过期时间,定时去轮询这些key
的过期时间。例如一个key
的value
设置的过期时间是30min
,那我们可以为这个key设置它自己的一个过期时间为20min
。所以当这个key
到了20min的时候我们就可以重新去构建这个key
的缓存,同时也更新这个key
的一个过期时间。指查询一个不存在的数据,每次通过接口或者去查询数据库都查不到这个数据,比如黑客的恶意攻击,比如知道一个订单号后,然后就伪造一些不存在的订单号,然后并发来请求你这个订单详情。这些订单号在缓存中都查询不到,然后会导致把这些查询请求全部打到数据库或者SOA接口。这样的话就会导致数据库宕机或者你的服务大量超时。
这种查询不存在的数据就是缓存击穿。
解决这个问题可以从以下方面入手:
key
(拼多多的五菱宏光神车的秒杀)在某个时间点过期。针对于这一个key有大量并发请求过来然后都会同时去数据库请求数据,瞬间对数据库造成巨大的压力。
这个的话可以用缓存雪崩的几种解决方法来避免:key
的过期时间,定时去轮询这些key
的过期时间。例如一个key
的value
设置的过期时间是30min
,那我们可以为这个key设置它自己的一个过期时间为20min
。所以当这个key到了20min的时候我们就可以重新去构建这个key
的缓存,同时也更新这个key
的一个过期时间。key
的情况下,比如你有100
个并发请求都要来取A
的缓存,这时候我们可以借助redis分布式锁来构建缓存,让只有一个请求可以去查询DB其他99个(没有获取到锁)都在外面等着,等A查询到数据并且把缓存构建好之后其他99
个请求都只需要从缓存取就好了。原理就跟我们java
的DCL
(double checked locking)思想有点类似。
master
库。毕竟这种更改订单状态的操作还是比较有限的。大多数情况都是用来展示的。展示的话是可以允许实时性要求没那么高。总的来说需要开具体的业务,没有通用的方案。看你的业务需求的容忍度,毕竟脱离了业务来谈技术都是耍流氓,是业务驱动技术。站在巨人的肩膀上摘苹果:
https://juejin.im/post/6844903665845665805
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。