MySQL服务演进

1

概述

• 当数据越来越多&＃xff0c;且增长速度很快&＃xff0c;尤其是并发量也越来越多时&＃xff0c;单点的数据库会出现性能瓶颈&＃xff0c;比如连接池连接数不够&＃xff0c;很多请求处于阻塞状态&＃xff0c;没有命中索引的查询非常耗时&＃xff0c;物理存储也会压力倍增

• 此时&＃xff0c;需要对数据库进行优化&＃xff0c;硬件层面&＃xff0c;增加CPU、内存和存储空间在前期能解决一定的问题&＃xff1b;

• 更多的&＃xff0c;需要通过软件层面来进行优化&＃xff0c;包括&＃xff1a;

• SQL调优&＃xff0c;如前面所讲&＃xff0c;排查出慢查询&＃xff0c;有针对性进行优化

• 表结构优化&＃xff0c;根据业务特性&＃xff0c;只返回表中合理数据&＃xff0c;或表根据业务拆分成多个表&＃xff0c;另外&＃xff0c;适当的冗余&＃xff0c;也能减少join&＃xff0c;提升查询性能

• 读写分离&＃xff0c;面向实际业务读多写少的实际情况&＃xff0c;使用binlog同步实现一主多从多个数据库实例&＃xff0c;提升性能

• 分库分表&＃xff0c;但数据量继续增加时&＃xff0c;尤其是单表数据超大&＃xff0c;比如超过500

2

业务演进...

• 就像一个公司是从小到大&＃xff0c;业务体量也是如此&＃xff0c;一般的&＃xff0c;一个业务系统正常演进如下&＃xff1a;

• 单业务系统--单数据库&＃xff1a;此时&＃xff0c;业务体量很小&＃xff0c;数据库承载量充分并有富余

• 多业务系统--单数据库&＃xff1a;这个阶段&＃xff0c;业务复杂度增大&＃xff0c;会将复杂的业务系统拆分成很多子业务系统&＃xff0c;数据库性能卓越&＃xff0c;还能继续支持多业务系统

• 多业务系统--多数据库&＃xff1a;即按业务分库、业务量继续增大&＃xff0c;数据库成为瓶颈&＃xff0c;将数据库按每个业务系统单独划分独立的数据库&＃xff0c;独立部署&＃xff0c;增加各个系统的业务承载能力&＃xff0c;整体业务的承载能力也增强&＃xff0c;微服务的处理模式就是这样

• 分库分表&＃xff1a;业务进入持续快速增长&＃xff0c;某些业务子系统的单个或多个业务表数据量超限&＃xff0c;通过硬件提升、单表的SQL优化、甚至时读写分离&＃xff0c;都不能有效提高查询或操作的性能&＃xff0c;就需要使用分表处理了&＃xff1b;主要有垂直分表和水平分表&＃xff0c;垂直分表是按业务特性&＃xff0c;单表只存放与业务相关的字段&＃xff1b;当数据量达到足够大时&＃xff0c;如超过500万条记录&＃xff0c;垂直分表性能提升有限&＃xff0c;最终还是要使用分库的水平分表

• 垂直分表&＃xff1a;按业务拆分成多个表结构&＃xff0c;使表结构更聚焦于业务&＃xff0c;减少查询返回数据量

• 水平分表&＃xff1a;表结构相同&＃xff0c;基于不同维度划分数据&＃xff0c;数据不相同&＃xff1b;又分单库分表和多库分表&＃xff0c;由于单库始终会有性能瓶颈&＃xff0c;所以常见为多库分表

业务演进过程

1

单应用-单DB

• 小型项目的常见业务形态

2

多应用-单DB

• 企业具备多种小项目常见的业务形态&＃xff0c;数据库服务需要性能相对较好

3

单应用-主从DB

• 中型复杂业务系统常见的模式&＃xff0c;将业务中的读操作、写操作针对不同的DB服务器&＃xff0c;提升业务系统容量

• 主、从DB服务器要有合理的数据同步机制

• 可以直接业务中切换&＃xff0c;也可以使用中间件

4

多应用-多DB

• 从业务的角度将应用、DB都做切分&＃xff0c;切分成粒度更小的多个应用&＃43;DB组合

• 微服务就是典型的多应用-多DB的模式

5

分库分表

• 当应用体量越来越大&＃xff0c;部分业务的单表数据超大&＃xff0c;如超过1000万条&＃xff0c;此时要考虑分库分表

• 分库分表给应用带来了很大的复杂性&＃xff0c;一般会使用像MyCat、ShardingSphere等中间件来处理&＃xff0c;给业务屏蔽DB的复杂性

►►►

如何分表&＃xff1f;

• 实现分表&＃xff0c;核心的就是根据业务找到一个合理的分表键&＃xff0c;一般要考虑几个条件&＃xff1a;

• 数据能尽量均匀的分布在不同的库或表&＃xff0c;并考虑业务增长的特性

• 跨度查询&＃xff0c;尤其是跨库join查询尽量少

• 该分表键尽量不会变动

• 常用的分表键划分(分区)策略有按范围、hash、hash&＃43;范围等

分表带来的问题

• 跨库关联查询&＃xff0c;如果在单库&＃xff0c;可以方便的使用join获取关联信息、生成需要的业务报表&＃xff0c;但分表后可能join的数据在另外一个库中&＃xff1b;一般使用适当冗余数据、所有库都存放全局表、使用集中数据仓库处理汇总业务&＃xff0c;以及在业务层组装等解决

• 分布式事务&＃xff0c;一个库中事务好处理&＃xff0c;跨库、跨业务的事务比较复杂&＃xff1b;可考虑在业务层面上使用消息中间件&＃xff0c;以及一些第三方组件Seata、TXLcn等使用两阶段提交方式处理

• 排序、分页、汇总等函数计算问题&＃xff0c;需要分库计算、然后汇总&＃xff0c;或是使用第三方组件

• 分布式ID&＃xff0c;分库分表后&＃xff0c;原有的表主键使用方式(如自增)可能会出现问题&＃xff0c;主要解决方式有&＃xff1a;UUID、号段模式、Redis缓存、雪花算法(SnowFlake)

第三方插件和中间件

• 分库分表后&＃xff0c;业务系统中实现对多个数据源的数据操作实际很复杂

• 有业界的第三方插件或中间件来解决前述分库分表带来的问题

• ShardingSphere&＃xff1a;Apache的开源的一个项目&＃xff0c;需要嵌入到业务系统代码中进行处理&＃xff0c;有基于Spring Boot的工具&＃xff0c;对代码有侵入

• MyCat&＃xff1a;是在业务系统与分库分表多数据源中间架设一个中间层来实现&＃xff0c;对代码无侵入

 福利