这里写目录标题
单机存储系统介绍
- 什么是存储引擎
存储引擎：存储系统的发动机，提供数据的增删改查能力，直接决定存储系统的功能和性能
性能因素： - 写入方式
顺序写
随机写 - 读取方式
随机读
顺序扫描
单机存储引擎
- hash存储引擎
（1）时间复杂度0（1）
（2）满足"="，"IN"查询
(3) 不支持范围查询
（4）不支持排序
有redis、memcached - b树存储引擎
b+树存储引擎特性
（1）根节点常驻内存，最多h-1次磁盘io
（2）非页字节点容纳尽量多的元素
（3）擅长范围查询
（4）随机写问题
（5）节点分裂
有mysql - lsm存储引擎
（1）随机变顺序写
（2）牺牲读性能
（3）增加后台合并开销
有布隆过滤器快速判断，文件内数据有序
存储模型
数据模型是存储模型外壳，描述存储系统以什么样的形式存储或管理数据
- 关系数据
- 键值数据
- 时序
- 图
redis原理分析
redis是用c语言开发的一个开源的高性能键值对（key-value）内存数据库
-
数据储存原理
（1）redisdb
（2）dict
（3）dictht
（4）dictentry
（5）key对存储效率的影响
（6）内存清理
（6.1）定期删除，惰性删除，lru，lfu -
数据固化方式
rdb快照方式
（1）手动方式
（2）自动方式
优点：对redis性能影响低，二进制压缩文件体积小，数据恢复
缺点：有数据丢失可能，备份文件版本兼容问题
写临时文件，覆盖老文件
aof持久化
（1）命令写入
（2）文件同步
（3）文件重写
（3.1）整理压缩aof文件，整理方式（过期数据，重复更新，删除数据，命令聚合）
（3.2）手动触发（）；被动触发
（3.3）fork子进程不影响父进程处理请求；子进程双写，确保数据不丢失
redis重启恢复过程
（append only file
日志形式记录写入指令
实时持久化） -
可靠性保障方式
（1）主从模式
全量同步，增量同步，运行id（master启动时生成，同步给salve），复制偏移量（确定同步位置）
（2）哨兵模式
监控（不断的检查master和slave是否运作正常），提醒（发现故障通知管理员和客户端），故障转移（自动主从切换，更新配置信息），集群配置信息提供（客户端应用初始化连接sentinel获取节点信息）
哨兵模式架构
（3）集群模式
无需sentinel哨兵，支持水平扩容，自动转移，不支持批量操作
客户端路由，两次交互，存在性能问题
（3.1）集群模式-codie -
数据分片策略对客户端透明
-
Zookeper作为name server
-
提供支持redis协议的proxy
-
proxy负责请求路由
mysql innodb存储原理与技术分析
（1）页头
（2）虚记录
（3）记录堆
（4）自由空间链表
（5）未分配空间
（6）slot区
（7）页尾
（8）页内记录维护
-变长数据存储-innodb
pagesize 16kb
每页至少两条数据
最多存储10个大字段
varcher
- 索引原理分析
聚簇索引
（1）数据存储在主键索引上
（2）数据按主键顺序存储
（3）自增主键vs随机主键
二级索引
（1）除主键索引以外的索引
（2）叶子中存储主键值
（3）一次查询需要走两遍索引
（4）主键大小会影响所有索引的大小
联合索引
（1）key由多个字段组成
（2）最左匹配原则
（3）一个索引只创建一棵树
（4）按第一列排序，第一列相同按第二列排序
索引实现原理
（1）存储空间
（2）主键选择
（3）联合索引使用
（4）字符串索引
innodb内存管理
（1）预分配内存空间
（2）数据以页为单位加载
（3）数据内存交换
innodb内存管理-技术点
（1）内存池
（2）内存页面管理
页面映射
页面数据管理
（3）数据淘汰
内存也都被使用
需要加载新数据
（4）页面管理
空闲页，数据页，脏页
（5）页面淘汰
lru
（6）mysql内存管理
buffer pool（预分配的内存池）
page（buffer pool的最小单位）
free list（空闲page组成的链表）
flush hash 表（维护内存page和文件的映射关系）
lru（内存淘汰算法）
（7）mysql内存管理-lru
（1）lru_new
（2）lru_old
（3）midpoint
（4）页面装载
磁盘数据到内存
（5）页面淘汰
（6）位置移动
（7）lru_new的操作 - mysql 事务基本概念
事务特性
并发问题
隔离级别 - mysql的事务实现原理
mvcc
（1）当前读
（2）快照读
（3）可见性判断
（4）read view（快照读，活跃事务列表；列表中最小事务id；列表中最大事务id）
undolog
（1）回滚日志
（2）保证事务原子性
（3）实现数据多原本
redolog
（1）记录修改
（2）用于异常恢复
（3）循环写入文件
（4）写入流程
（5）刷盘时机
（6）意义
索引使用费技巧
联合索引：优于多列独立索引
索引顺序：选择性高的在前面
覆盖索引：二级索引存储主键值更有利
索引排序：索引同时满足查询和排序 - 分库分表设计
（1）是否分表（建议单表并不超过1kw）
（2）分表方式
取模：存储均匀&访问均匀
按时间：冷热库
（3）分库
按业务垂直分布
水平垂直多个库
分布式存储技术原理分析
cap定理
cap定理：在一个分布式计算系统中，一致性，可用性和分区容错性这三种保证无法同时得到满足
（1）一致性
（2）可用性
（3）分区容错性
cap取舍：
cp：发生分区，需要牺牲用户体验，等待所有数据全部一致了之后再让用户访问系统
ap：发生分区，为了高可用，每个节点只能用本地数据提供服务，会导致全局数据的不一致性
理想情况下单机数据库ac；分布式数据库系统cp
单机数据库分布式解决方案
（1）垂直拆分
（2）水平拆分
（3）读写分离
业务侵入大，维护成本高
分布式数据库特性
（1）存储量不受单机容量限制
（2）计算能力不受单机资源限制
（3）扩展性强
（4）容错能力强
（5）数据可靠性高
- 分布式数据库设计思路
（1）多副本存储
保证数据一致性
一般kv存储模型
（2）主从模式
提供数据分片路由支持
（2.1）多副本存储方式
底层kv存储
数据一致性协议 - 技术难点-热点数据
（1）热点数据
数据分块
热数据迁移
（2）原子性
（2.1）技术难点-原子性
乐观锁方式
两阶段提交
（1）prewrite，获取锁，写入数据
（2）commit ，提交变更
常见分布式储存产品
（1）mongpdb
（2）pika（360）
（3）pagasus（小米）
（4）tian（美图）
（5）codis（redis分布式解决方案）
（6）tidb
分布式存储技术产品选型及适用场景分析
mongo
（1）文档型数据库
（2）支持主从
（3）支持副本集模式
（4）支持数据分片
（5）快速水平扩展
（6）高效数据压缩
tidb
（1）sql支持
（2）水平线弹性扩展
（3）水平式事务
（4）数据一致性保证
（5）故障自恢复的高可用
tidb架构
（1）基于rocksdb
（2）raft一致性协议
（3）etcd存储元数据
（4）支持olca
（5）支持olap
cods
综合对比分析
（1）协议
（2）持久化
（3）存储模型
（4）分布式方案
mysql迁移到tidb案列
mysql使用问题
（1）数据量大，快速水平扩展存储
（2）大数据量下，快速ddl
（3）分库分表造成业务逻辑非常复杂
（4）常规mysql主从故障转移会导致业务访问短暂不可用
数据及流量迁移
（1）数据迁移
主从同步
双写
（2）流量协议
切读
停双写
锁冲突问题
业务场景–手机通知栏推送
（1）用户—设备id映射
（2）数据变更场景
1账号登录多手机
2手机登录多账号
- 乐观锁问题
（1）商品状态流转
发布者下家商品0-1
买家拍下商品0-2