被动更新-固定时间过期---放弃了实时一致性
Setnx固定时间+随机时间
主动更新---更新数据库后、直接更新缓存
cache aside
写：先更新数据提供方、再删除缓存、
鸵鸟算法：忽略一些潜在问题、问题出现的概率极低
消息队列的消息重试、防止删除缓存失败、没消费
Read/Write Through
直接写入缓存、从缓存同步到数据发。调用方只和缓存交互
必须写成功：缓存成功、数据方成功------一个事务。TCC实现。慢了。读多写少。写少慢些可接收
初始化：
1、启动缓存、从数据方初始化
2、读取缓存，初始化
缓存预热。缓存没数据，命中率低。
Write Behind
异步写入数据方。加入消息队列。保证最终一致性。
缓存清理机制
缓存有限、清理未来不被访问，保留未来被频繁访问、提高命中率
过去访问多的、最近被更新的、最近被访问的
过期全部清理、要求缓存数据都有一个生存期、有效期
轮询时效清理
自动时效清理、本质还是轮询
数目阀值清理
1、条数 2、大小
FIFO
LRU
Linked-HashMap
实战：
时效性清理+数据阈值
LRU+软引用
#缓存风险点：
缓存穿透---缓存没用、数据提供方也没有---无效调用、增加数据提供方压力、缓存无用
解决方案：缓存中，缓存一份空数据。有key无value
#缓存雪崩
大量缓存突然失效、引发数据提供方压力骤增
解决方案： 数据阈值清理：阈值高可以缓解；过期时间：随机值、错峰失效
软引用清理、LRU进行强引用
#缓存击穿：
缓存没有、数据提供方有数据。没透。
#实战：
清理机制+更新机制，针对缓存，共同考虑
#缓存预热：
缓存服务启动后，脚步直接灌入，init时候加载。
#缓存的位置：
缓存要靠前、要早
前端缓存
cdn缓存
服务器缓存
数据库缓存
读缓存
写的访问量增大：
平峰
降级
灰度发布
#数据设计
数据库选型：
是否海量数据、大数据？
数据结构是行/列存储？
是否宽表（字段数）
数据属性：（业务数据常用的？辅助数据（日志）？）
是否要求事务？
实时性？---写延迟、读延迟要求不一样。写高读低- 写低读高
查询量：大量记录的少数列、少数记录的所有列
一致性要求
增删改查的要求
99%的业务都用结构化数据---关系型数据库、mysql，oraclee，sqlite
非关系型
列式数据库：Hbase
键值对：redis，memcached
文档：mongoDB---不知道有多少个字段
时序：influx DB
搜索：ES
优化数据库集中在 关系型数据库
sql和nosql是互补的关系
存储引擎选择：
支持的字段、数据类型、锁类型、索引、事务
innoDB 不支持hash索引、会转为btree
表结构设计：
先设计关系--->对象
需求->设计数据库->前期考虑很好的扩展性，
先设计对象--->关系
便于理解、快速实施。对象关系改变、结构变化大
数据冗余---允许反范式
CRUD异常：某些数据缺失，导致其他数据无法插入
删除异常：删除数据是，导致其他数据一起丢失
表、字段、索引
优化：索引、历史数据的拆分、分库分表