MySQL架构演进-从主从复制到分库分表

　　背景

业务飞速发展导致数据规模急速膨胀，单机的数据库已经无法满足互联网业务的发展。 传统的将数据集中存储单一数据结节的方案，在容量、性能、可用性和可维护性方面已经难以满足互联网海量数据的场景。 从容量方面考虑，单机数据库容量有限，难以扩容。 从性能方面来说，由于关系型数据库大多数采用B+树类型索引，在数据量超过一定的阈值后，索引的深度增加导致对磁盘的随机IO次数增加，进而导致性能问题。 从可用性方面来说，服务通常设计成无状态的，这必然导致系统的存储压力都集中在数据库层面，而单一的数据节点，或者简单的主从架构，已经越来越难以承担。 从运维角度来看，当数据都集中在一个节点上时，数据备份和恢复的时间成本也随之数据量上升变得不可控。同时数据丢失导致影响的范围也会被放大。

　　主从复制

　　主库将事务操作（除了查询以外的操作）记录到binlog

　　从库通过relay log同步数据，实现数据的同步

　　binlog日志格式

　　row 记录数据库操作详细记录，包括上线文信息等，文件较大。

　　statement 记录事务相关的SQL文件。

　　mixed 混合式, 基于row和statement两种文件格式。

　　异步复制

2000年，MySQL3.23.15版本引入复制功能，采用异步复制的方式，当网络或者机器故障，会导致数据不一致。

　　半同步复制

2010年, MySQL 5.5版本引入半同步复制, 半同步复制是指只要一个salve节点返回ack，master节点就可以提交事务了，保证数据库至少有一个节点完成了数据的同步。

　　组复制

2016年，MysQL在5.7.17中引入InnoDB Group Replication，该方案基于paxos协议实现组内复制，保证数据一致性，paxos协议核心在于过半选举。

　　主从复制的问题

　　主从复制延迟，导致"写完读"数据不一致问题。

　　从库读取失败，再去主库执行一遍SQL，存在性能问题。

　　业务层保证系统核心功能可用，将核心功能的CRUD操作都路由到主库，非核心业务功能即使存在短暂数据不一致也影响不大。

　　路由问题，需要业务层根据SQL路由到不同的数据库，路由到SLAVE节点时，还需要保证系统负载均衡。

　　业务层通过框架（如sharding-jdbc）或者手动实现，对业务的侵入性较大，已存在的旧系统改造不友好。

　　通过数据库中间件实现（如mycat、sharding-proxy），需要部署一个中间件（中间件实现SQL标准），规则配置在中间件，执行过程中会多一次网络转发。

　　不能保证系统高可用

　　通过一系列高可用的解决方案保证数据库高可用

　　数据库高可用

　　什么是高可用？

　　高可用意味着，更少的服务不可用的时间，一般用SLA(服务级别协议)衡量。

　　1年 = 365天 = 8760小时

　　99 = 8760 * 1% = 8760 * 0.01 = 87.6小时

　　99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时

　　99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟

　　99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟

　　为什么要做高可用？

　　通过故障转移，提供failover的能力，加上业务侧连接池的心跳重试，实现断线重连，业务不间断，降低RTO（Recovery Time Objective，复原时间目标）和RPO（Recovery Point Objective，复原点目标）。

　　容灾恢复：冷备和热备，冷备和热备的区别在于运行期间是否提供服务。

　　对于主从来说，简单的来说就是Master节点挂了，某一个从节点，自动切换成主。

　　从集群来看，即便是个别节点挂了，能正常对外提供服务。

　　常见的策略：

　　多实例部署

　　跨机房部署

　　两地三中心容灾高可用方案等。

　　手动切换

　　即如果主节点宕机，手动将某个从节点修改成主节点。

　　存在的问题：

　　可能数据不一致

　　需要人工干预

　　代码和配置的侵入性，需要配置其他节点，修改应用数据源的配置。

　　MHA

　　MHA全称叫做MySQL Master High Availability，是由Facebook工程师Yoshinori Matsunobu开发的一款MySQL高可用框架，基于Perl语言开发，一般能在30秒内实现主从切换，切换时通过SSH复制主节点的日志信息。

　　MHA负责MySQL主库的高可用，当主库发生故障时，MHA会选择一个数量最接近原主库的候选节点作为新的主节点，并且补齐和之前宕机的Master差异的Binlog。数据补齐后，即将写VIP漂移到新的主库上。具体的架构图如下：

　　优点

　　可以进行根据具体的故障实现自动检测和故障转移

　　扩展性好，可以任意的扩展数据节点数量

　　缺点：

　　极限情况下，可能会发生脑裂现象，出现多个Master。

　　需要配置SSH信息。

　　至少需要三台。

　　MGR

　　MGR是数据库支持的，只需要配置插件即可，如果主节点挂掉，将自动选择某个从改为主。无需人工干预，并且基于组复制（paxos算法），保证数据一致性。

　　MGR的特点

　　高一致性，基于分布式Paxos协议实现复制，保证数据一致性。

　　高容错性，自动检测机制，只要大多数节点都宕机的情况下，数据库可以继续工作，内置防脑裂保护机制。

　　高可扩展性，加入新节点后，自动实现增量同步，直到与其他节点数据一致。

　　高灵活性，提供了单主和多主模式，单主模式支持主节点宕机，自动选主，多主模式支持多节点写入。

　　MySQL InnoDb Cluster，一个完整的数据库高可用解决框架，由多个组件组成

　　MySQL Group Replication，提供DB的扩展，故障迁移

　　MySQL Router，轻量级中间件，提供应用程序连接目标的故障转移。

　　MySQL shell，新的MySQL客户端，多种接口模式，可以设置群组复制和Router。

　　Orchestrator

　　一款MySQL高可用和复制拓扑管理工具，支持复制拓扑结构的调整，自动故障迁移和手动切换的功能等，直接拖拽UI，就可以实现主从切换。

　　分库分表

　　分库分表通常是指垂直分库和水平分表，对于垂直分表其实就是将宽表拆分成小表，没有太多的技术挑战，这里侧重讲讲垂直分库和水平分表。

　　垂直分库

　　垂直分库是指将数据库进行纵向切分，通常按照业务的维度进行划分。

　　如典型的微服务的架构，将系统按照业务维度垂直拆分，划分成多个服务。如一个电商网站可以拆分成：订单、商品、会员、支付等服务。

　　垂直分库后业务更加单纯，职责单一，同时可以解决部分数据库容量问题，但是同时也引入了新的技术复杂度，如下：

　　分布式事务，跨数据库的事务操作需要分布式事务支持，否则系统将会面临数据不一致的问题。

　　方案一，采用XA事务，XA事务是数据库本身支持规范，具备强一致性的特征，但是性能比较差，对于追求高性能的场景不适合使用XA事务。

　　方案二，采用柔性事务，柔性事务是指，数据库保证局部事务，全局事务实现由业务层实现（如通过调度补偿，重试补偿，人工介入等），柔性事务常见的解决方案有：TCC、利用消息队列实现事务。

　　join问题，分库后，表分散到不同的数据库，无法直接使用SQL进行JOIN操作，需要业务层自己实现聚合操作，增加了开发成本。

　　水平分表

　　水平分表是指，将表按照某种规则分成多张表，拆分后的表结构和拆分前完全一致，但是数据分散到多张表中，也可以成为数据分片。

　　通过水平分表，解决了单表的容量和性能问题。但同时，水平分表后，引入了新的技术复杂度，主要有以下几点:

　　路由问题，当业务层通过SQL对数据库进行DML操作时，到底该查询那张表呢？

　　方案一：范围路由。根据表中某一列（分片键）的取值范围进行分表，如根据创建时间将主表分成多张表，每个月的数据单独存储在一个表中。范围路由可能出现数据分配不均匀的现象，但是表数量易于扩展。

　　方案二：哈希路由。根据表中某一列与分片数量取模运算(field_value % table_num)。hash路由和范围路由相反。表数量扩展时都会导致数据重新分布，但是数据分布较为均匀。

　　join问题，由于分表后，数据分散到多个表中，JOIN的条件语句中如果没有分片键，那么需要将全部的分片表都JOIN一遍，这种操作会存在性能问题。

　　count问题，分表后，如果需要统计表记录总和，需要遍历所有的表，然后再将结果进行汇总，可以通过一张单独的汇总表来解决，但这种解决方案需要每次insert或者delete的时候就需要更新汇总表，如果有一次没有更新，就会导致数据不一致。

　　order by问题，分表后，如果需要进行排序，需要遍历所有的表，然后在代码层进行重新排序，这个操作一看就会存在性能问题。

　　分库分表解决方案

　　业务代码层解决，可以通过SQL手动处理路由，但是和业务的耦合很严重，不易于维护。通常采用集成jar包的方式进行解决，如集成成熟的开源项目：sharding-jdbc。

　　数据库中间件，数据库中间件实现了对应数据库的SQL标准，路由规则配置在数据库中间件，业务代码操作数据库中间件和直接操作数据库没有任何区别。

　　总结

　　从单节点数据库到主从复制，再到数据库高可用，再到分库分表，很好的解决了数据的性能、容量、高可用、运维性等问题，但是会带来分布式事务、复杂SQL难以操作、SQL路由等问题。

　　架构设计应该遵循："简单性"、"合适性"、"演化性"的原则，符合当前的业务发展，所以系统设计没有必要一上来就考虑分库分表，而应该是数据量达到一定的量，出现性能瓶颈的时候再对系统进行改造和优化。

　　免责声明：

　　本公众号部分分享的资料来自网络收集和整理，所有文字和图片版权归属于原作者所有，且仅代表作者个人观点，与本公众号无关，文章仅供读者学习交流使用，并请自行核实相关内容，如文章内容涉及侵权，请联系后台管理员删除。