精华内容
下载资源
问答
  • 缓存对项目有什么好处
    万次阅读
    2020-10-12 22:28:14

    用缓存主要是两个用途,高性能和高并发

    1. 高性能
      假如有1000个请求要去查询同一条数据,如果1000个请求直接去数据库中查找,而且这个查找sql比较耗时,那么这1000个请求每个都会很慢.
      如果在查询系统和数据库中间加一层缓存,那么第一个请求查询数据库,会慢一点,查出来结果保存到缓存中,只要这个数据在一段时间内不会改变,其他999个请求就可以都去缓存中查询数据,就会很快
      如果数据在后续变化了,系统在修改数据库的同时,去更新一下缓存中的数据就可以了
    2. 高并发
      在高并发的时候,瞬间每秒压力激增,数据库承受不住一下子涌入的请求,可以把很多数据放在缓存中,从缓存中去操作,大幅度提升性能一般公司都是用缓存来实现高性能的
    更多相关内容
  • 这就是看看你对缓存这个东西背后没有思考,如果你就是傻乎乎的瞎用,没法给面试官一个合理的解答,那面试官你印象肯定不太好,觉得你平时思考太少,就知道干活儿。 面试题剖析 项目缓存是如何使用的? 这个...

    问题

    项目中缓存是如何使用的?为什么要用缓存?缓存使用不当会造成什么后果?

    分析

    这个问题,互联网公司必问,要是一个人连缓存都不太清楚,那确实比较尴尬。

    只要问到缓存,上来第一个问题,肯定是先问问你项目哪里用了缓存?为啥要用?不用行不行?如果用了以后可能会有什么不良的后果?

    这就是看看你对缓存这个东西背后有没有思考,如果你就是傻乎乎的瞎用,没法给面试官一个合理的解答,那面试官对你印象肯定不太好,觉得你平时思考太少,就知道干活儿。

    面试题剖析

    项目中缓存是如何使用的?

    这个,需要结合自己项目的业务来。

    为什么要用缓存?

    用缓存,主要有两个用途:高性能、高并发。

    高性能

    假设这么个场景,你有个操作,一个请求过来,吭哧吭哧你各种乱七八糟操作 mysql,半天查出来一个结果,耗时 600ms。但是这个结果可能接下来几个小时都不会变了,或者变了也可以不用立即反馈给用户。那么此时咋办?

    缓存啊,折腾 600ms 查出来的结果,扔缓存里,一个 key 对应一个 value,下次再有人查,别走 mysql 折腾 600ms 了,直接从缓存里,通过一个 key 查出来一个 value,2ms 搞定。性能提升 300 倍。

    就是说对于一些需要复杂操作耗时查出来的结果,且确定后面不怎么变化,但是有很多读请求,那么直接将查询出来的结果放在缓存中,后面直接读缓存就好。

    高并发

    mysql 这么重的数据库,压根儿设计不是让你玩儿高并发的,虽然也可以玩儿,但是天然支持不好。mysql 单机支撑到 2000QPS 也开始容易报警了。

    所以要是你有个系统,高峰期一秒钟过来的请求有 1万,那一个 mysql 单机绝对会死掉。你这个时候就只能上缓存,把很多数据放缓存,别放 mysql。缓存功能简单,说白了就是 key-value 式操作,单机支撑的并发量轻松一秒几万十几万,支撑高并发 so easy。单机承载并发量是 mysql 单机的几十倍。

    缓存是走内存的,内存天然就支撑高并发。

    用了缓存之后会有什么不良后果?

    常见的缓存问题有以下几个:

    • 缓存与数据库双写不一致

    • 缓存雪崩、缓存穿透

    • 缓存并发竞争

    问题1:如何保证缓存与数据库的双写一致性?

    分析

    你只要用缓存,就可能会涉及到缓存与数据库双存储双写,你只要是双写,就一定会有数据一致性的问题,那么你如何解决一致性问题?

    面试题剖析

    一般来说,如果允许缓存可以稍微的跟数据库偶尔有不一致的情况,也就是说如果你的系统不是严格要求 “缓存+数据库” 必须保持一致性的话,最好不要做这个方案,即:读请求和写请求串行化,串到一个内存队列里去。

    串行化可以保证一定不会出现不一致的情况,但是它也会导致系统的吞吐量大幅度降低,用比正常情况下多几倍的机器去支撑线上的一个请求。

    Cache Aside Pattern

    最经典的缓存+数据库读写的模式,就是 Cache Aside Pattern。

    • 读的时候,先读缓存,缓存没有的话,就读数据库,然后取出数据后放入缓存,同时返回响应。

    • 更新的时候,先更新数据库,然后再删除缓存。

    为什么是删除缓存,而不是更新缓存?

    原因很简单,很多时候,在复杂点的缓存场景,缓存不单单是数据库中直接取出来的值。

    比如可能更新了某个表的一个字段,然后其对应的缓存,是需要查询另外两个表的数据并进行运算,才能计算出缓存最新的值的。

    另外更新缓存的代价有时候是很高的。是不是说,每次修改数据库的时候,都一定要将其对应的缓存更新一份?也许有的场景是这样,但是对于比较复杂的缓存数据计算的场景,就不是这样了。如果你频繁修改一个缓存涉及的多个表,缓存也频繁更新。但是问题在于,这个缓存到底会不会被频繁访问到?

    举个栗子,一个缓存涉及的表的字段,在 1 分钟内就修改了 20 次,或者是 100 次,那么缓存更新 20 次、100 次;但是这个缓存在 1 分钟内只被读取了 1 次,有大量的冷数据。实际上,如果你只是删除缓存的话,那么在 1 分钟内,这个缓存不过就重新计算一次而已,开销大幅度降低。用到缓存才去算缓存。

    其实删除缓存,而不是更新缓存,就是一个 lazy 计算的思想,不要每次都重新做复杂的计算,不管它会不会用到,而是让它到需要被使用的时候再重新计算。像 mybatis,hibernate,都有懒加载思想。查询一个部门,部门带了一个员工的 list,没有必要说每次查询部门,都里面的 1000 个员工的数据也同时查出来啊。80% 的情况,查这个部门,就只是要访问这个部门的信息就可以了。先查部门,同时要访问里面的员工,那么这个时候只有在你要访问里面的员工的时候,才会去数据库里面查询 1000 个员工。

    最初级的缓存不一致问题及解决方案

    问题:先更新数据库,再删除缓存。如果删除缓存失败了,那么会导致数据库中是新数据,缓存中是旧数据,数据就出现了不一致。

    解决思路:先删除缓存,再更新数据库。如果数据库更新失败了,那么数据库中是旧数据,缓存中是空的,那么数据不会不一致。因为读的时候缓存没有,所以去读了数据库中的旧数据,然后更新到缓存中。

    比较复杂的数据不一致问题分析

    数据发生了变更,先删除了缓存,然后要去修改数据库,此时还没修改。一个请求过来,去读缓存,发现缓存空了,去查询数据库,查到了修改前的旧数据,放到了缓存中。随后数据变更的程序完成了数据库的修改。完了,数据库和缓存中的数据不一样了...

    为什么上亿流量高并发场景下,缓存会出现这个问题?

    只有在对一个数据在并发的进行读写的时候,才可能会出现这种问题。其实如果说你的并发量很低的话,特别是读并发很低,每天访问量就 1 万次,那么很少的情况下,会出现刚才描述的那种不一致的场景。但是问题是,如果每天的是上亿的流量,每秒并发读是几万,每秒只要有数据更新的请求,就可能会出现上述的数据库+缓存不一致的情况。

    解决方案如下:

    更新数据的时候,根据数据的唯一标识,将操作路由之后,发送到一个 jvm 内部队列中。读取数据的时候,如果发现数据不在缓存中,那么将重新读取数据+更新缓存的操作,根据唯一标识路由之后,也发送同一个 jvm 内部队列中。

    一个队列对应一个工作线程,每个工作线程串行拿到对应的操作,然后一条一条的执行。这样的话,一个数据变更的操作,先删除缓存,然后再去更新数据库,但是还没完成更新。此时如果一个读请求过来,没有读到缓存,那么可以先将缓存更新的请求发送到队列中,此时会在队列中积压,然后同步等待缓存更新完成。

    这里有一个优化点,一个队列中,其实多个更新缓存请求串在一起是没意义的,因此可以做过滤,如果发现队列中已经有一个更新缓存的请求了,那么就不用再放个更新请求操作进去了,直接等待前面的更新操作请求完成即可。

    待那个队列对应的工作线程完成了上一个操作的数据库的修改之后,才会去执行下一个操作,也就是缓存更新的操作,此时会从数据库中读取最新的值,然后写入缓存中。

    如果请求还在等待时间范围内,不断轮询发现可以取到值了,那么就直接返回;如果请求等待的时间超过一定时长,那么这一次直接从数据库中读取当前的旧值。

    高并发的场景下,该解决方案要注意的问题:

    读请求长时阻塞

    由于读请求进行了非常轻度的异步化,所以一定要注意读超时的问题,每个读请求必须在超时时间范围内返回。

    该解决方案,最大的风险点在于说,可能数据更新很频繁,导致队列中积压了大量更新操作在里面,然后读请求会发生大量的超时,最后导致大量的请求直接走数据库。务必通过一些模拟真实的测试,看看更新数据的频率是怎样的。

    另外一点,因为一个队列中,可能会积压针对多个数据项的更新操作,因此需要根据自己的业务情况进行测试,可能需要部署多个服务,每个服务分摊一些数据的更新操作。如果一个内存队列里居然会挤压 100 个商品的库存修改操作,每隔库存修改操作要耗费 10ms 去完成,那么最后一个商品的读请求,可能等待 10 * 100 = 1000ms = 1s 后,才能得到数据,这个时候就导致读请求的长时阻塞。

    一定要做根据实际业务系统的运行情况,去进行一些压力测试,和模拟线上环境,去看看最繁忙的时候,内存队列可能会挤压多少更新操作,可能会导致最后一个更新操作对应的读请求,会 hang 多少时间,如果读请求在 200ms 返回,如果你计算过后,哪怕是最繁忙的时候,积压 10 个更新操作,最多等待 200ms,那还可以的。

    如果一个内存队列中可能积压的更新操作特别多,那么你就要加机器,让每个机器上部署的服务实例处理更少的数据,那么每个内存队列中积压的更新操作就会越少。

    其实根据之前的项目经验,一般来说,数据的写频率是很低的,因此实际上正常来说,在队列中积压的更新操作应该是很少的。像这种针对读高并发、读缓存架构的项目,一般来说写请求是非常少的,每秒的 QPS 能到几百就不错了。

    我们来实际粗略测算一下。

    如果一秒有 500 的写操作,如果分成 5 个时间片,每 200ms 就 100 个写操作,放到 20 个内存队列中,每个内存队列,可能就积压 5 个写操作。每个写操作性能测试后,一般是在 20ms 左右就完成,那么针对每个内存队列的数据的读请求,也就最多 hang 一会儿,200ms 以内肯定能返回了。

    经过刚才简单的测算,我们知道,单机支撑的写 QPS 在几百是没问题的,如果写 QPS 扩大了 10 倍,那么就扩容机器,扩容 10 倍的机器,每个机器 20 个队列。

    读请求并发量过高

    这里还必须做好压力测试,确保恰巧碰上上述情况的时候,还有一个风险,就是突然间大量读请求会在几十毫秒的延时 hang 在服务上,看服务能不能扛的住,需要多少机器才能扛住最大的极限情况的峰值。

    但是因为并不是所有的数据都在同一时间更新,缓存也不会同一时间失效,所以每次可能也就是少数数据的缓存失效了,然后那些数据对应的读请求过来,并发量应该也不会特别大。

    多服务实例部署的请求路由

    可能这个服务部署了多个实例,那么必须保证说,执行数据更新操作,以及执行缓存更新操作的请求,都通过 Nginx 服务器路由到相同的服务实例上。

    比如说,对同一个商品的读写请求,全部路由到同一台机器上。可以自己去做服务间的按照某个请求参数的 hash 路由,也可以用 Nginx 的 hash 路由功能等等。

    热点商品的路由问题,导致请求的倾斜

    万一某个商品的读写请求特别高,全部打到相同的机器的相同的队列里面去了,可能会造成某台机器的压力过大。就是说,因为只有在商品数据更新的时候才会清空缓存,然后才会导致读写并发,所以其实要根据业务系统去看,如果更新频率不是太高的话,这个问题的影响并不是特别大,但是的确可能某些机器的负载会高一些。

    问题2:了解什么是 redis 的雪崩、穿透和击穿?redis 崩溃之后会怎么样?系统该如何应对这种情况?如何处理 redis 的穿透?

    分析

    其实这是问到缓存必问的,因为缓存雪崩和穿透,是缓存最大的两个问题,要么不出现,一旦出现就是致命性的问题,所以面试官一定会问你。

    面试题剖析

    缓存雪崩

    对于系统 A,假设每天高峰期每秒 5000 个请求,本来缓存在高峰期可以扛住每秒 4000 个请求,但是缓存机器意外发生了全盘宕机。缓存挂了,此时 1 秒 5000 个请求全部落数据库,数据库必然扛不住,它会报一下警,然后就挂了。此时,如果没有采用什么特别的方案来处理这个故障,DBA 很着急,重启数据库,但是数据库立马又被新的流量给打死了。

    这就是缓存雪崩。

    大约在 3 年前,国内比较知名的一个互联网公司,曾因为缓存事故,导致雪崩,后台系统全部崩溃,事故从当天下午持续到晚上凌晨 3~4 点,公司损失了几千万。

    缓存雪崩的事前事中事后的解决方案如下。

    • 事前:redis 高可用,主从+哨兵,redis cluster,避免全盘崩溃。

    • 事中:本地 ehcache 缓存 + hystrix 限流&降级,避免 MySQL 被打死。

    • 事后:redis 持久化,一旦重启,自动从磁盘上加载数据,快速恢复缓存数据。

    用户发送一个请求,系统 A 收到请求后,先查本地 ehcache 缓存,如果没查到再查 redis。如果 ehcache 和 redis 都没有,再查数据库,将数据库中的结果,写入 ehcache 和 redis 中。

    限流组件,可以设置每秒的请求,有多少能通过组件,剩余的未通过的请求,怎么办?走降级!可以返回一些默认的值,或者友情提示,或者空白的值。

    好处:

    • 数据库绝对不会死,限流组件确保了每秒只有多少个请求能通过。

    • 只要数据库不死,就是说,对用户来说,2/5 的请求都是可以被处理的。

    • 只要有 2/5 的请求可以被处理,就意味着你的系统没死,对用户来说,可能就是点击几次刷不出来页面,但是多点几次,就可以刷出来一次。

    缓存穿透

    对于系统A,假设一秒 5000 个请求,结果其中 4000 个请求是黑客发出的恶意攻击。

    黑客发出的那 4000 个攻击,缓存中查不到,每次你去数据库里查,也查不到。

    举个栗子。数据库 id 是从 1 开始的,结果黑客发过来的请求 id 全部都是负数。这样的话,缓存中不会有,请求每次都“视缓存于无物”,直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死。

    解决方式很简单,每次系统 A 从数据库中只要没查到,就写一个空值到缓存里去,比如 set -999 UNKNOWN。然后设置一个过期时间,这样的话,下次有相同的 key 来访问的时候,在缓存失效之前,都可以直接从缓存中取数据。

    缓存击穿

    缓存击穿,就是说某个 key 非常热点,访问非常频繁,处于集中式高并发访问的情况,当这个 key 在失效的瞬间,大量的请求就击穿了缓存,直接请求数据库,就像是在一道屏障上凿开了一个洞。

    解决方式也很简单,可以将热点数据设置为永远不过期;或者基于 redis or zookeeper 实现互斥锁,等待第一个请求构建完缓存之后,再释放锁,进而其它请求才能通过该 key 访问数据。

    问题3:redis 的并发竞争问题是什么?如何解决这个问题?了解 redis 事务的 CAS 方案吗?

    分析

    这个也是线上非常常见的一个问题,就是多客户端同时并发写一个 key,可能本来应该先到的数据后到了,导致数据版本错了;或者是多客户端同时获取一个 key,修改值之后再写回去,只要顺序错了,数据就错了。

    而且 redis 自己就有天然解决这个问题的 CAS 类的乐观锁方案。

    面试题剖析

    某个时刻,多个系统实例都去更新某个 key。可以基于 zookeeper 实现分布式锁。每个系统通过 zookeeper 获取分布式锁,确保同一时间,只能有一个系统实例在操作某个 key,别人都不允许读和写。

    你要写入缓存的数据,都是从 mysql 里查出来的,都得写入 mysql 中,写入 mysql 中的时候必须保存一个时间戳,从 mysql 查出来的时候,时间戳也查出来。

    每次要写之前,先判断一下当前这个 value 的时间戳是否比缓存里的 value 的时间戳要新。如果是的话,那么可以写,否则,就不能用旧的数据覆盖新的数据。

    最后,学习更多的Java干货资料,QQ搜索群号805879199获取~  

    展开全文
  • 问题 项目缓存是如何使用的?为什么要用缓存缓存使用不当会造成什么后果?...这就是看看你对缓存这个东西背后没有思考,如果你就是傻乎乎的瞎用,没法给面试官一个合理的解答,那面试官你印象肯定...

    问题

    项目中缓存是如何使用的?为什么要用缓存?缓存使用不当会造成什么后果?

    分析

    这个问题,互联网公司必问,要是一个人连缓存都不太清楚,那确实比较尴尬。

    只要问到缓存,上来第一个问题,肯定是先问问你项目哪里用了缓存?为啥要用?不用行不行?如果用了以后可能会有什么不良的后果?

    这就是看看你对缓存这个东西背后有没有思考,如果你就是傻乎乎的瞎用,没法给面试官一个合理的解答,那面试官对你印象肯定不太好,觉得你平时思考太少,就知道干活儿。

    面试题剖析

    项目中缓存是如何使用的?

    这个,需要结合自己项目的业务来。

    为什么要用缓存?

    用缓存,主要有两个用途:高性能高并发

    高性能

    假设这么个场景,你有个操作,一个请求过来,吭哧吭哧你各种乱七八糟操作 mysql,半天查出来一个结果,耗时 600ms。但是这个结果可能接下来几个小时都不会变了,或者变了也可以不用立即反馈给用户。那么此时咋办?

    缓存啊,折腾 600ms 查出来的结果,扔缓存里,一个 key 对应一个 value,下次再有人查,别走 mysql 折腾 600ms 了,直接从缓存里,通过一个 key 查出来一个 value,2ms 搞定。性能提升 300 倍。

    就是说对于一些需要复杂操作耗时查出来的结果,且确定后面不怎么变化,但是有很多读请求,那么直接将查询出来的结果放在缓存中,后面直接读缓存就好。

    高并发

    mysql 这么重的数据库,压根儿设计不是让你玩儿高并发的,虽然也可以玩儿,但是天然支持不好。mysql 单机支撑到 2000QPS 也开始容易报警了。

    所以要是你有个系统,高峰期一秒钟过来的请求有 1万,那一个 mysql 单机绝对会死掉。你这个时候就只能上缓存,把很多数据放缓存,别放 mysql。缓存功能简单,说白了就是 key-value 式操作,单机支撑的并发量轻松一秒几万十几万,支撑高并发 so easy。单机承载并发量是 mysql 单机的几十倍。

    缓存是走内存的,内存天然就支撑高并发。

    用了缓存之后会有什么不良后果?

    常见的缓存问题有以下几个:

    1. 缓存与数据库双写不一致
    2. 缓存雪崩、缓存穿透
    3. 缓存并发竞争

    问题1:

    如何保证缓存与数据库的双写一致性?

    分析

    你只要用缓存,就可能会涉及到缓存与数据库双存储双写,你只要是双写,就一定会有数据一致性的问题,那么你如何解决一致性问题?

    面试题剖析

    一般来说,如果允许缓存可以稍微的跟数据库偶尔有不一致的情况,也就是说如果你的系统不是严格要求 “缓存+数据库” 必须保持一致性的话,最好不要做这个方案,即:读请求和写请求串行化,串到一个内存队列里去。

    串行化可以保证一定不会出现不一致的情况,但是它也会导致系统的吞吐量大幅度降低,用比正常情况下多几倍的机器去支撑线上的一个请求。

    Cache Aside Pattern

    最经典的缓存+数据库读写的模式,就是 Cache Aside Pattern。

    • 读的时候,先读缓存,缓存没有的话,就读数据库,然后取出数据后放入缓存,同时返回响应。
    • 更新的时候,先更新数据库,然后再删除缓存

    为什么是删除缓存,而不是更新缓存?

    原因很简单,很多时候,在复杂点的缓存场景,缓存不单单是数据库中直接取出来的值。

    比如可能更新了某个表的一个字段,然后其对应的缓存,是需要查询另外两个表的数据并进行运算,才能计算出缓存最新的值的。

    另外更新缓存的代价有时候是很高的。是不是说,每次修改数据库的时候,都一定要将其对应的缓存更新一份?也许有的场景是这样,但是对于比较复杂的缓存数据计算的场景,就不是这样了。如果你频繁修改一个缓存涉及的多个表,缓存也频繁更新。但是问题在于,这个缓存到底会不会被频繁访问到?

    举个栗子,一个缓存涉及的表的字段,在 1 分钟内就修改了 20 次,或者是 100 次,那么缓存更新 20 次、100 次;但是这个缓存在 1 分钟内只被读取了 1 次,有大量的冷数据。实际上,如果你只是删除缓存的话,那么在 1 分钟内,这个缓存不过就重新计算一次而已,开销大幅度降低。用到缓存才去算缓存。

    其实删除缓存,而不是更新缓存,就是一个 lazy 计算的思想,不要每次都重新做复杂的计算,不管它会不会用到,而是让它到需要被使用的时候再重新计算。像 mybatis,hibernate,都有懒加载思想。查询一个部门,部门带了一个员工的 list,没有必要说每次查询部门,都里面的 1000 个员工的数据也同时查出来啊。80% 的情况,查这个部门,就只是要访问这个部门的信息就可以了。先查部门,同时要访问里面的员工,那么这个时候只有在你要访问里面的员工的时候,才会去数据库里面查询 1000 个员工。

    最初级的缓存不一致问题及解决方案

    问题:先更新数据库,再删除缓存。如果删除缓存失败了,那么会导致数据库中是新数据,缓存中是旧数据,数据就出现了不一致。

    redis-junior-inconsistent

    解决思路:先删除缓存,再更新数据库。如果数据库更新失败了,那么数据库中是旧数据,缓存中是空的,那么数据不会不一致。因为读的时候缓存没有,所以去读了数据库中的旧数据,然后更新到缓存中。

    比较复杂的数据不一致问题分析

    数据发生了变更,先删除了缓存,然后要去修改数据库,此时还没修改。一个请求过来,去读缓存,发现缓存空了,去查询数据库,查到了修改前的旧数据,放到了缓存中。随后数据变更的程序完成了数据库的修改。完了,数据库和缓存中的数据不一样了...

    为什么上亿流量高并发场景下,缓存会出现这个问题?

    只有在对一个数据在并发的进行读写的时候,才可能会出现这种问题。其实如果说你的并发量很低的话,特别是读并发很低,每天访问量就 1 万次,那么很少的情况下,会出现刚才描述的那种不一致的场景。但是问题是,如果每天的是上亿的流量,每秒并发读是几万,每秒只要有数据更新的请求,就可能会出现上述的数据库+缓存不一致的情况

    解决方案如下:

    更新数据的时候,根据数据的唯一标识,将操作路由之后,发送到一个 jvm 内部队列中。读取数据的时候,如果发现数据不在缓存中,那么将重新读取数据+更新缓存的操作,根据唯一标识路由之后,也发送同一个 jvm 内部队列中。

    一个队列对应一个工作线程,每个工作线程串行拿到对应的操作,然后一条一条的执行。这样的话,一个数据变更的操作,先删除缓存,然后再去更新数据库,但是还没完成更新。此时如果一个读请求过来,没有读到缓存,那么可以先将缓存更新的请求发送到队列中,此时会在队列中积压,然后同步等待缓存更新完成。

    这里有一个优化点,一个队列中,其实多个更新缓存请求串在一起是没意义的,因此可以做过滤,如果发现队列中已经有一个更新缓存的请求了,那么就不用再放个更新请求操作进去了,直接等待前面的更新操作请求完成即可。

    待那个队列对应的工作线程完成了上一个操作的数据库的修改之后,才会去执行下一个操作,也就是缓存更新的操作,此时会从数据库中读取最新的值,然后写入缓存中。

    如果请求还在等待时间范围内,不断轮询发现可以取到值了,那么就直接返回;如果请求等待的时间超过一定时长,那么这一次直接从数据库中读取当前的旧值。

    高并发的场景下,该解决方案要注意的问题:

    • 读请求长时阻塞

    由于读请求进行了非常轻度的异步化,所以一定要注意读超时的问题,每个读请求必须在超时时间范围内返回。

    该解决方案,最大的风险点在于说,可能数据更新很频繁,导致队列中积压了大量更新操作在里面,然后读请求会发生大量的超时,最后导致大量的请求直接走数据库。务必通过一些模拟真实的测试,看看更新数据的频率是怎样的。

    另外一点,因为一个队列中,可能会积压针对多个数据项的更新操作,因此需要根据自己的业务情况进行测试,可能需要部署多个服务,每个服务分摊一些数据的更新操作。如果一个内存队列里居然会挤压 100 个商品的库存修改操作,每隔库存修改操作要耗费 10ms 去完成,那么最后一个商品的读请求,可能等待 10 * 100 = 1000ms = 1s 后,才能得到数据,这个时候就导致读请求的长时阻塞

    一定要做根据实际业务系统的运行情况,去进行一些压力测试,和模拟线上环境,去看看最繁忙的时候,内存队列可能会挤压多少更新操作,可能会导致最后一个更新操作对应的读请求,会 hang 多少时间,如果读请求在 200ms 返回,如果你计算过后,哪怕是最繁忙的时候,积压 10 个更新操作,最多等待 200ms,那还可以的。

    如果一个内存队列中可能积压的更新操作特别多,那么你就要加机器,让每个机器上部署的服务实例处理更少的数据,那么每个内存队列中积压的更新操作就会越少。

    其实根据之前的项目经验,一般来说,数据的写频率是很低的,因此实际上正常来说,在队列中积压的更新操作应该是很少的。像这种针对读高并发、读缓存架构的项目,一般来说写请求是非常少的,每秒的 QPS 能到几百就不错了。

    我们来实际粗略测算一下

    如果一秒有 500 的写操作,如果分成 5 个时间片,每 200ms 就 100 个写操作,放到 20 个内存队列中,每个内存队列,可能就积压 5 个写操作。每个写操作性能测试后,一般是在 20ms 左右就完成,那么针对每个内存队列的数据的读请求,也就最多 hang 一会儿,200ms 以内肯定能返回了。

    经过刚才简单的测算,我们知道,单机支撑的写 QPS 在几百是没问题的,如果写 QPS 扩大了 10 倍,那么就扩容机器,扩容 10 倍的机器,每个机器 20 个队列。

    • 读请求并发量过高

    这里还必须做好压力测试,确保恰巧碰上上述情况的时候,还有一个风险,就是突然间大量读请求会在几十毫秒的延时 hang 在服务上,看服务能不能扛的住,需要多少机器才能扛住最大的极限情况的峰值。

    但是因为并不是所有的数据都在同一时间更新,缓存也不会同一时间失效,所以每次可能也就是少数数据的缓存失效了,然后那些数据对应的读请求过来,并发量应该也不会特别大。

    • 多服务实例部署的请求路由

    可能这个服务部署了多个实例,那么必须保证说,执行数据更新操作,以及执行缓存更新操作的请求,都通过 Nginx 服务器路由到相同的服务实例上

    比如说,对同一个商品的读写请求,全部路由到同一台机器上。可以自己去做服务间的按照某个请求参数的 hash 路由,也可以用 Nginx 的 hash 路由功能等等。

    • 热点商品的路由问题,导致请求的倾斜

    万一某个商品的读写请求特别高,全部打到相同的机器的相同的队列里面去了,可能会造成某台机器的压力过大。就是说,因为只有在商品数据更新的时候才会清空缓存,然后才会导致读写并发,所以其实要根据业务系统去看,如果更新频率不是太高的话,这个问题的影响并不是特别大,但是的确可能某些机器的负载会高一些。

    问题2:

    了解什么是 redis 的雪崩、穿透和击穿?redis 崩溃之后会怎么样?系统该如何应对这种情况?如何处理 redis 的穿透?

    分析

    其实这是问到缓存必问的,因为缓存雪崩和穿透,是缓存最大的两个问题,要么不出现,一旦出现就是致命性的问题,所以面试官一定会问你。

    面试题剖析

    缓存雪崩

    对于系统 A,假设每天高峰期每秒 5000 个请求,本来缓存在高峰期可以扛住每秒 4000 个请求,但是缓存机器意外发生了全盘宕机。缓存挂了,此时 1 秒 5000 个请求全部落数据库,数据库必然扛不住,它会报一下警,然后就挂了。此时,如果没有采用什么特别的方案来处理这个故障,DBA 很着急,重启数据库,但是数据库立马又被新的流量给打死了。

    这就是缓存雪崩。

    redis-caching-avalanche

    大约在 3 年前,国内比较知名的一个互联网公司,曾因为缓存事故,导致雪崩,后台系统全部崩溃,事故从当天下午持续到晚上凌晨 3~4 点,公司损失了几千万。

    缓存雪崩的事前事中事后的解决方案如下。

    • 事前:redis 高可用,主从+哨兵,redis cluster,避免全盘崩溃。
    • 事中:本地 ehcache 缓存 + hystrix 限流&降级,避免 MySQL 被打死。
    • 事后:redis 持久化,一旦重启,自动从磁盘上加载数据,快速恢复缓存数据。

    redis-caching-avalanche-solution

    用户发送一个请求,系统 A 收到请求后,先查本地 ehcache 缓存,如果没查到再查 redis。如果 ehcache 和 redis 都没有,再查数据库,将数据库中的结果,写入 ehcache 和 redis 中。

    限流组件,可以设置每秒的请求,有多少能通过组件,剩余的未通过的请求,怎么办?走降级!可以返回一些默认的值,或者友情提示,或者空白的值。

    好处:

    • 数据库绝对不会死,限流组件确保了每秒只有多少个请求能通过。
    • 只要数据库不死,就是说,对用户来说,2/5 的请求都是可以被处理的。
    • 只要有 2/5 的请求可以被处理,就意味着你的系统没死,对用户来说,可能就是点击几次刷不出来页面,但是多点几次,就可以刷出来一次。

    缓存穿透

    对于系统A,假设一秒 5000 个请求,结果其中 4000 个请求是黑客发出的恶意攻击。

    黑客发出的那 4000 个攻击,缓存中查不到,每次你去数据库里查,也查不到。

    举个栗子。数据库 id 是从 1 开始的,结果黑客发过来的请求 id 全部都是负数。这样的话,缓存中不会有,请求每次都“视缓存于无物”,直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死。

    redis-caching-penetration

    解决方式很简单,每次系统 A 从数据库中只要没查到,就写一个空值到缓存里去,比如 set -999 UNKNOWN。然后设置一个过期时间,这样的话,下次有相同的 key 来访问的时候,在缓存失效之前,都可以直接从缓存中取数据。

    缓存击穿

    缓存击穿,就是说某个 key 非常热点,访问非常频繁,处于集中式高并发访问的情况,当这个 key 在失效的瞬间,大量的请求就击穿了缓存,直接请求数据库,就像是在一道屏障上凿开了一个洞。

    解决方式也很简单,可以将热点数据设置为永远不过期;或者基于 redis or zookeeper 实现互斥锁,等待第一个请求构建完缓存之后,再释放锁,进而其它请求才能通过该 key 访问数据。

    问题3:

    redis 的并发竞争问题是什么?如何解决这个问题?了解 redis 事务的 CAS 方案吗?

    分析

    这个也是线上非常常见的一个问题,就是多客户端同时并发写一个 key,可能本来应该先到的数据后到了,导致数据版本错了;或者是多客户端同时获取一个 key,修改值之后再写回去,只要顺序错了,数据就错了。

    而且 redis 自己就有天然解决这个问题的 CAS 类的乐观锁方案。

    面试题剖析

    某个时刻,多个系统实例都去更新某个 key。可以基于 zookeeper 实现分布式锁。每个系统通过 zookeeper 获取分布式锁,确保同一时间,只能有一个系统实例在操作某个 key,别人都不允许读和写。

    zookeeper-distributed-lock

    你要写入缓存的数据,都是从 mysql 里查出来的,都得写入 mysql 中,写入 mysql 中的时候必须保存一个时间戳,从 mysql 查出来的时候,时间戳也查出来。

    每次要写之前,先判断一下当前这个 value 的时间戳是否比缓存里的 value 的时间戳要新。如果是的话,那么可以写,否则,就不能用旧的数据覆盖新的数据。

    转载来源:https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/why-cache.md

    展开全文
  • 【大型电商项目开发】缓存的使用-本地缓存与分布式缓存-整合redis-41

    一:缓存

    1.缓存使用

    1)频繁访问数据库,势必会对数据库造成很大的压力,降低系统性能。所以我们可以把不会经常变化的,或者变化对用户影响不大的数据保存到缓存中。
    2)为了系统性能的提升,我们一般都会将部分数据放入缓存中,加速访问。而 db 承担数据落盘以及持久化的工作。
    3)哪些数据适合放入缓存?

    • 即时性、数据一致性要求不高的
    • 访问量大且更新频率不高的数据(读多,写少)

    4)举例:电商类应用,商品分类,商品列表等适合缓存并加一个失效时间(根据数据更新频率 来定),后台如果发布一个商品,买家需要 5 分钟才能看到新的商品一般还是可以接受的。

    2.读模式缓存使用流程

    1)流程图
    在这里插入图片描述
    2)代码实现

    data = cache.load(id);//从缓存加载数据 
    If(data == null){ 
        data = db.load(id);//从数据库加载数据 
        cache.put(id,data);//保存到 cache 中 
    }
    return data;
    

    3)在开发中,凡是放入缓存中的数据我们都应该指定过期时间,使其可以在系统即使没 有主动更新数据也能自动触发数据加载进缓存的流程。避免业务崩溃导致的数据永久不一致 问题。

    3.本地缓存——map集合

    本地缓存:同一个进程,同一个jvm,在本地保存一个副本。我们可以使用map作为本地缓存,数据以内存的方式进行保存
    1)示例代码

    private Map<String,Object> cache = new HashMap<>();
    //先从缓存中获取数据,如果缓存有,就是用缓存的
    Object data = cache.get("msg");
    if(data == null){
    //首先从数据库获取
    Objetc data = db.get("msg");
    //其次保存到map中
    cache.put("msg",data );
    }
    return data;
    
    • 如果缓存有,就是用缓存的
    • 如果没有,就先从数据库获取,然后保存到缓存中

    2)优点&缺点
    优点:如果项目是单体架构,只部署在一台服务器,不会有任何问题,使用本地缓存效果很好,很快。
    在这里插入图片描述
    缺点:在分布式系统下,一个模块可能部署在若干服务器上,每个服务器都带一个本地缓存,如果不能负载均衡到一个服务器就会导致,访问到不同服务器时,会重新查询数据库。并且修改数据后,不能保证每一个服务器内的缓存一致,会发生数据不一致的情况。

    • 本地缓存
      本地缓存
    • 分布式缓存
      分布式缓存
      结论:所以在分布式的系统下,不要使用本地缓存,推荐将缓存提取出来,作为一个中间件。都集中的给一个地方存放数据,就会保证数据的一致性问题。

    二:SpringBoot整合redis

    1.redis的好处

    1)使用redis作为集群,分片存储,提升存储容量
    2)打破了本地缓存的容量限制
    3)易于维护,容易做到高可用,高性能

    2.整合redis

    1)服务器安装redis
    服务器安装redis传送门
    2)在product的pom文件中引入redis依赖

    <!--引入redis-->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-data-redis</artifactId>
            </dependency>
    

    3)在application.yml文件配置redis

    spring:
      ## 指定redis的地址
      redis:
      ## 虚拟机或者服务器的的ip
        host: 127.0.0.1
        port: 6389
    

    4)使用SpringBoot自动配置好的StringRedisTemplate来操作redis

    • redis主要是K,V结构
    • StringRedisTemplate的k和v都是字符串
    • redis可以当作map来使用,存放数据用key,数据值用value

    5)在test类测试redis

        @Autowired
        private StringRedisTemplate stringRedisTemplate;
        @Test
        public void testStringRedisTemplate(){
            //key-hello  value-word
            ValueOperations<String, String> ops = stringRedisTemplate.opsForValue();
            //保存
            ops.set("hello","word_"+ UUID.randomUUID().toString());
            //查询
            String hello = ops.get("hello");
    

    三:改造三级分类业务-将三级分类信息存入缓存

    1.代码逻辑改造

        @Override
        public Map<String, List<Catalog2Vo>> getCatalogJson() {
            //1.加入缓存逻辑,缓存中存入的数据是json字符串
            String catalogJson = redisTemplate.opsForValue().get("catalogJson");
            if(StringUtils.isEmpty(catalogJson)){
                //2.缓存没有就查询数据库
                Map<String, List<Catalog2Vo>> catalogJsonFromDb = getCatalogJsonFromDb();
                //3.将查到的数据放进缓存,将对象转化为json放进缓存
                String s = JSON.toJSONString(catalogJsonFromDb);
                redisTemplate.opsForValue().set("catalogJson",s);
                return catalogJsonFromDb;
            }
            //转为指定的对象
            TypeReference<Map<String, List<Catalog2Vo>>> typeReference = new TypeReference<Map<String, List<Catalog2Vo>>>() {};
            Map<String, List<Catalog2Vo>> result = JSON.parseObject(catalogJson,typeReference);
            return result;
        }
    
    • JSON跨语言,跨平台的兼容
    • 加入缓存逻辑,缓存中的数据就是json字符串
    • 给缓存中放入json字符串。拿出的json字符串,还要逆转为能用的对象类型(序列化与反序列化)

    2.访问商城首页测试

    在这里插入图片描述
    成功存入redis

    三:压力测试出的内存泄漏与解决

    1.压力测试

    用JMeter模拟高并发下访问三级分类,就会报错!
    在这里插入图片描述

    2.原因分析——堆外内存溢出

    1)springboot2.0版本以后,默认使用lettuce作为操作redis的客户端,他使用netty进行网络通信。
    2)lettuce的bug导致netty对外内存溢出。netty如果没有指定堆外内存,默认使用-Xmx300m
    3)netty底层会统计内存的使用量,使用了多少就会减去多少,直到发生堆外内存溢出

    3.解决方案

    注:不能通过使用-Dio.netty.maxDirectMemory只去调大堆外内存
    1)升级lettuce客户端,使用netty进行网络底层框架,吞吐量极大
    2)切换使用jedis客户端,老版客户端,好久没更新

    4.引入jedis

    <!--引入redis-->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-data-redis</artifactId>
                <exclusions>
                    <exclusion>
                        <groupId>io.lettuce</groupId>
                        <artifactId>lettuce-core</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>
    
            <dependency>
                <groupId>redis.clients</groupId>
                <artifactId>jedis</artifactId>
            </dependency>
    
    • 切换jedis客户端以后,吞吐量提高了四倍,响应时间提高了四倍
    • 上线之后会切换到lettuce,然后定位问题

    5.springRedisTemplate与lettuce,jedis之间的关系

    • lettuce,jedis都是操作redis的底层客户端
    • spring对lettuce,jedis会再次封装为springRedisTemplate
    • springRedisTemplate可以直接操作lettuce和jedis
    展开全文
  • 很多人首先会想从服务器缓存方面着手程序进行优化,许多不同的服务器缓存方式都他们自己的特点,像我曾经参与的一些项目中,根据缓存的命中率不同使用过 Com+/Enterprise Libiary Caching/Windows服务,静态文件等...
  • 什么要使用缓存

    2021-06-24 07:12:18
    有什么好处?使用不当有什么后果? 分析 为什么使用,也就是说要回答出来使用缓存的优缺点就可以了。 项目中的缓存如何使用 这个需要结合自己的业务场景来说,没有的话哪怕硬加一个。 为什么使用缓存 主要是两方面,...
  • 目录 1、多级缓存 (一)集成Caffeine (二)Caffeine驱逐策略 ...分布式缓存一些数据是不适合存放在本地缓存的,比如登录凭证,这个数据和用户直接的关联,如一个请求访问A服务器凭证...
  • Redis:黑马点评项目之商品缓存

    千次阅读 2022-03-26 11:37:32
    但是这种一致性不是我们能控制的,淘汰哪一部分数据,什么时候淘汰,不确定;好处是没有维护成本; 超时剔除:给缓存数据添加过期时间TTL,到期自动删除缓存,下次查询更新缓存;这个一致性的强度取决于时间长短;...
  • 我们为什么使用缓存,是因为缓存可以给我们的 Web 项目带来以下好处,以提高性能和用户体验。 加快了浏览器加载网页的速度; 减少了冗余的数据传输,节省网络流量和带宽; 减少服务器的负担,大大提高了网站的...
  • 浏览器缓存带来的前端项目更新问题及解决方法

    万次阅读 多人点赞 2019-03-10 12:34:44
    先说一个前端开发中会遇到的问题,我们更新已上线的项目,用户的浏览器显示的却是旧版的页面,没有及时获取到我们更新的资源,这是什么原因造成的?此时,如果用户刷新一下页面,就得到更新后的资源,又是为什么? ...
  • redis的优缺点和为什么要用redis做缓存
  • 数据字典的好处很多比如:1、可以减少使用表,来专门记录类型。2、类型使用key检索,或者报表统计分析,在一定程度上相比汉字来讲,效率好得多。3、使用缓存的数据字典、也可以减少不少的io操作。等等、、、、首先,...
  • 缓存优化

    2020-09-23 23:17:02
    1. 1、什么缓存 在计算中,缓存是一个高速数据存储层,其中存储了数据子集,且通常是短暂性存储,这样日后再次请求此数据时,速度要比访问数据的主存储位置快。通过缓存,可以高效地重用之前检索或计算的数据。...
  • java项目缓存技术

    千次阅读 2019-08-27 14:31:19
    一、什么缓存 1、Cache是高速缓冲存储器 一种特殊的存储器子系统,其中复制了频繁使用的数据以利于快速访问 2、凡是位于速度相差较大的两种硬件/软件之间的,用于协调两者数据传输速度差异的结构,均可称之为 ...
  • 微服务-多级缓存

    2022-04-09 23:13:50
    1.什么是多级缓存 传统的缓存策略一般是请求到达Tomcat后,先查询Redis,如果未命中则查询数据库,如图: 存在下面的问题: •请求要经过Tomcat处理,Tomcat的性能成为整个系统的瓶颈 •Redis缓存失效时,会...
  • 项目方案】利用Zookeeper实现集群缓存一致

    多人点赞 热门讨论 2022-07-12 21:01:10
    你知道吗,利用Zookeeper的统一配置管理特性可以解决集群部署下的缓存不一致问题。
  • 一、什么缓存 缓存就是数据交换的缓冲区,是存储数据的临时地方,一般读写性能较高。 缓存的作用: 降低后端负载。当用户进行请求时,先去查询缓存,查询到之后直接返回给用户,而不必查询数据库,大大降低了后端...
  • 在前端性能优化的方式中,最重要的当然是缓存了,使用好了缓存对项目有很大的帮助。比如我们访问网页时,使用网页后退功能,会发现加载的非常快,体验感很好,这就是缓存的力量。 什么缓存呢? 当我们第一次访问...
  • 在WEB开发中用来应付高流量最有效的办法就是用缓存技术,能有效的提高服务器负载性能,用空间换取时间。 缓存一般用来 存储频繁访问的数据 临时存储耗时的计算结果 内存缓存减少磁盘IO 使用缓存的2个主要原因: ...
  • 什么要使用页面缓存技术 一、总结 一句话总结: 系统的瓶颈往往是来自于数据库,我们可以使用缓存来减少数据库的访问! 系统都是逐渐演进的,一个系统在运行中必须是根据场景逐渐地提高优化性能。高并发就是...
  • MyBatis的二级缓存

    千次阅读 2022-02-20 20:26:04
    文章目录MyBatis的二级缓存MyBatis默认是开启一级缓存的开启MyBatis的二级缓存什么要开启二级缓存在mybatis的配置文件中进行配置在对应的mapper映射文件中声明相关的DO对象需要实现序列化测试动态代理接口执行更新...
  • 统一返回Result二、连接测试1.controller2.service3.mapper4.swagger3启动测试三、Redis缓存(*)1.redis缓存策略2.@Cacheable自动缓存3.RedisTemplate手动缓存3.1 Cache注解和缓存逻辑3.2 配置类RedisConfig23.3 ...
  • 1.1什么缓存缓存(Cache)就是复制了频繁使用的数据以利于快速访问。 就是把频繁访问的数据从访问速度慢慢的存储地方A复制一份放到访问速度快的存储地方B,这样每次拿取这个数据时先访问B没有这个数据就...
  • 一、bug起因 最近做公司的项目样式进行了修改后,新版本上线。...其实浏览器缓存有好处的,第一次访问网站会从服务器获取静态的资源,然后将静态资源在游览器中缓存,下次用户在访问时,就直接获取...
  • ajax缓存有好处,但也坏处,缓存有时候会导致误操作,影响用户体验,若你的WEB项目不需要ajax缓存功能,可按下述方法来禁止ajax缓存。 一、在ASP中禁止ajax缓存: ‘放在ASP网页最开头部分  Response.expires=0 ...
  • 静态内容不会带来什么好处。 当响应缓慢时(例如,使用caddy作为慢速后端的代理时),应使用它。 建造 注意:构建需要Go 1.12或更高版本。 要使用它,您需要使用此插件编译自己的caddy版本。 首先获取代码 export ...
  • Vue 中的组件缓存

    万次阅读 2021-07-24 11:24:11
    一、介绍 先来看一个问题? 从首页的区块链模块切换到文章详情页面,再从文章详情页面回到首页,我们发现首页... 主要用于保留组件状态或避免重新渲染,当它包裹动态组件时,会缓存不活动的组件实例,而不是销毁它们

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 111,797
精华内容 44,718
关键字:

缓存对项目有什么好处