关键词
- 分库分表规划
- 滑润扩容/缩容处理计划
- 无锁化规划
- 高并发体系
- 读写别离架构计划
一、简介
在高并发的体系中，体系的TPS目标瓶颈的一般是来源于数据库。单机数据库的资源和处理才能有限。在高并发的散布式体系中，可选用分库分表打破单机限制。本文经过分库分表的相关概念、分片战略、滑润扩/缩容计划、读写别离架构计划进行介绍。创作不易，转载请注明出处：原文链接
二、分库分表概述
在事务量不大时，单库单表即可支撑。当数据量过大存储不下、或许并发量过大负荷不起时，就要考虑分库分表。分库分表的目的是将数据进行涣散，分为若干个子集，称为逻辑分片，逻辑分片均对应有实在的物理分片，每个物理分片能够被区分为多个逻辑分片。
2.1、分库分表相关术语
- 读写别离: 不同的数据库，具有相同的数据，分别只担任数据的读和写；MySQL Master-Slave模式：Master担任写，Slave担任读
- 分库：一个体系的多张数据表，存储到多个数据库实例中；
- 分表: 关于一张多行(记载)多列(字段)的二维数据表，又分两种情形：
(1) 笔直分表: 竖向切分，不同分表存储不同的字段，能够把不常用或许大容量、或许不同事务的字段拆分出去。
(2) 水平分表: 横向切分，依照特定分片算法，不同分表存储不同的记载。
2.2 真的要选用分库分表？
需求注意的是，分库分表会为数据库保护和事务逻辑带来一系列杂乱性，除非预估的事务量大到万不得已，切莫过度规划、过早优化。 规划期内的数据量和功能问题，测验能否用下列方法处理：
- 当前数据量：假如没有到达几百万，通常无需分库分表；
- 数据量问题：添加磁盘、添加分库(不同的事务功能表，整表拆分至不同的数据库)；
- 功能问题：升级CPU/内存、读写别离、优化数据库体系配置、优化数据表/索引、优化 SQL、分区、数据表的笔直切分；
- 假如仍未能见效，才考虑最杂乱的计划：数据表的水平切分。
2.3 分片战略(路由战略、sharding)
2.3.1 连续分片
依据特定字段(比方用户ID、订单时刻)的规模，值在该区间的，区分到特定节点。
- 长处：集群扩容后，指定新的规模落在新节点即可，无需进行数据搬迁。
- 缺陷：假如按时刻区分，数据热点散布不均(前史数冷当前数据热)，导致节点负荷不均。数据规模膨胀时，分片战略需求快速进行调整适配
2.3.2 ID取模分片
长处：结合一致性哈希，虚拟节点等算法，平衡数据散布 缺陷：扩容后需求搬迁数据 举例：假设分库数为M，每个库的表数量为N,核算方法如下：
- 首要核算总表个数：M * N = K
- 核算数据地点一切表的index：id % K
- 核算地点库索引：index / N
- 核算地点库的表索引：index % N
三、体系扩容、缩容计划
3.1 分库数、分表数抉择
分表、分库的总数、redis库的总数、HashMap容量都要求是2的N次方，为什么？
- 由于假如分表数量 M 是 2的N次方时，在定位数据地点表的取模运算能够变换为位预算： id % M = id & (M – 1)，位运算在核算机中十分迅速的。
- 在进行缩容扩容时，能够核算出影响的数据规模
3.2 常规计划
- 预估搬迁耗时，发布停服公告；
- 停服(用户无法运用服务)，运用事前预备的搬迁脚本，进行数据搬迁；
- 修正为新的分片规矩；
- 启动服务器
该计划要求停机更新，在大部分互联网事务中是不行承受的。
3.3 滑润计划
选用双倍扩容战略，防止数据搬迁。扩容前每个节点的数据，有一半要搬迁至一个新增节点中，对应关系比较简单。具体操作如下(假设已有 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。
- 解除数据库实例的主从同步关系，并使之收效；
- 此时，四个节点的数据都已完整，只是有冗余(多存了和自己配对的节点的那部分数据)，择机铲除即可(过后随时进行，不影响事务)。
3.5 实践落地计划
常见署理比方:MyCat,部署一台MyCat署理服务器伪装成 MySQL 服务器，署理服务器担任与实在 MySQL 节点的对接，应用程序只和署理服务器对接。实在的数据库对事务体系是透明的。
在进行数据库扩展时，能够经过DBA配置数据表同步，并修正配置，完成JDBCUrl不变可是指向不同的实在物理数据库实例，做到事务体系不修正代码且无需上线完成滑润扩/缩容，这个进程可能会呈现秒级影响(数据库署理与新物理库建立衔接，该阶段对数据库的读写恳求进行堵塞，等候衔接切换结束)
前期规划中，能够将体系的TPS承载才能依照实践事务量级所需求的2-3倍进行规划，此时规划的数据分片为逻辑分片，而不同的逻辑分片数据能够存储在相同的物理分片中；这样在前期开展中，能够将不同的逻辑分片进行分组寄存，以进行实践的物理本钱操控；跟着事务的开展，需求更高的功能和容量支撑时，能够将存储在相同物理分片的逻辑分片数据迁出至新的物理数据库，然后提高体系功能。
比方：前期阶段体系高峰期只需求1万的TPS要求，在进行体系规划时能够直接依照2万，或许3万的TPS提早进行规划，假如单库可支撑每秒的修正为1000，那么至少需求将数据分为10个物理分片进行支撑，假如不考虑未来扩展，1个物理分片只对应1个逻辑分片，则只需求将数据拆分为10个逻辑分片，至此能够满意1万TPS需求。可是为了防止事务快速开展(参阅疫情期间，各大互联网买药渠道订单量量级几十倍的增长)，在实践规划时，规划的体系容量应该依照需求的2-3倍规划，所以这儿能够挑选规划30个逻辑分片，在前期不需求太多功能时，能够将每3个逻辑分片区分在同一个数据库物理分片上，即底层还是10个物理分片，实践上数据库功能仍然只能支撑1万TPS，本钱遍得到了操控；当需求扩展时，无需进行新的逻辑分片规划，只是只需求重视逻辑分片对应数据的物理分片数据搬迁。且无需修正代码和上线操作，事务体系彻底无感知。即在规划阶段，逻辑分片的数量往往大于物理分片数量。
四、常见高功能体系之读写别离架构
- 写库支撑水平扩展，当功能不足时，水平扩展底层数据库
- 非在线实时查询，比方事务分页查询，则读取经过DataBus同步数据的读库，这儿一般会冗余查询所用的字段，以支撑杂乱的查询条件
- 假如查询功能无法满意，能够经过添加索引、多级缓存等方法进行满意
- 该完成能够灵敏改变，从根本上处理连表查询问题
该架构即为CQRS体系架构，做到了真正的读写别离，且理论上能够支撑恣意的查询事务，且具有强壮的扩展才能。假如功能不够，则数据库水平扩容，假如查询需求不断改变，则不断新增异构数据战略，甚至能够作为事务侧的数据源中心。
当体系到达这种架构时，能够处理绝大部分(99%)的需求。可是假如从体系的完整性和稳定性上讲，该体系还会存在两个问题：
- 功能上：该体系的功能瓶颈在数据库上，当功能或许容量不足时则对数据库进行横向扩展，这样每个服务器就会产生新的数据库链接。假如你的事务满足庞大，会存在一种情况：单台机器所能衔接的数据库衔接到达了单机所能到达的TCP衔接数量极限，这时理论上体系也无法再进行扩展。
- 稳定性上：该体系暂时不具备容灾才能，假如数据中心产生火灾，断电，地震的问题，整个体系将无法正常供给服务
这儿为笔者提及一个技能，有兴趣的读者能够深化了解：Set化(也称体系单元化技能)。该技能前期是淘系最先选用，原因就是上文提到的单机与数据库的衔接数到达单机上限，无法再经过数据库水平扩展支撑事务开展。便引进Set化技能。 Set化技能与分库分表的将数据碎片化的实质思维是类似的，微观上只是路由战略从数据层上升到了应用层以及网关层，实质都是分治思维。Set化不仅能支撑功能、容量扩展，还能很好地支撑容灾，作为现代互联网公司基础设施被广泛选用推广中。在选用Set化技能时，还需求考虑哪些服务需求做Set化，哪些不必接入Set。这儿提一个概念：服务是否是具有状况的，即：服务是有状况服务还是无状况服务，有状况服务能够挑选做Set化，而无状况服务则无需做Set化，由于无状况意味着能够无限仿制扩展(比方网关服务等)。
五、分库分表所引进的问题
- 分片所引起的散布式事务问题(引申：无同享型数据架构)
- 跨分片连表、聚合、统计
- 扩容、缩容所引起的数据搬迁
六、引申
- 银行最基本的转账事务选用分库分表会呈现什么问题，怎么处理？
- 怎么处理查询维度改变不断改变、面向彻底不同的事务方(C端、B端等等)需求、功能及其吞吐量需求供给查询处理计划 ？
- 推荐了解：无同享数据架构、无锁化规划、高功能体系规划
七、参阅引用
- 分库分表
- 表数量2的n次方_分表与分库运用场景以及规划方法
- 理解分库分片
- 数据库秒级滑润扩容架构计划
- MySQL 分库分表及其滑润扩容计划
- 群众点评订单体系分库分表实践
