数据库很容易成为应用系统的瓶颈。单机数据库的资源和处理能力有限，在高并发的分布式系统中，可采用分库分表突破单机局限。本文总结了分库分表的相关概念、全局ID的生成策略、分片策略、平滑扩容方案、以及流行的方案。
1 分库分表概述
在业务量不大时，单库单表即可支撑。
当数据量过大存储不下、或者并发量过大负荷不起时，就要考虑分库分表。
1.1 分库分表相关术语
-
读写分离: 不同的数据库，同步相同的数据，分别只负责数据的读和写；
-
分区: 指定分区列表达式，把记录拆分到不同的区域中(必须是同一服务器，可以是不同硬盘)，应用看来还是同一张表，没有变化；
-
分库：一个系统的多张数据表，存储到多个数据库实例中；
-
分表: 对于一张多行(记录)多列(字段)的二维数据表，又分两种情形：
(1) 垂直分表: 竖向切分，不同分表存储不同的字段，可以把不常用或者大容量、或者不同业务的字段拆分出去；
(2) 水平分表(最复杂): 横向切分，按照特定分片算法，不同分表存储不同的记录。
1.2 真的要采用分库分表？
需要注意的是，分库分表会为数据库维护和业务逻辑带来一系列复杂性和性能损耗，除非预估的业务量大到万不得已，切莫过度设计、过早优化。
规划期内的数据量和性能问题，尝试能否用下列方式解决：
-
当前数据量：如果没有达到几百万，通常无需分库分表；
-
数据量问题：增加磁盘、增加分库(不同的业务功能表，整表拆分至不同的数据库)；
-
性能问题：升级CPU/内存、读写分离、优化数据库系统配置、优化数据表/索引、优化 SQL、分区、数据表的垂直切分；
-
如果仍未能奏效，才考虑最复杂的方案：数据表的水平切分。
2 全局ID生成策略
2.1 自动增长列
优点：数据库自带功能，有序，性能佳。
缺点：单库单表无妨，分库分表时如果没有规划，ID可能重复。解决方案：
2.1.1 设置自增偏移和步长
- ### 假设总共有 10 个分表
- ### 级别可选: SESSION(会话级), GLOBAL(全局)
- SET @@SESSION.auto_increment_offset = 1; ### 起始值, 分别取值为 1~10
- SET @@SESSION.auto_increment_increment = 10; ### 步长增量
如果采用该方案，在扩容时需要迁移已有数据至新的所属分片。
2.1.2 全局ID映射表
在全局 Redis 中为每张数据表创建一个 ID 的键，记录该表当前最大 ID；
每次申请 ID 时，都自增 1 并返回给应用；
Redis 要定期持久至全局数据库。
2.2 UUID(128位)
在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成UUID的API。
UUID 由4个连字号(-)将32个字节长的字符串分隔后生成的字符串，总共36个字节长。形如：550e8400-e29b-41d4-a716-446655440000。
UUID 的计算因子包括：以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字。
UUID 是个标准，其实现有几种，最常用的是微软的 GUID(Globals Unique Identifiers)。
优点：简单，全球唯一；
缺点：存储和传输空间大，无序，性能欠佳。
2.3 COMB(组合)
参考资料：The Cost of GUIDs as Primary Keys
组合 GUID(10字节) 和时间(6字节)，达到有序的效果，提高索引性能。
2.4 Snowflake(雪花) 算法
参考资料：twitter/snowflake，Snowflake 算法详解
Snowflake 是 Twitter 开源的分布式 ID 生成算法，其结果为 long(64bit) 的数值。
其特性是各节点无需协调、按时间大致有序、且整个集群各节点单不重复。
该数值的默认组成如下(符号位之外的三部分允许个性化调整)：
-
1bit: 符号位，总是 0(为了保证数值是正数)。
-
41bit: 毫秒数(可用 69 年)；
-
10bit: 节点ID(5bit数据中心 + 5bit节点ID，支持 32 * 32 = 1024 个节点)
-
12bit: 流水号(每个节点每毫秒内支持 4096 个 ID，相当于 409万的 QPS，相同时间内如 ID 遇翻转，则等待至下一毫秒)
3 分片策略
3.1 连续分片
根据特定字段(比如用户ID、订单时间)的范围，值在该区间的，划分到特定节点。
优点：集群扩容后，指定新的范围落在新节点即可，无需进行数据迁移。
缺点：如果按时间划分，数据热点分布不均(历史数冷当前数据热)，导致节点负荷不均。
3.3 ID取模分片
缺点：扩容后需要迁移数据。
3.2 一致性Hash算法
优点：扩容后无需迁移数据。
3.4 Snowflake 分片
优点：扩容后无需迁移数据。
4 分库分表引入的问题
4.1 分布式事务
参见 分布式事务的解决方案
由于两阶段/三阶段提交对性能损耗大，可改用事务补偿机制。
4.2 跨节点 JOIN
对于单库 JOIN，MySQL 原生就支持；
对于多库，出于性能考虑，不建议使用 MySQL 自带的 JOIN，可以用以下方案避免跨节点 JOIN：
-
全局表: 一些稳定的共用数据表，在各个数据库中都保存一份；
-
字段冗余: 一些常用的共用字段，在各个数据表中都保存一份；
-
应用组装：应用获取数据后再组装。
另外，某个 ID 的用户信息在哪个节点，他的关联数据(比如订单)也在哪个节点，可以避免分布式查询。
4.3 跨节点聚合
只能在应用程序端完成。
但对于分页查询，每次大量聚合后再分页，性能欠佳。
4.4 节点扩容
节点扩容后，新的分片规则导致数据所属分片有变，因而需要迁移数据。
5 节点扩容方案
相关资料: 数据库秒级平滑扩容架构方案
5.1 常规方案
如果增加的节点数和扩容操作没有规划，那么绝大部分数据所属的分片都有变化，需要在分片间迁移：
-
预估迁移耗时，发布停服公告；
-
停服(用户无法使用服务)，使用事先准备的迁移脚本，进行数据迁移；
-
修改为新的分片规则；
-
启动服务器。
5.2 免迁移扩容
采用双倍扩容策略，避免数据迁移。扩容前每个节点的数据，有一半要迁移至一个新增节点中，对应关系比较简单。
具体操作如下(假设已有 2 个节点 A/B，要双倍扩容至 A/A2/B/B2 这 4 个节点)：
-
无需停止应用服务器；
-
新增两个数据库 A2/B2 作为从库，设置主从同步关系为：A=>A2、B=>B2，直至主从数据同步完毕(早期数据可手工同步)；
-
调整分片规则并使之生效：
原ID%2=0 => A改为ID%4=0 => A, ID%4=2 => A2；
原ID%2=1 => B改为ID%4=1 => B, ID%4=3 => B2。 -
解除数据库实例的主从同步关系，并使之生效；
-
此时，四个节点的数据都已完整，只是有冗余(多存了和自己配对的节点的那部分数据)，择机清除即可(过后随时进行，不影响业务)。
6 分库分表方案
6.1 代理层方式
部署一台代理服务器伪装成 MySQL 服务器，代理服务器负责与真实 MySQL 节点的对接，应用程序只和代理服务器对接。对应用程序是透明的。
比如 MyCAT，官网，源码，参考文档：MyCAT+MySQL 读写分离部署
MyCAT 后端可以支持 MySQL, SQL Server, Oracle, DB2, PostgreSQL等主流数据库，也支持MongoDB这种新型NoSQL方式的存储，未来还会支持更多类型的存储。
MyCAT 不仅仅可以用作读写分离，以及分表分库、容灾管理，而且可以用于多租户应用开发、云平台基础设施，让你的架构具备很强的适应性和灵活性。
6.2 应用层方式
处于业务层和 JDBC 层中间，是以 JAR 包方式提供给应用调用，对代码有侵入性。主要方案有：
(1)淘宝网的 TDDL: 已于 2012 年关闭了维护通道，建议不要使用。
(2)当当网的 Sharding-JDBC: 仍在活跃维护中：
是当当应用框架 ddframe 中，从关系型数据库模块 dd-rdb 中分离出来的数据库水平分片框架，实现透明化数据库分库分表访问，实现了 Snowflake 分片算法；
Sharding-JDBC定位为轻量Java框架，使用客户端直连数据库，无需额外部署，无其他依赖，DBA也无需改变原有的运维方式。
Sharding-JDBC分片策略灵活，可支持等号、between、in等多维度分片，也可支持多分片键。
SQL解析功能完善，支持聚合、分组、排序、limit、or等查询，并支持Binding Table以及笛卡尔积表查询。
Sharding-JDBC直接封装JDBC API，可以理解为增强版的JDBC驱动，旧代码迁移成本几乎为零：
-
可适用于任何基于Java的ORM框架，如JPA、Hibernate、Mybatis、Spring JDBC Template或直接使用JDBC。
-
可基于任何第三方的数据库连接池，如DBCP、C3P0、 BoneCP、Druid等。
-
理论上可支持任意实现JDBC规范的数据库。虽然目前仅支持MySQL，但已有支持Oracle、SQLServer等数据库的计划。
数据库水平分库扩展
为了增加db的并发能力，常见的方案就是对数据进行sharding，也就是常说的分库分表，这个需要在初期对数据规划有一个预期，从而预先分配出足够的库来处理。
比如目前规划了3个数据库，基于uid进行取余分片，那么每个库上的划分规则如下：
我们可以看到，数据可以均衡的分配到3个数据库里面。
但是，如果后续业务发展的速度很快，用户量数据大量上升，当前容量不足以支撑，应该怎么办？
需要对数据库进行水平扩容，再增加新库来分解。新库加入之后，原先sharding到3个库的数据，就可以sharding到四个库里面了：
不过此时由于分片规则进行了变化（uid%3 变为 uid%4），大部分的数据，无法命中在原有的数据库上了，需要重新分配，大量数据需要迁移。
比如之前uid1通过uid1%3 分配在A库上，新加入库D之后，算法改为uid1%4 了，此时有可能就分配在B库上面了。如果你有看到之前《一致性哈希的原理与实践》，就会发现新增一个节点，大概会有90%的数据需要迁移，这个对DB同学的压力还是蛮大的，那么如何应对？
一般有以下几种方式：
停服迁移
停服迁移是最常见的一种方案了，一般如下流程：
-
预估停服时间，发布停服公告；
-
停服，通过事先做好的数据迁移工具，按照新的分片规则，进行迁移；
-
修改分片规则；
-
启动服务。
我们看到这种方式比较安全，停服之后没有数据写入，能够保证迁移工作的正常进行，没有一致性的问题。唯一的问题，就是停服了和时间压力了。
缺点：
-
停服，伤害用户体验，同时也降低了服务器的可用性；
-
必须在制定时间内完成迁移，如果失败，需要择日再次进行。同时增加了开发人员的压力，容易发生大的事故；
-
数据量的巨大的时候，迁移需要大量时间。
那有没有其他方式来改进一下，我们看下以下两种方案：
升级从库
线上数据库，我们为了保持其高可用，一般都会每台主库配一台从库，读写在主库，然后主从同步到从库。如下，A，B是主库，A0和B0是从库。
此时，当需要扩容的时候，我们把A0和B0升级为新的主库节点，如此由2个分库变为4个分库。同时在上层的分片配置，做好映射，规则如下：
uid%4=0和uid%4=2的分别指向A和A0，也就是之前指向uid%2=0的数据，分裂为uid%4=0和uid%4=2
uid%4=1和uid%4=3的指向B和B0，也就是之前指向uid%2=1的数据，分裂为uid%4=1和uid%4=3
因为A和A0库的数据相同，B和B0数据相同，所以此时无需做数据迁移。只需要变更一下分片配置即可，通过配置中心更新，无需重启。
由于之前uid%2的数据分配在2个库里面，此时分散到4个库中，由于老数据还存在（uid%4=0，还有一半uid%4=2的数据），所以需要对冗余数据做一次清理。
而这个清理，不会影响线上数据的一致性，可是随时随地进行。
处理完成以后，为保证高可用，以及下一步扩容需求。可以为现有的主库再次分配一个从库。
总结一下此方案步骤如下：
-
修改分片配置，做好新库和老库的映射。
-
同步配置，从库升级为主库
-
解除主从关系
-
冗余数据清理
-
为新的数据节点搭建新的从库
双写迁移
双写的方案，更多的是针对线上数据库迁移来用的，当然了，对于分库的扩展来说也是要迁移数据的，因此，也可以来协助分库扩容的问题。
原理和上述相同，做分裂扩容，只是数据的同步方式不同了。
一、增加新库写链接
双写的核心原理，就是对需要扩容的数据库上，增加新库，并对现有的分片上增加写链接，同时写两份数据。
因为新库的数据为空，所以数据的CRUD对其没有影响，在上层的逻辑层，还是以老库的数据为主。
二、新老库数据迁移
通过工具，把老库的数据迁移到新库里面，此时可以选择同步分裂后的数据（1/2）来同步，也可以全同步，一般建议全同步，最终做数据校检的时候好处理。
三、数据校检
按照理想环境情况下，数据迁移之后，因为是双写操作，所以两边的数据是一致的，特别是insert和update，一致性情况很高。但真实环境中会有网络延迟等情况，对于delete情况并不是很理想，比如：
A库删除数据a的时候，数据a正在迁移，还没有写入到C库中，此时C库的删除操作已经执行了，C库会多出一条数据。
此时就需要做好数据校检了，数据校检可以多做几遍，直到数据几乎一致，尽量以旧库的数据为准。
四、分片配置修改
数据同步完毕，就可以把新库的分片映射重新处理了，还是按照老库分裂的方式来进行：
uid%2=0，变为uid%4=0和uid%4=2
uid%2=1，变为uid%4=1和uid%4=3
五、冗余数据清理
最后，还是需要对冗余数据做一次清理。
标签：分库,数据库,扩展,uid%,分片,数据,节点 来源： https://www.cnblogs.com/hanease/p/16313321.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。