标签：提高 相关 复杂度 图片 真心 思路 src 访问 访问速度
前台请求，后台先从缓存中取数据，取到直接返回结果，取不到时从数据库中取，数据库取到更新缓存，并返回结果，数据库也没取到，那直接返回空结果。
解决方案3：如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
解决方案4：设置热点数据永远不过期。
解决方案3：接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
解决方案4：从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。 这样可以防止攻击用户反复用同一个id暴力攻击
解决方案2：设置热点数据永远不过期
注--------其实，大多数情况下这种爆款很难对数据库服务器造成压垮性的压力。达到这个级别的公司没有几家的。所以，务实主义的小编，对主打商品都是早早的做好了准备，让缓存永不过期。即便某些商品自己发酵成了爆款，也是直接设为永不过期就好了。
大道至简，mutex key互斥锁真心用不上。
描述：
新的缓存系统没有任何缓存数据，缓存预热就是系统上线后，在缓存重建数据的过程中，系统性能和数据库负载都不太好，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！
解决方案
1、数据量不大，可以在项目启动的时候自动进行加载
2、定时刷新缓存
描述：
缓存热备即当一台缓存服务器不可用时能实时切换到备用缓存服务器，不影响缓存使用。集群模式下，每个主节点都会有一个或多个从节点来当备用，一旦主节点挂点，从节点立即充当主节点使用。
解决方案：
作为一个并发量较大的应用，在使用缓存时有三个目标：
第一，加快用户访问速度，提高用户体验。
第二，降低后端负载，减少潜在的风险，保证系统平稳。
第三，保证数据“尽可能”及时更新。下面将按照这三个维度对上述两种解决方案进行分析。
互斥锁 (mutex key)：
这种方案思路比较简单，但是存在一定的隐患，如果构建缓存过程出现问题或者时间较长，可能会存在死锁和线程池阻塞的风险，但是这种方法能够较好的降低后端存储负载并在一致性上做的比较好。
永远不过期
这种方案由于没有设置真正的过期时间，实际上已经不存在热点 key 产生的一系列危害，但是会存在数据不一致的情况，同时代码复杂度会增大。
标签：提高 相关 复杂度 图片 真心 思路 src 访问 访问速度
原文地址：https://www.cnblogs.com/yuanfang0903/p/11197963.html
