Cache
若从数据库查询（复杂查询、跨表跨库查询）一个数据比较耗时，而且数据在短时间内不会变，那么可以把查询结果做缓存。
由于缓存是内存，所以性能大大由于数据库。
Cache Aside Pattern：
- 读，先读缓存，再读数据库。
- 更新，先删除缓存，再更新数据库。选择删除而不是跟新缓存的原因：很多时候是经过复杂查询、计算后的结果，更新的话成本太大。其实使用的是 lazy 的思想。
场景：先修改数据库，再删除缓存，如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据出现不一致。
解决方案：先删除缓存，再修改数据库。
场景：先删除缓存，然后去修改数据库，此时还没修改完成，一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中，此时数据变更的程序完成了数据库的修改。
解决方案：
缓存挂了，所有请求瞬时全部到数据库，导致数据库宕机。
解决方案：
- 保证缓存高可用。
- 系统内缓存，比如 ehcache。
- 在请求数据库层做限流+降级。比如 Hystrix。
- 缓存持久化，可以尽快恢复缓存。
由于不正确的请求（比如黑客攻击），所有的请求都命中不到缓存，导致全部请求到数据库。比如数据库中 id 为 1 -100，发出请求 id 为 -1。
可以把数据库查不到的数据写一个空值到缓存里面去。
场景：多个服务同时对缓存中的某个 key 做更新，没有按照期望的顺序执行，所以最终的缓存数据不正确。
解决方案：分布式锁+时间戳。
Last modified 3yr ago