大型网站数据库分库分表
分库分表方案：
垂直&水平
1、什么是垂直拆分？
指的是将一个包含了很多表的数据库,根据表的功能的不同,拆分为多个小的数据库,每个库中包含部分表。
、垂直拆分的另外2种用途？
1）、将一个包含了很多字段的大表拆分为多个小表,每个表中包含部分字段(基本很少遇到)
2）、进行服务化(SOA)的改造,除了业务上需要进行拆分,底层的存储也需要进行隔离
3、垂直拆分的好处？
垂直拆分会使得单个用户请求的响应时间变长,但是会使得整个服务的吞吐量大大的增加。（服务吞吐量即系统在单位时间内处理请求的数量）
使得单个用户请求的响应时间变长的原因在于：在单体应用场景下,所有的业务都在一个节点内部完成,而垂直拆分后,通常会需要进行rpc调用,rpc的调用会加长单个用户请求的响应时间。
2、什么是读写分离？
将数据库分为主库和从库,一个主库用于写数据,多个从库完成读数据的操作。
主从库通过某种机制进行数据的同步。
一、为什么需要使用读写分离？
随着业务的不断发展,用户数量和并发量不断上升,此时如果仅靠单个数据库实例来支撑所有的访问压力,数据库将难以支撑。
比如：产品库中,包含了几万种产品数据,并且每天新增几十条产品数据,而产品库每天的访问可能有几亿甚至几十亿次,数据库读的压力太大,单台mysql实例扛不住。此时可以将数据库进行读写分离,主库负责数据写的操作,多个从库负责数据读的操作。
1）、更新数据库数据时,应用将数据写入到master主库
2）、主库将数据同步给多个slave从库
3）、当查询数据时,应用选择某一个slave节点读取数据。
二、读写分离的优点？
通过配置多个从库,可以有效的避免过大的访问量对单个库造成的压力。
三、读写分离技术所面临的问题有哪些？
1）、主从数据同步延迟的问题
2）、事务问题
垂直拆分可以解决服务吞吐量即提高系统在单位时间内处理请求的数量
读写分离可以缓解单库的压力,增强用户并发访问量
3、什么是水平拆分（分表分库）？
通过一种算法,将数据库进行分割的架构。每个分片中的数据没有重合,所有分片中的数据并集组成全部数据。
4、分库分表的问题
主要体现在如下4个方面：基本数据的增删改功能、分布式id、分布式事务、动态扩容
1）、基本的数据库增删改功能
对于开发人员而言,虽然分库分表的,但是其还是希望能和单库单表那样去操作数据库。
如：我们要批量插入4条记录,并且希望根据用户的id字段,确定这条记录插入哪个库的那张表中。如：1号记录插入user1表….4号记录插入user4表
那么之前的单库作如下：
|
insert into user(id,name) values (1,”tianshouzhi”),(2,”huhuamin”), (3,”wanghanao”),(4,”luyang”) |
这显然无法实现,因为我们已经对库和表进行了拆分,这种sql语法只能操作mysql的单个库和单个表,所以必须将sql改为4条,然后分表到每个库上去执行,如下：
|
insert into user0(id,name) values (4,”luyang”) insert into user1(id,name) values (1,”tianshouzhi”) insert into user2(id,name) values (2,”huhuamin”) insert into user3(id,name) values (3,”wanghanao”) |
2）、分布式id
在分库分表后,我们不能再使用mysql的自增主键。
因为在插入记录的时候,不同的库生成的记录的自增id可能会出现冲突
因此,需要一个全局的id生成器,目前分布式id有很多种方案,其中一个比较轻量级的方案是twitter的snowflake算法。
3）、分布式事务
分布式事务是分库分表的绕不过去的一个坎,因为涉及到了同时更新多个分片数据。
如：批量插入记录到四个不同的库,如何保证要么同时成功,要么同时失败。
关于分布式事务,mysql支持XA事务,但是效率较低。
柔性事务是目前比较主流的方案,柔性事务包括：最大努力通知型、可靠消息最终一致性方案以及TCC两个阶段提交。
但是无论XA事务还是柔性事务,实现起来都是非常复杂的。
4）、动态扩容
动态扩容是指只增加分库分表的数量
如：将原来user表拆分到2个库的四张表上。
现在我们希望将分库的数量变为4个,分表的数量变为8个。
这种情况一般要伴随着数据迁移,如在4张表的情况下,id为7的记录,7%4=3
因此这条记录位于user3这张表上,但是现在分表的数量变为8个,而7%8=0
而user0这张表根本没有id=7这条记录,因此如果不进行数据迁移的话,就会出现记录找不到的情况。
分库策略:
Hash:通过一个字段进行hash
Range：范围
List：预定义
未完待续！！！
