共计 2968 个字符，预计需要花费 8 分钟才能阅读完成。
1. 垂直拆分
1.1 垂直分库
垂直拆分就是要把表按功能模块划分到不同数据库中，如果你的零碎是散布式微服务的架构，那就更好了解了，个别一个微服务对应这一个或多个数据库。比方电商零碎个别都会有用户核心、订单、商品等等。用户核心数据库存的都是用户信息相干的，商品数据库存的都是商品相干的数据，订单数据库则是存的订单相干的。
1.2 垂直分表
垂直分表是将一张数据表的字段，拆成两张或两张以上的数据进行寄存。这样做的目标一个是防止一张表存的字段太多，单条数据的数据量大，不仅会占用更多的物理内容，还会升高查问的性能。而且有些字段查问的不是很频繁，有些字段查问的很频繁，那咱们就能够将这查问频繁和查问不频繁的字段离开寄存。这样就能够防止磁盘进行不必要的 IO，进步零碎的性能。咱们个别都是把查问频繁的字段放到主表中，查问不频繁且不是很重要的字段放到扩大表中。主表和扩大表是 1 对 1 的关系，之间用主键进行关联。
1.3 垂直拆分优缺点
长处：
- 解决业务零碎层面的耦合，业务清晰。
- 与微服务的治理相似，也能对不同业务的数据进行分级管理、保护、监控、扩大等。
- 并发场景下，垂直切分肯定水平的晋升 IO、数据库连接数、单机硬件资源的瓶颈。
毛病： - 局部表无奈 join，只能通过接口聚合形式解决，晋升了开发的复杂度。
- 分布式事务处理简单。
- 仍然存在单表数据量过大的问题（须要程度切分）。
2. 程度拆分
当一个利用曾经依照垂直拆分，将数据库或数据表拆的粒度达到了最小，然而单表的数据行数微小，在进行数据库读写的时候，存储性能还是会很差，这个时候就须要进行程度拆分了。程度拆分又分为库内分表和分库分表，在进行程度分表的时候，须要依据表中存储的数据之间存在的逻辑关系进行拆分。能够依据表中的某个字段取分，比如说用户 id。也能够依据工夫去分，比方一个月分一次表。这些分表策略最终目标都是为了让单表的数据变小，从而加重数据表读写的 IO 压力。
2.1 库内分表
库内分表是在一个数据库中的某张表，数据行数达到了数据库读写性能的瓶颈的时候，将数据平摊到数据表构造一样的数据表中，已达到缩小单张表数据，晋升数据表读写性能的目标。
2.2 分库分表
库内分表只解决了一个库内单张表的压力，然而如果查问的比拟频繁的话，库内分表的那个数据库的整体性能还是很容易达到瓶颈。因为一个物理机的 CPU、内容、网络 IO 都是无限的，所以就须要多个库去分担单库的 IO 压力。
分库分表就是将原先单库分好的数据表，平摊到各个数据库中，目标就是为了加重单库的 IO 性能压力，正所谓人多力量大嘛。
3. 分表策略
3.1 按范畴拆分
依照 ID 区间来切分。例如：将 userId 为 1~9999 分到第一个库，10000~19999 的分到第二个库，以此类推。某种意义上，某些零碎中应用的 ” 冷热数据拆散 ”，将一些应用较少的历史数据迁徙到其余库中，业务性能上只提供热点数据的查问，也是相似的实际。
长处：
- 单表大小可控。
- 人造便于程度扩大，前期如果想对整个分片集群扩容时，只须要增加节点即可，无需对其余分片的数据进行迁徙。
- 应用分片字段进行范畴查找时，间断分片可疾速定位分片进行疾速查问，无效防止跨分片查问的问题。
毛病：
- 热点数据成为性能瓶颈。间断分片可能存在数据热点，例如按工夫字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查问。
3.2 取模分表
这种分表策略是我的项目中用的比拟多的，字段值取模分表的算法就是用某个字段的值进行取模，即 key%n，如果算数据落到哪个库中，则 n 是数据库的总数。如果算数据落到哪个表中，则 n 是数据表的总数。Key 就是你须要用来取模字段的值，这个能够个别都是依据你我的项目的业务去定义的，比方：key 是 userId，那这个人的数据必然会落入到同一个库中。须要留神的是这个 key 肯定要保障是全局惟一 id。
长处：
- 数据分片绝对比拟平均，不容易呈现热点和并发拜访的瓶颈。
毛病： - 前期分片集群扩容时，须要迁徙旧的数据（应用一致性 hash 算法能较好的防止这个问题）容易面临跨分片查问的简单问题。
3.3 工夫分表
依照工夫进行分表，这个表的拆分周期将会作为表的后缀名，比方按月分表，则表名个别都会跟着这个表是几年几月的。个别都会依据数据量大小决定工夫拆分的粒度，数据量有小到大对应的拆分的粒度则是时、日、月、年进行拆分。个别依照工夫来进行切分的数据，个别都是日志类的数据。这种数据个别都是查问一些创立工夫比拟近的数据，历史数据不会轻易查问。
长处：
- 单表大小可控
- 人造便于程度扩大，前期如果想对整个分片集群扩容时，只须要增加节点即可，无需对其余分片的数据进行迁徙。
- 应用分片字段进行范畴查找时，间断分片可疾速定位分片进行疾速查问，无效防止跨分片查问的问题。
毛病： - 热点数据成为性能瓶颈。间断分片可能存在数据热点，例如按工夫字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查问, 联表查问艰难。
以上总结的是几种比拟罕用的分库分表策略，还有其它的分库分表策略感兴趣的能够自行去理解。分库分表策略没有哪个是最好的，都是要依据本人的业务场景去抉择应用哪种分库分表策略
当初比拟风行的几种分库分表中间件有：shardingJDBC，mycat 等。把握一种就能够了，底层的原理都是一样的，概括起来的话就是拦挡 sql 语句，而后依据你配置的分库分表策略去改写 sql，路由到对应的数据库中。
4. 主从复制
以 mysql 为例，在进行 master 数据库数据的批改数据操作，数据库执行之后，都会将执行日志记录到本地，以二进制文件保留，也就是咱们所说的 bin-log。
假如 master 和 slave 数据配置好了主从关系，实时的对 master 的数据进行批改，master 数据库会通过 3306 端口，通过网络将 bin-log 同步给 slave 数据库。slave 执行的并不是二进制日志，因为它是从 master 的二进制日志复制过去的，并不是本人的数据库变动产生的，有点接力的感觉，称为中继日志，即 relay log。这就是所谓的 mysql 的复制，即 MYSQL replication。
能够发现，通过下面的机制，能够保障 master 和 slave 的数据库数据统一，然而工夫上必定有提早，即 MYSQL- B 的数据是滞后的。即使不思考什么网络的因素，master 的数据库操作是能够并发的执行的，然而 slave 只能从 relay log 中读一条，执行下。因而 master 的写操作很频繁，slave 很可能跟不上。
主从复制这块只须要晓得它的原理就行，因为配置主从复制有点偏运维，有专门的运维会去做这件事，开发不须要关怀。
5. 读写拆散
在数据库集群架构中，让主库负责解决事务性查问，而从库只负责解决 select 查问，让两者分工明确达到进步数据库整体读写性能。当然，主数据库另外一个性能就是负责将事务性查问导致的数据变更同步到从库中，也就是写操作。这就是数据库的读写拆散。
长处：
- 摊派服务器压力，进步机器的零碎解决效率
- 减少冗余，进步服务可用性，当一台数据库服务器宕机后能够调整另外一台从库以最快速度复原服务
** 感觉写的不错的，能够一键三连哦。想理解更多，或想要间接获取我的后续内容。
Gong#Zhong#Hao：java 干货仓库，发送【亿级零碎设计】。**
后续文章目录纲要：
