https://baijiahao.baidu.com/s?id=1622441635115622194&wfr=spider&for=pc
https://mp.weixin.qq.com/s/5bBzVN-6jbpMtJf0xxssNg
https://www.cnblogs.com/405845829qq/p/7552736.html
https://mp.weixin.qq.com/s/clQrAnxuxX_al7k6TPpgzw 【有实战讲解】
【本文只是集各篇文章之所长，整体概述，具体到每一个细节还有很多小知识，自己搜索】
目录
（1）第一种扩容的方式：根据表的数据增加库的数量----表不动，加库，库加倍----无数据迁移
（2）第二种扩容的方式：成倍的增加表----加表加库，两者均加倍
5.3、跨节点的count,order by,group by以及聚合函数问题
1、分库分表的原因
1、随着单库中的数据量越来越大，相应的，查询所需要的时间也越来越多，这个时候，相当于数据的处理遇到了瓶颈
2、单库发生意外的时候，需要修复的是所有的数据，而多库中的一个库发生意外的时候，只需要修复一个库（当然，也可以用物理分区的方式处理这种问题）
2、分库分表的常用策略
2.1、垂直切分（拆字段）
根据业务的不同，将原先拥有很多字段的表拆分为两个或者多个表，这样的代价我个人觉得很大，原来对这应这个表的关系，开始细分，需要一定的重构，而且随着数据量的增多，极有可能还要增加水平切分；
2.2、水平切分
将数据分散在多个表中
Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。不太严格的讲，对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用垂直切分，即把关系紧密（比如同一模块）的表切分出来放在一个server上。如果表并不多，但每张表的数据非常多，这时候适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个数据库(server)上。当然，现实中更多是这两种情况混杂在一起，这时候需要根据实际情况做出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库(server)阵列。
需要特别说明的是：当同时进行垂直和水平切分时，切分策略会发生一些微妙的变化。比如：在只考虑垂直切分的时候，被划分到一起的表之间可以保持任意的关联关系，因此你可以按“功能模块”划分表格，但是一旦引入水平切分之后，表间关联关系就会受到很大的制约，通常只能允许一个主表（以该表ID进行散列的表）和其多个次表之间保留关联关系，也就是说：当同时进行垂直和水平切分时，在垂直方向上的切分将不再以“功能模块”进行划分，而是需要更加细粒度的垂直切分，而这个粒度与领域驱动设计中的“聚合”概念不谋而合，甚至可以说是完全一致，每个shard的主表正是一个聚合中的聚合根！这样切分下来你会发现数据库分被切分地过于分散了（shard的数量会比较多，但是shard里的表却不多），为了避免管理过多的数据源，充分利用每一个数据库服务器的资源，可以考虑将业务上相近，并且具有相近数据增长速率（主表数据量在同一数量级上）的两个或多个shard放到同一个数据源里，每个shard依然是独立的，它们有各自的主表，并使用各自主表ID进行散列，不同的只是它们的散列取模（即节点数量）必需是一致的.
3、分库分表的常用方法
3.1、有瑕疵的简单分库分表（按id的大小分库分表）
按照分片键（我们这里就用id表示了）的大小来进行分库分表，如果你的id是自增的，而且能保证在进行分库分表后也是自增的，那么能进行很好的改造，以id大小水平切分，而且极有可能不用迁移数据。
- 当然，这里只列举了比较小的数据量，实际情况的分库的界限还是要依据具体的情况而定。
- 这样的分库分表，因为新的数据总在一个库里，很可能导致热点过于集中（读写可能集中在一个库中），这是采取这种方式需要考虑的事情。
- 如果无法保证你的id是自增长的，那么你的数据就会凌乱的分散在各个数据库，这样热点确实就分散了，可是每当你增加一个数据库的时候，你就有可能进行大量的数据迁移，应对这种情况，就是尽量减少数据迁移的代价，所以这里运用一致性hash的方式进行分库分表比较好，可以尽可能的减少数据迁移，并且也能解决热点过于集中的问题。
- 这里按id的大小来分库，还可以发散到按照时间来分库，比如说一个月的数据放在一个库，这个使用mycat比较容易实现按时间分库，不过你需要思考的数据的离散性，数据集中于一个两月，而剩下的几个月数据稀疏，这样的又可能需要按照数据的生产规律合并几个月到一个库中，使得数据分布均匀。
3.2、比较方便的取模分库
一般的取模分库分表是就是将id mod n，然后放入数据库中，这样能够使数据分散，不会有热点的问题，那么，剩下的是，在扩容的时候，是否会有数据迁移的问题，一般的扩容，当然是会有数据迁移的。
例子中，对3取模，当需要扩容的时候(假设增加两个库)，则对5取模，这样的结果必然是要进行数据迁移的，但是可以运用一些方法，让它不进行数据迁移，scale-out扩展方案能够避免在取模扩容的时候进行数据迁移。
（1）第一种扩容的方式：
根据表的数据增加库的数量----表不动，加库，库加倍----无数据迁移
首先，我们有一个数据库——DB_0,四张表——tb_0,tb_1,tb_2,tb_3那么我们现在数据到数据库是这样的:
DB="DB_0"；TB=“tb_"+id%4
当数据增加，需要进行扩容的时候，我增加一个数据库：DB_1
DB="DB_"+((id%4)/2)；TB=“tb_"+id%4
当我们的数据继续飙升，这个时候又需要我们增加库，这个时候进行加库操作的时候，就不是增加一个库，而必须是两个，这样才能保证不进行数据迁移。DB="DB_"+id%4；TB=“tb_"+id%4
这个时候到了这个方案的加库上限，不能继续加库了，否则就要进行数据迁移，所以这个方案的弊端还是挺大的，这样的方式，也会造成单表的数据量过大。
（2）第二种扩容的方式：成倍的增加表----加表加库，两者均加倍
首先，我们还是一个数据库——DB_0,两张表——tb_0,tb_1，那么我们现在数据到数据库是这样的:DB="DB_0"；TB=“tb_"+id%2
假设当我们数据量打到一千万的时候，我们增加一个库，这时需要我们增加两张表：tb_0_1,tb_1_1，并且原来的 DB_0 中库的表 tb_1 整表迁移到 DB_1 中，tb_0 和 tb_0_1放在 DB_0 中，tb_1 和 tb_1_1 放到 DB1 中。
DB="DB_"+id%2；
tb:
if(id<1千万) { return "tb_" + id % 2 }
else if(id>=1千万) { return "tb_"+ id % 2 + "_1" }
数据的增长不可能到此为止，当增加到两千万的时候，我们需要加库，这个时候，按照这种做法，我们需要增加两个库(DB_2,DB_3) 和 四张表(tb_0_2,tb_1_2,tb_2_2,tb_3_2)，将上次新增的表整表分别放进两个新的库中，然后每个库里再生成一张新表。
DB:
if(id < 1千万) { return "DB_" + id % 2 }
else if(1千万 <= id < 2千万) { return "DB_"+ id % 2 +2 }
else if(2千万 <= id ) { return "DB_"+ id % 4 }
tb:
if(id < 1千万) { return "tb_" + id % 2 }
else if(1千万 <= id < 2千万) { return "tb_"+ id % 2 +"1" }
else if(id >= 2千万) { return "tb"+ id % 4+"_2" }
值得注意的一点，在id超出范围的时候，该给怎么样的提示是值得思考的。
4、常用的分库分表中间件
4.1、简单易用的组件
- 当当：sharding-jdbc
- 蘑菇街“”TSharding
4.2、强悍重量级的中间件
- sharding
- TDDL Smart Client的方式（淘宝）
- Atlas(Qihoo 360)
- alibaba.cobar(是阿里巴巴（B2B）部门开发)
- MyCAT（基于阿里开源的Cobar产品而研发）
- Oceanus(58同城数据库中间件)
- OneProxy(支付宝首席架构师楼方鑫开发)
- vitess（谷歌开发的数据库中间件）
4.3、中间件分类
这么多的分库分表中间件全部可以归结为两大类型：
- CLIENT模式；
- PROXY模式；
（1）CLIENT模式代表有阿里的TDDL，开源社区的sharding-jdbc（sharding-jdbc的3.x版本即sharding-sphere已经支持了proxy模式）。架构如下：
（2）PROXY模式代表有阿里的cobar，民间组织的MyCAT。架构如下：
但是，无论是CLIENT模式，还是PROXY模式。几个核心的步骤是一样的：SQL解析，重写，路由，执行，结果归并。
笔者比较倾向于CLIENT模式，架构简单，性能损耗较小，运维成本低。
5、分库分表需要解决的问题
5.1、事务问题
方案一：使用分布式事务
- 优点： 交由数据库管理，简单有效
- 缺点：性能代价高，特别是shard越来越多时
方案二：由应用程序和数据库共同控制
- 原理：将一个跨多个数据库的分布式事务分拆成多个仅处理单个数据库上面的小事务，并通过应用程序来总控各个小事务。
- 优点：性能上有优势
- 缺点：需要应用程序在事务控制上做灵活设计。如果使用了spring的事务管理，改动起来会面临一定的困难。
5.2、跨节点Join的问题
只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。
5.3、跨节点的count,order by,group by以及聚合函数问题
这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。
解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。
5.4、数据迁移，容量规划，扩容等问题
来自淘宝综合业务平台团队，它利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总的来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。
5.5、ID问题
一旦数据库被切分到多个物理结点上，我们将不能再依赖数据库自身的主键生成机制。
一方面，某个分区数据库自生成的ID无法保证在全局上是唯一的；
另一方面，应用程序在插入数据之前需要先获得ID,以便进行SQL路由.一些常见的主键生成策略。
（1）UUID 结合数据库维护一个Sequence表
使用UUID作主键是最简单的方案，但是缺点也是非常明显的。由于UUID非常的长，除占用大量存储空间外，最主要的问题是在索引上，在建立索引和基于索引进行查询时都存在性能问题。
此方案的思路也很简单，在数据库中建立一个Sequence表，表的结构类似于：
CREATETABLE`SEQUENCE` (
`table_name`varchar(18) NOTNULL,
`nextid`bigint(20) NOTNULL,
PRIMARY KEY (`table_name`)
) ENGINE=InnoDB每当需要为某个表的新记录生成ID时就从Sequence表中取出对应表的nextid,并将 nextid 的值加 1 后更新到数据库中以备下次使用。
此方案也较简单，但缺点同样明显：由于所有插入任何都需要访问该表，该表很容易成为系统性能瓶颈，同时它也存在单点问题，一旦该表数据库失效，整个应用程序将无法工作。有人提出使用Master-Slave进行主从同步，但这也只能解决单点问题，并不能解决读写比为1:1的访问压力问题。
（2）Twitter的分布式自增ID算法Snowflake
在分布式系统中，需要生成全局UID的场合还是比较多的，twitter 的 snowflake 解决了这种需求，实现也还是很简单的，除去配置信息，核心代码就是：毫秒级时间41位； 机器ID 10位； 毫秒内序列12位。
- 10---0000000000 0000000000 0000000000 0000000000 0 --- 00000 ---00000 ---000000000000
在上面的字符串中，第一位为未使用（实际上也可作为long的符号位），接下来的41位为毫秒级时间，然后 5 位 datacenter标识位，5位机器ID（并不算标识符，实际是为线程标识），然后12位该毫秒内的当前毫秒内的计数，加起来刚好64位，为一个Long型。
这样的好处是:整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和机器ID作区分），并且效率较高，经测试，snowflake每秒能够产生26万ID左右，完全满足需要。
5.6、跨分片的排序分页
一般来讲，分页时需要按照指定字段进行排序。当排序字段就是分片字段的时候，我们通过分片规则可以比较容易定位到指定的分片，而当排序字段非分片字段的时候，情况就会变得比较复杂了。为了最终结果的准确性，我们需要在不同的分片节点中将数据进行排序并返回，并将不同分片返回的结果集进行汇总和再次排序，最后再返回给用户。如下图所示：
上面图中所描述的只是最简单的一种情况（取第一页数据），看起来对性能的影响并不大。但是，如果想取出第10页数据，情况又将变得复杂很多，如下图所示：
有些读者可能并不太理解，为什么不能像获取第一页数据那样简单处理（排序取出前10条再合并、排序）。其实并不难理解，因为各分片节点中的数据可能是随机的，为了排序的准确性，必须把所有分片节点的前N页数据都排序好后做合并，最后再进行整体的排序。很显然，这样的操作是比较消耗资源的，用户越往后翻页，系统性能将会越差。
那如何解决分库情况下的分页问题呢？有以下几种办法：
- 如果是在前台应用提供分页，则限定用户只能看前面n页，这个限制在业务上也是合理的，一般看后面的分页意义不大（如果一定要看，可以要求用户缩小范围重新查询）。
- 如果是后台批处理任务要求分批获取数据，则可以加大page size，比如每次获取5000条记录，有效减少分页数（当然离线访问一般走备库，避免冲击主库）。
- 分库设计时，一般还有配套大数据平台汇总所有分库的记录，有些分页查询可以考虑走大数据平台。
5.7、分库数量
分库数量首先和单库能处理的记录数有关，一般来说，Mysql 单库超过5000万条记录，Oracle单库超过1亿条记录，DB压力就很大(当然处理能力和字段数量/访问模式/记录长度有进一步关系)。
在满足上述前提下，如果分库数量少，达不到分散存储和减轻DB性能压力的目的；如果分库的数量多，好处是每个库记录少，单库访问性能好，但对于跨多个库的访问，应用程序需要访问多个库，如果是并发模式，要消耗宝贵的线程资源；如果是串行模式，执行时间会急剧增加。
最后分库数量还直接影响硬件的投入，一般每个分库跑在单独物理机上，多一个库意味多一台设备。所以具体分多少个库，要综合评估，一般初次分库建议分4-8个库。
5.8、路由透明
分库从某种意义上来说，意味着 DB schema 改变了，必然影响应用，但这种改变和业务无关，所以要尽量保证分库对应用代码透明，分库逻辑尽量在数据访问层处理。当然完全做到这一点很困难，具体哪些应该由DAL负责，哪些由应用负责，这里有一些建议：
- 对于单库访问，比如查询条件指定用户Id，则该SQL只需访问特定库。此时应该由DAL层自动路由到特定库，当库二次分裂时，也只要修改mod 因子，应用代码不受影响。
- 对于简单的多库查询，DAL负责汇总各个数据库返回的记录，此时仍对上层应用透明。
5.9、使用框架还是自主研发【结合第4点】
目前市面上的分库分表中间件相对较多，其中：
- 基于代理方式的有：MySQL Proxy和Amoeba，
- 基于Hibernate框架的是Hibernate Shards，
- 基于jdbc的有当当sharding-jdbc，
- 基于mybatis的类似maven插件式的有：蘑菇街TSharding，
- 通过重写spring的ibatis template类 的是 Cobar Client
这些框架各有各的优势与短板，架构师可以在深入调研之后结合项目的实际情况进行选择，但是总的来说，我个人对于框架的选择是持谨慎态度的。
一方面多数框架缺乏成功案例的验证，其成熟性与稳定性值得怀疑。
另一方面，一些从成功商业产品开源出框架（如阿里和淘宝的一些开源项目）是否适合你的项目是需要架构师深入调研分析的。当然，最终的选择一定是基于项目特点、团队状况、技术门槛和学习成本等综合因素考量确定的。
6、部署方法----数据迁移方法
6.1、停机 部署法
大致思路就是，挂一个公告，半夜停机升级，然后半夜把服务停了，跑数据迁移程序，进行数据迁移。
步骤如下:
（1）出一个公告，比如 “今晚00:00～6:00进行停机维护，暂停服务”
（2）写一个迁移程序，读 db-old 数据库，通过中间件写入新库 db-new1 和 db-new2 ，具体如下图所示
（3）校验迁移前后一致性，没问题就切该部分业务到新库。顺便科普一下，这个中间件。现在流行的分库分表的中间件有两种：
- 一种是proxy形式的，例如mycat，是需要额外部署一台服务器的。
- 还有一种是client形式的，例如当当出的Sharding-JDBC，就是一个jar包，使用起来十分轻便。
我个人偏向Sharding-JDBC，这种方式，无需额外部署，无其他依赖，DBA也无需改变原有的运维方式。
评价：
大家不要觉得这种方法low，我其实一直觉得这种方法可靠性很强。而且我相信各位读者所在的公司一定不是什么很牛逼的互联网公司，如果你们的产品凌晨1点的用户活跃数还有超过1000的，你们握个爪！毕竟不是所有人都在什么电商公司的，大部分产品半夜都没啥流量。所以此方案，并非没有可取之处。
但是此方案有一个缺点，累！不止身体累，心也累！你想想看，本来定六点结束，你五点把数据库迁移好，但是不知怎么滴，程序切新库就是有点问题。于是，眼瞅着天就要亮了，赶紧把数据库切回老库。第二个晚上继续这么干，简直是身心俱疲。
ps：这里教大家一些技巧啊，如果你真的没做过分库分表，又想吹一波，涨一下工资，建议答这个方案。因为这个方案比较low，low到没什么东西可以深挖的，所以答这个方案，比较靠谱。
- 你刚才刚好有提到分库分表的相关问题，我们当时部署的时候，先停机。然后半夜迁移数据，然后第二天将流量切到新库，这种方案太累，不知道贵公司有没有什么更好的方案？
那么这种情况下，会有两种回答。
第一种，硬着头皮随便扯。
第二种，真的做过，据实回答。记住，怎么回答的不重要。重点的是，你这个问题出去，会给面试官一种错觉:"这个小伙子真的做过分库分表。"
如果你担心进去了，真派你去做分库分表怎么办？OK，不要怕。我赌你试用期碰不到这个活。因为能进行分库分表，必定对业务非常熟。还在试用期的你，必定对业务不熟，如果领导给你这种活，我只能说他有一颗大心脏。
ok，指点到这里。面试本来就是一场斗智斗勇的过程，扯远了，回到我们的主题。
6.2、双写部署法（一）----消息队列做增量记录
这个就是不停机部署法，这里我需要先引进两个概念: 历史数据 和 增量数据。
假设，我们是对一张叫做 test_tb 的表进行拆分，因为你要进行双写，系统里头和 test_tb 表有关的业务之前必定会加入一段双写代码，同时往老库和新库中写，然后进行部署，那么
历史数据：在该次部署前，数据库表test_tb的有关数据，我们称之为历史数据。
增量数据：在该次部署后，数据库表test_tb的新产生的数据，我们称之为增量数据。
然后迁移流程如下
（1）先计算你要迁移的那张表的max(主键)。在迁移过程中，只迁移db-old中test_tb表里，主键小等于该max(主键)的值，也就是所谓的历史数据。
这里有特殊情况，如果你的表用的是uuid，没法求出max(主键)，那就以创建时间作为划分历史数据和增量数据的依据。如果你的表用的是uuid,又没有创建时间这个字段，我相信机智的你，一定有办法区分出历史数据和增量数据。
（2）在代码中，与test_tb有关的业务，多加一条往消息队列中发消息的代码，将操作的sql发送到消息队列中，至于消息体如何组装，大家自行考虑。需要注意的是，只发写请求的sql，只发写请求的sql，只发写请求的sql。重要的事情说三遍！原因有二：
- 只有写请求的sql对恢复数据才有用。
- 系统中，绝大部分的业务需求是读请求，写请求比较少。
注意了，在这个阶段，我们不消费消息队列里的数据。我们只发写请求，消息队列的消息堆积情况不会太严重！
（3）写一段迁移程序 迁移历史数据，迁移 db-old 中主键小于该max(主键)的数据到 test_tb 表里 。
上面步骤（1）～步骤（3）的过程如下：
（4）等到db-old中的历史数据迁移完毕，则开始迁移增量数据，也就是在消息队列里的数据。将迁移程序下线，写一段订阅程序订阅消息队列中的数据，订阅程序将订阅到到数据，通过中间件写入新库
（5）新老库一致性验证，去除代码中的双写代码，将涉及到 test_tb 表的读写操作，指向新库。
上面步骤（4）～步骤（5）的过程如下：
这里大家可能会有一个问题，在步骤(1)～步骤(3),系统对历史数据进行操作，会造成不一致的问题么？
OK，不会。这里我们对delete操作和update操作做分析，因为只有这两个操作才会造成历史数据变动，insert进去的数据都是属于增量数据。
- 对db-old中test_tb表的历史数据发出delete操作，数据还未删除，就被迁移程序给迁走了。此时delete操作在消息队列里还有记录，后期订阅程序订阅到该delete操作，可以进行删除。
- 对db-old中test_tb表的历史数据发出delete操作，数据已经删除，迁移程序迁不走该行数据。此时delete操作在消息队列里还有记录，后期订阅程序订阅到该delete操作，再执行一次delete，并不会对一致性有影响。对update的操作类似，不赘述。
6.3、双写部署法（二）----binlog做增量记录
上面的方法有一个硬伤，注意我有一句话
- 在代码中，与test_tb有关的业务，多加一条往消息队列中发消息的代码，将操作的sql发送到消息队列中，至于消息体如何组装，大家自行考虑。
大家想一下，这么做，是不是造成了严重的代码入侵。将非业务代码嵌入业务代码，这么做，后期删代码的时候特别累。
有没什么方法，可以避免这个问题的？
有的，订阅binlog日志。关于binlog日志，我尽量下周写一篇《研发应该掌握的binlog知识》，这边我就介绍一下作用
- 记录所有数据库表结构变更（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）的二进制日志。binlog不会记录SELECT和SHOW这类操作，因为这类操作对据本身并没有修改。
还记得我们在 双写部署法(一) 里介绍的，往消息队列里发的消息，都是写操作的消息。而binlog日志记录的也是写操作。所以订阅该日志，也能满足我们的需求。
于是步骤如下：
（1）打开binlog日志，系统正常上线就好
（2）还是写一个迁移程序，迁移历史数据。步骤和上面类似，不啰嗦了。步骤（1）~步骤（2）流程图如下
（3）写一个订阅程序，订阅binlog(mysql中有canal。至于oracle中，大家就随缘自己写吧)。然后将订阅到的数据通过中间件，写入新库。
（4）检验一致性，没问题就切库。
步骤（3）~步骤（4）流程图如下：
=====================
怎么检验数据一致性
这里大概介绍一下吧，这篇的篇幅太长了，大家心里有底就行。
（1）先验数量是否一致，因为验数量比较快。
至于验具体的字段，有两种方法：
（2.1）有一种方法是，只验关键性的几个字段是否一致。
（2.2）还有一种是 ，一次取50条(不一定50条，具体自己定，我只是举例),然后像拼字符串一样，拼在一起。用 md5进行加密，得到一串数值。新库一样如法炮制，也得到一串数值，比较两串数值是否一致。如果一致，继续比较下50条数据。如果发现不一致，用 二分法 确定不一致的数据在0-25条，还是26条-50条。以此类推，找出不一致的数据，进行记录即可。
END
1351
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
