高并发中的数据库设计

一、单机数据库

1、数据库的基本组成
（1）K-V存储
（2）事务引擎、关系代数和
（3）用户API

2、K-V存储
（1）本质来说，就是“映射”，按照key找打value
（2）所有数据存储的最基本和最底层的结构
（3）不文件系统找指定的数据的作用相同，也是根据指定的key查找到对应的数据
（4）映射的关键特性
是否支持范围查找？是否能够处理更新？读写性能指标？是否面向磁盘结构？并行指标？内存占用？
（5）按照key找到对应的数据
（6）二级索引：分级key-value-key-value等
（7）组合索引：两个key

3、事务
（1）事务的核心就是锁与并发
（2）查询加锁，保证数据不会被独占
（3）单个事务单元：建立索引、读取记录、写入记录、删除。。。
（4）一组事务单元

4、SQL引擎
（1）AST
抽象语法树，标记SQL的组成方式
（2）执行计划
告知执行器如何高效的利用K-V

二、分布式数据库

1、多机Key-Value存储
（1）可运维、高性能、可以比较容易地扩容
（2）核心数据结构还是hash和树，部分case针对多机做了一点点优化
（3）代表组件

mongoDB->mongos服务器
Hbase->region server + client jar包
DRDS(TDDL)->tddl规则引擎组件

2、路由
（1）规则引擎
有状态数据应按照什么规则进行写入和读取
（2）本质来说还是查找的过程
Hash：O(1)效率，不支持范围查询（按时间这样的查询条件就比较困难），不需要频繁调整数据分布
Tree：主要是B-Tree，O(logN)效率，支持范围查询，需要频繁分裂和合并

3、Hash
（1）Id%n最普通的hash
（2）如果id%3 -> id%4总会有80%的数据发生移动，最好情况下是倍分id%3 -> id%6，这时候会有50%的数据发生移动，数据移动本身过于复杂
（3）一致性hash：主要解决数据扩容和缩容

Def idmod=id%100
If(id>=0 and id<250) return db1;
Else if(id >= 250 and id < 500) return db2;
Else if(id >= 500 and id < 750) return db3;
Else return db4；

（4）虚拟节点

解决热点问题，只需要调整对应关系即可
解决n到n+1问题，规则可以规定只移动需要移动的数据
方案相对的复杂一些
一般推荐使用简单方案开始，使用n到2n方案扩容
只有需要的情况下，再考虑平滑的扩展到虚拟节点方案即可

4、B树
Hbase使用的切分方法
支持范围查询，对于大部分场景来说，引导列都是pk.userid一类的单值查询，用树相对复杂
需要频繁的进行切分和合并操作，region server的噩梦
固定节点情况下，跨度相对较大，查找效率可能会进一步降低

5、一致性问题C（顺序）A（安全）P
（1）无主机方案Dynamo/cassandra/Paxos:gossip
W+R>N，所有节点可写，不存在单点故障
读数据的最新版本，需要将所有可写节点的数据都读出来合并一次
（2）有主机方案（Raft）
Mysql MongoDB Oracle+firbreChannel
只有一个节点可写，切换时存在短暂leader election过程，会出现短暂不可写
数据一致性比较好控制，读最新数据只需要读主机就可以，一致性读性能较好

6、考虑问题
（1）有些机器负担写任务，因此读压力可能不均衡，因此必须有权重设置
（2）单个节点挂掉的时候，TCP超时会导致业务APP的线程花费更多的时间来处理单个请求，这样会降低APP的处理能力，导致雪崩
（3）因为突发情况，导致数据库请求数增加，数据库响应变慢，导致雪崩

三、数据库时间

1、单机优化原则
（1）二分查找效率》全表遍历，选择合适的索引
（2）内存读写》SSD读写》磁盘读写，将物理读（磁盘读）换成逻辑读（内存读）
（3）减少锁冲突，尽可能通过业务设计，将更新变成插入
（4）减少临时表使用，减少多维护排序

2、分布式系统优化原则
（1）减少跨机网络交互，尽可能带sharding key，分页优化
（2）减少数据读写热点，切分颗粒度尽可能细，用户颗粒度好于省份
（3）减少锁开销，尽可能规避分布式事务

3、原则
（1）尽一切可能利用单机资源：单机事务、单机join
（2）尽可能走内存，尽可能将一次要查询到数据物理的放在一起
（3）通过合理的数据冗余，减少走网络的次数
（4）合理并行提升响应时间
（5）读取数据瓶颈，可以通过加slave节点解决
（6）写入瓶颈，用规则sharding和扩容来解决