高并发问题，也就是怎么做缓存的问题，以商品详情页为例。
数据库读写分离能只能做到10000左右的QPS已经接近极限，要想要更高的QPS需要缓存。
以商品详情页为例
小公司：所有页面也就10000个左右，直接全部静态化放在nginx上。
大公司：某些数据变了只用改几个页面，但在模板本身变化格式的时候要渲染的页面太多。
使用nginx redis echache多级缓存方案。
以大公司方案为细分讨论。
首先，不再使用静态化页面的方案。
所有页面都使用数据动态渲染，然后对两部分数据分开处理。
高实时性的数据，仅使用Redis缓存，并保证数据库Redis双写一致。
低实时性的数据，用一个单独的缓存生成服务，通过mq接收到数据修改消息后。
异步将数据生成并写入到nginx redis echache多级缓存中。
多级缓存的访问顺序是，优先nginx 其次redis，echache相当于备份，用来做后面说的服务降级。
缓存命中率问题
nginx本地存放数据，但如果nginx是被随机访问的，会有缓存命中率问题。
例如也就是你有10个数据，两个nginx分别放5个。
但是每个nginx都可能被访问10个数据，如果访问到不存在的数据，就要到Redis去取了。
显然纯随机的访问导致的是nginx不可接受，很多时候也不可能每个nginx都放所有数据。
方案是采用两层nginx，第一层接入，然后根据例如产品id来做hash。
确保相同的id永远会走到固定的nginx上即可。
并发构建冲突
你的异步缓存构建服务很可能并非一直一个服务而是多个服务。
那么在缓存构建缓存时候需要使用分布式锁来解决对同一个数据的并发更新。
记得带上能判断数据版本的标识，可以是时间。
大value
nginx和redis上的数据，要做维度化拆分，不能说一个产品信息所有都堆在某个结构上。
说白了就是像数据库那样，少量多次，降低Redis延迟。
缓存预热或者说缓存冷启动问题
一开始缓存里还没有数据的时候，数据库很可能被高并发打死。
导致缓存还没来得及构建，系统就崩溃，系统永远起不来。
一方面要做限流。
另一方面，需要有一个实时计算平台，比如storm，能够实时统计出热数据。
启动时候提前将这些热数据写入缓存。
热点数据
和一般的热数据不同，热点数据指的是某个局部时间突然变热的数据。
方案是根据storm平台的统计，发现热点数据后，单独做一套系统。
这个系统负责，将热数据立马写入所有nginx，并临时修改分发层nginx的策略。
将之前的根据id分法，转为如果是热点数据，随机分法，让nginx均摊压力。
事后LRU会自动淘汰这些数据。nginx同时将规则调整回来。
缓存穿透
可能是恶意的攻击也有可能系统自身造成，查询一些不在缓存，甚至不在数据库的数据。
第一层布隆过滤器确保数据是在有效范围内，比如针对id做过滤。
第二层将合理的但确实不存在的数据，依然根据id为key放入缓存。
这样一是不会为数据库添加负担，第二是以后这个id有数据了，依然能够更新上去。
缓存雪崩
通常指Redis集群全面崩溃。这很容易造成系统直接瘫痪。
三个层面
事前：做好集群本身的高可用，Redis集群最好双机房部署。
事中：做好服务降级，也就是服务间的高可用，不然某个服务拖垮整个应用，
同时降级通常是限流访问数据，并用echache做临时缓存继续服务。
这样客户感觉是刷10次出2次，而不是网站完全崩溃。
事后：用之前备份的rdb或者aof文件，恢复Redis，并预热后，再进行服务。
网友评论