早期数据库有三种：层次式数据库、网络型数据库、关系型数据库。
目前常见关系型数据库和非关系型数据库。
根据数据库存储体系分：
关系型数据库：把复杂数据结构归为二元关系；
键值（Key-Value）数据库：非关系型数据库，键为唯一标识；
列存储数据库：column-Based；
文档型数据库：可以是XML、JSON、BSON格式，呈树状结构，可视为值可查的键值数据库；
搜索引擎数据库
文件系统的缺点：数据冗余（Data Redundancy）、数据不一致性（Data Inconsistency）、数据孤立（Data Isolation）
NoSql数据库：列式存储数据库、键值对存储数据库、文档型数据库、图数据库
NoSql体系框架分为4层，数据持久层（Data Persistence）、数据分布层（Data Distribution Model）、数据逻辑模型层（Data Logic Model）、接口层（接口层提供5种选择Rest\Thrift\Map/Reduce\Get/Put\特定语言API）
关系型数据库
基本术语：
主码，主键，可以唯一确定实体
候选码，关系中的某一属性或属性组的值能唯一标识一个元组
主属性，包含在任何候选码的属性
关系运算符：
自然连接（列名去重复相加，数据要选出相同）
笛卡尔积（列名相加，数据相乘）
数据库设计基本步骤：
（1）需求分析 - 数据流图、数据字典、需求说明书
（2）概念结构设计 - ER图
属性冲突、命名冲突、结构冲突
（3）逻辑结构设计 - 关系表
（4）物理设计
（5）数据库实施阶段
（6）数据库运行和维护阶段
数据模型：概念模型 - 现实世界到信息世界的第一抽象，其实就是ER图
关系模型 - 二维表的形式表示实体联系模型
网状模型
面向对象模型
数据模型三要素：数据结构（所研究对象的集合）、数据操作、数据的约束条件（一组完整性规则的集合）
分布式数据库
分布式数据库系统（Distributed DataBase System）
数据库系统结构：三级模式两级映像
外模式-以视图形式呈现
概念模式 - 以表形式呈现
内模式 - 以文件形式呈现
通过二级映像体现了逻辑和物理的两个层面的数据独立性（逻辑独立性，物理独立性）
函数依赖
范式（就是描述如何将ER图转换为关系模型）规范操作
1NF：要求数据表中的所有字段都是不可分割的原子值。
2NF：在1NF基础上，要求数据表中每个非主属性完全依赖于某一个候选键。（不能存在联合主键 ）
3NF：在2NF基础上，要求每个非主属性不依赖于其他非主属性。（不能存在传递依赖 ）
BCNF：在3NF基础上，避免数据冗余和不一致性。（出现更新（增删改）异常）
注：只有出度没有入度就是候选键
反规范化技术：牺牲部分规范化提高性能
反规范化技术带来问题：为了保障数据一致性，增加了数据维护的复杂度，会降低修改速度
反规范化技术方法：增加冗余列、增加派生列、重新组表、水平分割表、垂直分割表
模式分解（规范化操作的概念）：通过对关系模式进行拆分，消除模式中混合组合依赖，分解为更小模式的过程。
是否保持函数依赖分解
有损无损分解
事务：由一系列DML（数据操作语言，如增删改查）操作组成，这些操作要么全做要么全不做，它从第一个DML开始，rollback或commit或DDL（数据库定义语言，表结构操作）结束。
事务四特性：原子性A tomicity、一致性C onsistency、隔离性I solation、持续性D urability。
事务的隔离性引发安全问题 - > 并发控制，控制不同事务并发执行提高效率
x锁 排它锁 写锁（加写锁后任何锁都不能再加）
S锁 共享锁 读锁 （加读锁后只能再加读锁）
一级封锁协议：加写锁 解决丢失更新问题
二级封锁协议：写加写锁，读加读锁 解决丢失更新、不可重读问题
三级封锁协议：先加读锁，再加写锁 解决丢失更新、不可重读、读脏数据问题
Redis(Remote Dictionary Server) 基于Key-Value结构的NoSql内存数据库
工作流程：
部署方式：
主从模式（主从复制）- 实现了读写分离（主写从读）和数据冗余备份，但存在主节点单点故障风险。当主节点宕机时，需要人工介入或者配合哨兵模式实现自动故障转移。
哨兵模式
Cluster集群模式
核心机制采用哈希槽机制
常见缓存问题：
1.缓存穿透 - 恶意请求大量不存在key,缓存未命中后所有请求直达数据库，导致数据库压力激增或崩溃。
解决方案
a.缓存空对象 对不存在的key缓存空值，设置短期过期时间
b.引入布隆过滤器进行拦截
2.缓存击穿 - 单个key过期瞬间，大量并发请求直达数据库，造成数据库单点压力。
解决方案
a.热点key设置永久有效（persist命令），通过主动更新保证数据新鲜
b.分布式锁（setnx）,保证同一时间只有一个请求更新缓存，其余请求等待
c.热点数据预热（提前将热点key加载到缓存）
3.缓存雪崩 - 大量key在同一时间过期，导致大量请求直达数据库，引发数据库雪崩
解决方案
a.过期时间随机化（给每个key的过期时间增加随机偏移量）
b.redis集群部署（提升缓存服务可用性，避免单节点故障）
c.多级缓存（本地缓存+redis缓存）降低redis依赖
d.数据库限流、熔断（Sentinel），保护数据库不被压垮
如何保证redis和mysql数据一致性
1.先更新MySql再更新redis
2.延迟双删