缓存
经典的缓存架构
可以支持百万流量的三级缓存
cache aside pattern
- 读数据的时候，先读缓存，缓存没有的话，就读数据库，放入缓存，返回响应
- 写数据的时候，先删除缓存，再更新数据库
为什么是删除缓存，而不是更新缓存那？
原因很简单，试想这么场景，数据频繁的被修改，那么缓存就也要不断的重新计算，这个计算是非常消耗资源的，而且你更新了这么多次缓存还不一定能用到，就有点得不偿失了，所以就有了先删除缓存，再更新数据的做法，这样就是减少了非常多次的缓存重新计算的工作量，而是用到了数据的时候，再从数据库中加载到缓存中
数据库和缓存双写问题
初级
先写数据库，后写缓存，如果写缓存失败，就会出现数据库和缓存不一致的情况
解决方案：很简单，写数据的时候，先删除缓存，再更新数据库就可以了
其实就是从两个操作失败的场景来分析就会明白了
- 删除缓存失败，那么就会再次执行删除缓存的操作，可以自定义重试几次，删除换缓存失败的情况，缓存和数据库数据一直，删除缓存成功，会以数据库数据为主，将相应数据写入数据库，等到再次请求缓存，用到这个数据的时候，再将数据放入到缓存中
- 更新数据库失败，更新数据库失败就会回滚，此时缓存中没有数据，以数据库的数据为主，无非就是多次重试执行sql，直到成功或者说规定重试几次，返回更新数据失败的提示
进阶
看完上面的解释，你是不是以为使用了先删除缓存，再写数据库的方式就可以避免数据库和缓存数据不一致的情况，我在这里告诉你，不是的！
有一种场景，在一个线程删除缓存成功，准备将数据写数据库的时候，此时另外一个线程来请求这个数据，发现缓存中没有，直接去请求数据库，将数据库的数据读入到了缓存中，然后第一个线程才将数据写入数据库，此时缓存和数据库的数据出现了不一致的情况，数据库中是最新的数据，而缓存中是原来的数据。你以为已经给它删除了，但是如果一个线程出现上述这场景，就和没有删除的情况一样，仍然出现了缓存和数据库数据不一致的问题
解决方案：
数据库与缓存更新与读取操作进行异步串行化
更新数据的时候，根据数据的唯一标识，将操作路由之后，发送一个jvm内部的队列中
读取数据的时候，如果发现数据不在缓存中，那么将重新拉取数据+更新缓存的造作，根据唯一标识路由之后，也发送同一个jvm内部的队列中
一个队列对应一个工作线程
每个工作线程串行拿到对应的操作，然后一条一条的执行选择的话，一个数据变更的操作，先执行，删除缓存，然后再去更新数据库，但是还米有完成更新
此时如果一个读请求过来，读到了空的缓存，那么可以优先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成
这有有一个优化的点，一个队列中，其实多个更新缓存请求串在一个是没有意义的，因此可以做过滤，如果发现队列中已经有一个更新缓存的队列了，那么就不用再放一个更新的操作了，直接等待前面的更新操作完成
待那个队列对应的工作线程完成了上一个操作的数据的数据库的修改之后，才会去执行下一个操作，此时会从数据库获取最新的值，然后写入缓存，如果请求还在等待时间范围，不断轮询可以发现可以直接取到值了，那么直接返回；如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取当前的值
注意
在进阶中的方案仍然有有一些问题需要实际考虑
由于读请求进行了非常轻度的异步化，所以一定要注意超时时间的问题，每个读请求必须在超时时间内返回
该解决方案最大的风险点在于，可能数据更新很频繁，导致队列中积压了大量更新操作在里面，然后读请求会发生大量的超时，最后导致大量的请求直接走数据库
务必通过一些模拟真实的测试，看看更新数据的频繁是怎样的
另外一点，因为在 一个队列中，可能会积压针对多个数据项的更新操作，因此要根据自己的业务情况进行测试，可能需要部署多个服务，每个服务分摊一些数据更新的操作，如果一个内存队列里居然会积压100个商品的库存修改操作，每个库存修改都要豪飞10ms完成，那么最后一个商品的去请求，可能要等待1s，这个时候就导致读请求长时间的阻塞
一定要根据实际业务系统的运行情况，去做一些压力测试，和模拟线上环境，去看看罪犯满给的时候，内存队列可能会挤压多少更新操作，如果读请求在200ms内返回，那还是可以接受的
如果一个内存队列中可挤压的更新操作特别多，那么你就要加机器，让每个机器上部署的服务实例处理更少的机器，那么就会提高读请求的响应时间
其实根据之前的项目经验，一般数据的写频率都是很低的，因此实际上正常来说，在队列中积压的更新操作应该是很少的
多实例部署的请求路由
可能这个服务部署了多个实例，那么必须保证说，执行数据更新操作，以及执行缓存更新操作的请求，都通过nginx服务器路由到相同的服务实例上
热点商品问题，导致请求的倾斜
对某一个商品的请求特别高，全部请求到相同机器的相同的队列去了，可能会造成某台机器压力过大
缓存雪崩
缓存雪崩这种场景，在缓存架构中是非常重要的一个环节，应对缓存雪崩的解决方案，避免缓存雪崩的时候，造成整个系统崩溃，带来巨大的经济损失
- redis集群彻底崩溃
- 缓存服务大龄对redis的请求hang主，占用资源
- 缓存服务大量的骑牛打到源头服务去查mysql，直接打死mysql
- 源头服务因为mysql被打死也崩溃，对原服务的请求也hang主，占用资源
- 缓存服务大量的资源全部耗费访问redis和源服务无果，最后自己被拖死，无法提供服务
- ng无法访问缓存服务，redis和源服务，只能基于本地缓存提供服务，但是缓存过期后，没有数据提供
- 网站崩溃
事前
redis本身的高可用性，主从架构
建议双机房部署，可以是一套redis cluster，不同机器的，也可以是不同的redis cluster，两套redis cluster之间做一个数据同步，redis集群是可以搭建成树状结构的
事中
ehcache本地缓存
主要是为了应对redis中的数据被清除的现象和预防redis彻底崩溃
多台机器上部署的缓存服务实例的内存中，还有要ehcache的缓存
ehcache还能支撑一阵子
对redis访问的资源隔离
目的：为了避免所有资源hang在redis上
对redis cluster访问失败的情况，做下熔断策略
什么时候判断redis死了，就自动给他熔断，部署redis cluster的降级策略
降级机制: fallback
fail silent模式，failback里面直接返回一个空值，比如一个null，最简单了
对源服务访问的限流以及资源隔离
资源隔离：限制访问商品服务的资源，避免商品故障的时候，所有资源都在访问该商品
目的：为了源头服务在mysql死掉的情况下，可以存活一阵
事后
redis做了备份
redis数据做了备份，直接根据redis的持久化策略来恢复数据
快速缓存预约
缓存穿透
其实很简单，就是你查询的数据，多级缓存中都没有，大量的数据都直接走到了数据库，容易导致数据库崩溃