网络公司做网站谷歌推广效果怎么样
1.缓存击穿
缓存击穿指的是某个热点key突然失效，比如说过期了，导致大量请求打到缓存，缓存不存在就去访问数据库，导致数据库压力暴增，甚至崩溃。
2.缓存击穿的解决方法：
缓存预热、缓存永不过期、双重判定锁
2.1缓存预热
指在接收请求前，先将较为热点的缓存从数据库读取到缓存中，这样可以减少数据库的访问压力。如果不进行缓存预热，那么就只能等用户访问缓存，发现缓存没有再去读数据库并回写，这样在高并发场景下可能是致命的。
2.2缓存永不过期
一般而言，高并发的场景实质上是有限的，一般是可以预判的，比如秒杀场景，还有其他的一些活动场景，在可预判的情况下，我们做缓存预热的同时就可以设置缓存不过期，避免缓存过期导致缓存穿透。在活动结束后，再将缓存设为有限存在。
2.3双重判定锁
光做了上述内容还不够，因为高并发情境下，上万个请求发现缓存不存在，此时开始阻塞，等待获取锁并访问数据库进行回写。
但是，第一个线程做了就够了，此时后续的线程就不应该继续访问数据库做回写操作，所以拿到锁后需要回头查看缓存是否已经被回写，如果已经被回写，那么就直接返回。
3.高并发极端情况
有一万个请求同一时间访问触发了缓存击穿，如果用双重判定锁，逻辑是这样的：
1.第一个请求加锁、查询缓存是否存在、查询数据库、放入缓存、解锁，假设我们用了50毫秒；
- 第二个请求拿到锁查询缓存、解锁用了1毫秒；
- 那最后一个请求需要等待10049毫秒后才能返回，用户等待时间过长，极端情况下可能会触发应用的内存溢出。
方案1：直接返回
由于每个线程都需要阻塞等待拿到分布式锁，但是实质上只要有第一个线程拿到锁，就能够完成回写，所以后续的线程访问锁，发现无法访问，就说明已经有线程在进行回写，此时直接抛出异常并返回即可。减少了线程等待时常。但是这样对用户并不友好。
方案2：分布式锁分片
上述矛盾实际上是 检查缓存 和 释放锁 的时常太长 导致的线程等待时间太长，所以我们减少线程等待时常即可，我们将锁分成多个，按照线程对应的全局唯一id hash 后 取模分配锁，假设现在分配十把锁，此时每个锁的压力就减少十倍，那么对应线程的等待时常也减少了十倍。
如果使用双重判定锁，那最后一个请求需要等待10049毫秒后才能返回。
而使用分布式锁分片
十把锁，每把锁线程数量大概为1000，此时每把锁的最后一个线程的只需要1049ms即可返回，速度翻了10倍。
这里有一个疑惑，减少线程阻塞有什么用呢？还不如直接返回报错。
实质上缓存的访问速度大概是0.1ms，所以主要矛盾在阻塞等待，只要阻塞等待的时间缩短了，就缓解了整个流程的读取速度。
伪代码如下：
public String selectTrain(String id， String userId) {// 查询缓存不存在，去数据库查询并放入到缓存String cacheData = cache.get(id);if (StrUtil.isBlank(cacheData)) {// 假设设置10把分布式锁，那么就通过唯一标识（这里取用户ID）进行取模获取分片下标int idx = Math.abs(userId.hashCode()) % 10;// 为避免大量请求同时访问数据库，通过分布式锁减少数据库访问量Lock lock = getLock(id + idx);lock.lock();try {// 获取锁后双重判定cacheData = cache.get(id);// 理论上只有第一个请求加载数据库是有效的，因为它加载后会把数据放到缓存// 后面的请求再请求数据库加载缓存就没有必要了if (StrUtil.isBlank(cacheData)) {// 获取数据库中存在的数据String dbData = trainMapper.selectId(id);if (StrUtil.isNotBlank(dbData)) {// 将查询到的数据放入缓存，下次查询就有数据了cahce.set(id, dbData);cacheData = dbData;}}} finally {lock.unlock();}}return cacheData;
}4.热key问题：
热key场景是指在一个并发请求的环境中，其中一个热点的key被高频访问，影响线程的响应速度。
解决方案：
使用key分片，和上面的锁分片类似，不过此次是将缓存分为多块，每块有自己的key，每个线程根据自身全局唯一id hash 后取模，从而被分配到相同缓存的不同分片上，提升了读写缓存的效率。
假设在一个商品秒杀活动场景下，商品ID123正在被秒杀，所有用户访问同一个key：product:123:info，为了减缓高频请求对这一个key的访问，可以将这个热key分片为100个子key，即product:123:info:shard0 ~ product:123:info:shard99，每条子key的内容都是一致的，无论请求访问哪条key的内容，结果都是相同。
这么做的好处是可以分担请求压力。原本1w请求同一件商品，对一条key的压力是巨大的，但是经过分片之后，每个子key同时只需要承载100个请求，压力大大缓解。
热key分片的方案适用于读多写少的场景，但他的缺点也是明显的，需要同时维护多个子key，如果更新就要写所有子key。