企业网站有百度权重说明,如何制作企业网站,营销平台建设,如何买域名因为csdn只支持这种文档形式#xff1a;不支持思维导图#xff1a;
更好友好的阅读#xff1a;可以看我的飞书--------思维导图#xff08;这样食用更加#xff09;#xff1a; 缓存穿透问题原因每次从缓存中都查不到数据#xff0c;而需要查询数据库#xff0c;同时数…因为csdn只支持这种文档形式不支持思维导图
更好友好的阅读可以看我的飞书--------思维导图这样食用更加 缓存穿透问题原因每次从缓存中都查不到数据而需要查询数据库同时数据库中也没有查到该数据也没法放入缓存如何解决布隆过滤器原理布隆过滤器可以用于检索一个元素是否在一个集合中。结构概率型数据结构使用方式一通过自己写算法实现布隆过滤器方式二使用网上存在的开源包推荐指数⭐⭐⭐(这个技术有些过时了但是可以用)优点算法简单可以自己配置缺点存在一定的误判率不支持删除操作查找性能比布谷鸟底空间利用率低布谷鸟过滤器要求条件适用于对误判率要求较高的场景。如网络路由、存储系统等原理最简单的布谷鸟哈希结构是一维数组结构会有两个 hash 算法将新来的元素映射到数组的两个位置。如果两个位置中有一个位置为空那么就可以将元素直接放进去。但是如果这两个位置都满了它就不得不「鸠占鹊巢」随机踢走一个然后自己霸占了这个位置。近似集合数据结构如何使用方式一自己写一个算法我试过比较复杂方式二调用别人写的库情况优点相较于布隆过滤器具有更低的误判率支持删除操作查找性能高空间利用率高缺点删除不完美存在误删的概率。删除的时候只是删除了一份指纹副本并不能确定此指纹副本是要删除的key的指纹。同时这个问题也导致了假阳性的情况。插入复杂度比较高随着插入元素的增多复杂度会越来越高因为存在桶满踢出的操作所以需要重新计算但综合来讲复杂度还是常数级别。存储空间的大小必须为2的指数让空间效率打了折扣同一个元素最多插入kb次k指哈希函数的个数b指的桶中能装指纹的个数如果布谷鸟过滤器支持删除则必须存储同一项的多个副本。 插入同一项kb1次将导致插入失败。 这类似于计数布隆过滤器其中重复插入会导致计数器溢出。推荐指数⭐⭐⭐⭐⭐绝对好用缓存空对象方案一要求条件适中推荐指数⭐⭐⭐⭐很常见的方式设置缓存的时候同时设置一个过期时间这样过期之后就会重新去数据库查询最新的数据并缓存起来方案二要求条件实时性要求非常高推荐指数⭐⭐⭐要结合实际情况考虑双写一致性的问题如果对的话那就写数据库的时候同时写缓存。这样可以保障实时性方案三要求条件实时性要求不是那么高推荐指数⭐⭐⭐⭐非常实用的方式那就写数据库的时候给消息队列发一条数据让消息队列再通知处理缓存的逻辑去数据库取出最新的数据校验参数原理我们可以对用户id做检验。请求合法性校验比如权限管理推荐指数⭐⭐⭐⭐⭐这个必须做缓存击穿问题原因缓存击穿问题是由于key过期了导致的如何解决加锁原理在缓存失效的瞬间通过加锁机制来保证只有一个请求能够访问数据库其他请求等待获取缓存数据。使用同一时刻只有一个请求才能访问某个信息并且另一个线程将数据库中查询到的结果又重新放入缓存中推荐指数⭐⭐⭐非必要不加锁自动续期原理在key快要过期之前就自动给它续期推荐指数⭐⭐⭐本来要过期但是续期的指令如何识别缓存不失效原理对于很多热门key其实是可以不用设置过期时间让其永久有效的。推荐指数⭐⭐⭐⭐正对某些业务可以设置缓存雪崩
原因有多个热门key同时失效非常严重归根结底都是有大量的请求透过缓存而直接访问数据库了有大量的热门缓存同时失效。会导致大量的请求访问数据库。而数据库很有可能因为扛不住压力而直接挂掉。缓存服务器宕机了可能是机器硬件问题或者机房网络问题。总之造成了整个缓存的不可用。解决办法过期时间加随机数推荐指数⭐⭐⭐⭐较为安全要求不要设置相同的过期时间即使在高并发的情况下多个请求同时设置过期时间由于有随机数的存在也不会出现太多相同的过期key高可用分布式部署推荐指数⭐⭐⭐⭐能在源头处理最好深层原因针对缓存服务器宕机的情况原理通过多个节点来分担缓存的压力提高系统的容灾性解决办法在前期做系统设计时可以做一些高可用架构redis可以使用哨兵模式或者集群模式避免出现单节点故障导致整个redis服务不可用的情况服务降级备份机制推荐指数⭐⭐⭐⭐做一个数据兜底更深的原因做了高可用架构redis服务还是挂了该怎么办呢解决办法配置一些默认的兜底数据。程序中有个全局开关比如有10个请求在最近一分钟内从redis中获取数据失败则全局开关打开。就直接从配置中心中获取默认的数据。还需要有个线程每隔一定时间去从redis中获取数据数据预热原理数据预热就是系统上线后将相关的缓存数据直接加载到缓存系统这样就可以避免在用户请求的时候先查询数据库方式在系统低峰期提前对热点数据进行加载和缓存避免大量数据同时失效推荐指数⭐⭐⭐⭐不要等高峰了做预案双层缓存策略C1为原始缓存C2为拷贝缓存C1失效时可以访问C2C1缓存失效时间设置为短期C2缓存失效时间设置为长期推荐指数⭐⭐⭐万一都宕机就完蛋了定时更新缓存策略原理失效性要求不高的缓存容器启动初始化加载采用定时任务更新或移除缓存使用另起一个线程去做任务处理推荐指数⭐⭐⭐⭐⭐前期预防永远比后期解决来的好双写一致性redis与mysql
原因分布式常见问题数据库和缓存双写就必然会存在不一致的问题最终一致性要保证数据库与缓存可以先后一致强一致性有强一致性要求的数据不能放缓存解决方法更新缓存先写缓存写数据库问题程度上上很严重问题原因刚写完缓存突然网络出现了异常导致写数据库失败了推荐指数⭐⭐用的不多造成影响容易诞生假数据先写数据库在写缓存问题情况写缓存失败了问题程度上 严重问题原因写数据库和写缓存都属于远程操作。通常建议写数据库和写缓存不要放在同一个事务中写数据库成功了但写缓存失败了数据库中已写入的数据不会回滚推荐指数⭐⭐ ⭐接口性能要求不太高的系统造成影响数据库是新数据而缓存是旧数据两边数据不一致的情况问题情况高并发先写数据库在写缓存问题程度上上 很严重问题原因请求b在缓存中的新数据被请求a的旧数据覆盖了。请求互相覆盖推荐指数⭐⭐高并发场景不适合造成影响可能会出现数据库是新值而缓存中是旧值两边数据不一致的情况问题情况浪费系统资源问题程度上严重问题原因每写一次缓存都需要经过一次非常复杂的计算推荐指数⭐⭐计算要求低的情况造成影响浪费cpu和内存资源删除缓存先删缓存在写数据库高并发下单删问题程度中上适度问题原因请求A删除完缓存数据Data后网络卡顿写入数据库操作暂停。请求B读数据Data缓存中没有去数据库读读的是旧数据。请求A网络好了写入新数据到数据库推荐指数⭐⭐⭐低并发下造成影响请求A的新值并没有被请求B写入缓存同样会导致缓存和数据库的数据不一致的情况高并发下缓存双删问题程度中下 良好问题原因写数据库之前删除缓存一次写完数据库后再删除缓存一次推荐指数⭐⭐⭐⭐看情况推荐使用使用要点第二次删除缓存并非立马就删而是要在一定的时间间隔之后。原因在另一个请求未生效前删除这就没有意义了造成影响第二次删除可能失败解决办法重试机制原理更新了数据库成功了但更新缓存失败了可以立刻重试N次。如果其中有任何一次成功则直接返回成功。如果N次都失败了则写入数据库准备后续再处理。同步重试推荐指数⭐⭐⭐原因接口并发量比较高的时候可能有点影响接口性能异步重试推荐指数⭐⭐⭐⭐⭐方式一每次都单独起一个线程该线程专门做重试的工作推荐指数⭐⭐⭐原因在高并发的场景下可能会创建太多的线程导致系统OOM问题方式二将重试的任务交给线程池处理推荐指数⭐⭐⭐⭐原因如果服务器重启部分数据可能会丢失方式三将重试数据写表存入数据库定时任务推荐指数⭐⭐⭐⭐不适合实时性要求特别高的业务场景使用定时任务进行重试重试表至少得有一下字段重试次数字段是否成功的状态字段原理设置初始值每次删除重试次数字段加1只要任意有一次成功就返回成功同时修改状态等待后续进一步处理缺点实时性没那么高优点数据是落库的不会丢数据方式四将重试的请求写入mq等消息中间件推荐指数⭐⭐⭐⭐⭐实时性还是比较高的使用mq的consumer中处理原理操作写完数据库但删除缓存失败了产生一条mq消息发送给mq服务器mq消费者读取mq消息如果其中有任意一次成功了则返回成功。重试N此后还是失败写入死信队列中后续需要人工处理优点mq的实时性还是比较高的优化删除缓存可以完全走异步。即用户的写操作在写完数据库之后不用立刻删除一次缓存。而直接发送mq消息到mq服务器然后有mq消费者全权负责删除缓存的任务。方式五订阅mysql的binlog推荐指数⭐⭐⭐⭐⭐强烈推荐原理订阅者中如果发现了更新数据请求则删除相应的缓存监听binlog使用canal等中间件实现原理业务接口中写数据库之后就不管了直接返回成功mysql服务器会自动把变更的数据写入binlog中binlog订阅者获取变更的数据然后删除缓存问题也会删除失败解决办法重试机制推荐使用方式三和方式四当推荐方式四先写数据库再删缓存问题程度下上 优秀问题原因缓存过期失效请求A查询数据发现缓存没有去数据库查询但是网络原因没有及时更新缓存。请求B先写数据库然后删除缓存。请求A恢复更新缓存。诞生条件同时满足概率小缓存刚好自动失效请求A查询数据库旧值以及更新缓存数据的时间比请求B写入数据库以及删除缓存数据的时间长一般数据库查询比数据库写入时间短那种复合聚合查询就不好说了推荐指数⭐⭐⭐⭐⭐ (推荐使用)使用指南请求查询不要太过复杂造成影响最差的情况就是读取到旧数据问题不算太大刷新一下重新请求数据就对了删除可能失效解决办法重试机制原理更新了数据库成功了但更新缓存失败了可以立刻重试N次。如果其中有任何一次成功则直接返回成功。如果N次都失败了则写入数据库准备后续再处理。同步重试推荐指数⭐⭐⭐适合低并发原因接口并发量比较高的时候可能有点影响接口性能异步重试推荐指数⭐⭐⭐⭐⭐常见操作方式一每次都单独起一个线程该线程专门做重试的工作推荐指数⭐⭐⭐原因在高并发的场景下可能会创建太多的线程导致系统OOM问题方式二将重试的任务交给线程池处理推荐指数⭐⭐⭐⭐原因如果服务器重启部分数据可能会丢失方式三将重试数据写表存入数据库定时任务推荐指数⭐⭐⭐⭐不适合实时性要求特别高的业务场景使用定时任务进行重试重试表至少得有一下字段重试次数字段是否成功的状态字段原理设置初始值每次删除重试次数字段加1只要任意有一次成功就返回成功同时修改状态等待后续进一步处理缺点实时性没那么高优点数据是落库的不会丢数据方式四将重试的请求写入mq等消息中间件推荐指数⭐⭐⭐⭐⭐实时性还是比较高的使用mq的consumer中处理原理操作写完数据库但删除缓存失败了产生一条mq消息发送给mq服务器mq消费者读取mq消息如果其中有任意一次成功了则返回成功。重试N此后还是失败写入死信队列中后续需要人工处理优点mq的实时性还是比较高的优化删除缓存可以完全走异步。即用户的写操作在写完数据库之后不用立刻删除一次缓存。而直接发送mq消息到mq服务器然后有mq消费者全权负责删除缓存的任务。方式五订阅mysql的binlog推荐指数⭐⭐⭐⭐⭐强烈推荐原理订阅者中如果发现了更新数据请求则删除相应的缓存监听binlog使用canal等中间件实现原理业务接口中写数据库之后就不管了直接返回成功mysql服务器会自动把变更的数据写入binlog中binlog订阅者获取变更的数据然后删除缓存问题也会删除失败解决办法重试机制推荐使用方式三和方式四当推荐方式四缓存的并发竞争
原因多个redis的client同时set key引起的并发问题多客户端同时并发写一个key一个key的值是1本来按顺序修改为2,3,4最后是4但是顺序变成了4,3,2最后变成了2。解决方案乐观锁推荐指数⭐⭐⭐乐观锁适用于大家一起抢着改同一个key使用watch 命令可以方便的实现乐观锁缺点如果 redis 使用了数据分片的方式那么这个方法就不适用了什么是数据分片原理Redis的分片机制允许数据拆分存放在不同的Redis实例上每个Redis实例只包含所有键的子集优点可以减轻单台Redis的压力提升Redis扩展能力和计算能力分布式锁时间戳原理加锁的目的实际上就是把并行读写改成串行读写的方式从而来避免资源竞争用一个状态值表示锁对锁的占用和释放通过状态值来标识加锁使用方法使用使用redis中setnx()函数返回1则客户端获得锁把锁的键值设置为时间值表示该键已经被锁定可以通过DEL lock.foo来释放该锁返回 0 则表明该锁已经被其他客户端取得这时返回重试等待对方完成或者等待锁超时在或者返回推荐指数⭐⭐⭐⭐适合分布式环境优点不用关心 redis 是否为分片集群模式时间戳使用适合有序场景原理系统B先抢到锁将key1设置为{ValueB 7:05}。接下来系统A抢到锁发现自己的key1的时间戳早于缓存中的时间戳7:007:05那就不做set操作了推荐指数⭐⭐⭐适合对于有序情况优点业务处理有序消息队列原理把Redis.set操作放在队列中使其串行化及一个一个执行较为通用的解决方案推荐指数⭐⭐⭐⭐高并发场景中优点串行化
