分库分表

为什么要分库分表（分库分表解决的问题）

1.库并发量大，支撑不住
2.表数据量大sql执行慢
3.库数据量大，所在机器磁盘容量不够用

mysql的并发量控制

800-1200合理，不超过1500，2000危险

分库分表中间件

作用

帮你分发数据到指定的数据库数据表

分类

1.	proxy（独立部署在机器上）
i.	client（jar包，应用直接分发数据）

sharding-jdbc，3.0跟新为sharding-sphere：client

i.目前推出到了3.0版本，支持分库分表、读写分离、分布式id生成、柔性事务（最大努力送达型事务、TCC事务）
ii.成熟
iii.轻量级不需要额外部署
iv.版本升级相对麻烦

mycat：proxy

i.比较新
ii.不需要依赖直接访问中间件即可
iii.运维成本高

数据库拆分方式

垂直拆分（一般在设计数据库层面）

表的字段拆分；访问频率高低分一个表；数据库有缓存的，字段越少，缓存数据就越多，就越快；//订单表拆分（分表）

水平拆分（部署，提升性能层面）

相同表结构，不同数据
i.一个库相同表结构不同表（分表）
ii.不同库，相同表结构相同表（分库）
iii.先路由到某个库再路由到某个表

数据分发方式

i.常见根据id取摸hash分发（数据分散均匀，扩容不方便，数据迁移的过程）
ii.时间范围range分发 （扩容方便，数据访问热点问题）

分库分表后的数据迁移

长时间停机分库分表

关闭系统-数据迁移（后台临时程序+分库分表中间件）-部署新代码
需要长时间停机+可能一次搞不定

不停机双写方案

i.	修改系统写库的代码：同时操作新库和老库
ii.	后台数据迁移临时工具
    1.	判断新库是否有数据，没有就插入
    2.	判断新库是否有数据，有的话比较最后修改时间判断是否覆盖 
    3.	迁移一轮后，比较两个库的数据是否完全一样，如果不一样，判断是否需要覆盖
    4.	循环往复，到凌晨的时候基本上没有新的数据，差不多就一致了
    5.	删掉写旧库的代码，重新部署

动态扩容缩容的分库分表方案

为什么要扩容？

要么是磁盘容量不够，要么是并发扛不住

停机扩容（此时数据量太大）

动态扩容分库分表扩容方案

具体方案

i.一开始32个库32个表（一次性分够）
    1.最高支持并发：写并发32*1000=32000 32*15000=48000；每秒5万的写并发（完全够用）
    2.最高支持数据量：1024*500w=50亿条数据 
    3.一开始数据库服务器数量可以少点，之后库容（增加并发，以及降低磁盘使用率），只需要增加数据库服务器，数据库迁移，然后修改配置文件中数据库的地址即可。
ii.	路由规则
    1.	id%32=库
        id%32 %32 =表

扩容操作

（只需要增加数据库服务器，dba整库迁移，修改配置文件中的数据库地址即可）
i.一开始4个数据库服务器，每个服务器8个数据库（4*8=32）//并发4*2000=8000
ii.扩容1:8个数据库服务器，每个服务器4个数据库，dba负责整库迁移
iii.一般扩到32个服务器32个库，每个库32张表
iv.	最高1024个服务器，1024个库，每个库1张表（这个时候改变路由规则）

分库分表后主键问题

a)	基于全局的某个库色生成自增的id，（并发低）
b)	uuid，太长了，性能差
c)	当前时间+业务id生成唯一Id
d)	snowflake算法
    i.	64位long形的id
    ii.	1位+41位+5位+5位+12位
    iii.	0（正数）+时间戳计算的二进制（不是真实的时间）+机房id（最多32以内）+机器id（最多32以内）+排序（从0开始排序最多4096个	）
    iv.	那个机房的那个机器的那个时间发送过来的请求，如果同一毫秒有多个，后面排序累加
    v.	twitter的