缓存的更新机制

被动更新-固定时间过期—放弃了实时一致性

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异常：某些数据缺失，导致其他数据无法插入

删除异常：删除数据是，导致其他数据一起丢失

表、字段、索引

优化：索引、历史数据的拆分、分库分表