在讲ShardingSphere前,需要对mysql的主从架构有一些了解
1、为什么要主从架构?
1.如果主服务器出现问题,可以快速切换到从服务器提供的服务
2.可以在从服务器上执行查询操作,降低主服务器的访问压力
3.可以在从服务器上执行备份,以避免备份期间影响主服务器的服务1、M-S 2、M-S-S-S 3、M-M-M-S 4、MM 5、SSSS
2、有哪些主从方案?
1、M-S (一主一从)
2、M-S-S-S (一主多从)
3、M-M-M-S(多主一从)
4、MM (双主)
5、SSSS(全从)
每一种主从方案都要相对场景去使用。
数据同步方式:
1、GTID(底层也是基于bin-log)(基于事务方式,同步时做了一些优化)5.7版本之后支持
2、bin-log(1.5版本之后就支持了)
bin-log其实就是从节点去主节点拉取相应的逻辑文件(数据库操作文件),然后进行重放机制从而达到数据同步。
所以要进行数据同步需要master节点开启binlog。开启binlog即表示其他机器可以来我这拉取相应操作日志文件取同步数据。
3、主从复制大概流程:
1、大致流程:
主机每次进行写操作,都会将对应逻辑写到相应日志文件binlog中,然后通过dump线程去通知从节点去拉取。从节点拉取后会启用一个io线程将日志写入ralaylog文件中,然后再启动一个sql线程执行对应的逻辑。
2、主从复制的方式:
上面说到每次主机进行写操作会写到binlog中,那此时就有几个问题:
每次主机进行写操作是等从节点重放完成后主机点才去执行commit,还是主机先commit然后让从机异步去执行重放机制。
那么这就要涉及到主从复制的方式了。
1)、同步复制(Fully synchronized)
Mysql-Cluster
2)、异步复制(Asyn)mysql默认的复制方式
3)、半同步复制
半同步中有两种情况:一种是同步级别较高的——就是从机中必须要有一个副本的数据和主机一致才能ack
另一种就是同步级别较低的——就是上面图中的情况
如果半同步主机指定时间没有接收到任何ack,则会进行降级为异步复制。如果在指定时间又接收到ack了,则会切回半同步模式
但凡涉及到分布式,就需要有分布式事务的解决,那么如果此时commit失败,那么主从模式下的分布式事务是怎么解决的?(后面会讲)
4、高可用方案:
一、MMM高可用方案(基本不用了)
MMM(Master-Master replication managerfor Mysql,Mysql主主复制管理器)是一 套灵活的脚本程序,基于perl实现,用来对mysql replication进行监控和故障迁移,并能管 理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)
1.1 优点
(1)高可用性,扩展性好,出现故障自动转移,对于主主同步,在同一时间只提供一台数 据库写操作,保证数据的一致性。
(2)配置简单,容易操作。
1.2 缺点
(1)需要一台备份服务器,浪费资源
(2)需要多个虚拟IP
(3)agent可能意外终止,引起裂脑。
二、MHA方案
MHA服务,有两种角色, MHA Manager(管理节点)和 MHA Node(数据节点)。在 MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,目 前MHA主要支持一主多从的架构,要搭建MHA,要求一个复制集群中必须最少有三台数据 库服务器。
2.1 优点
(1)不需要备份服务器
(2)不改变现有环境
(3)操作非常简单
(4)可以进行日志的差异修复
(5)可以将任意slave提升为master
2.2 缺点
(1)需要全部节点做ssh秘钥
(2)MHA出现故障后配置文件会被修改,如果再次故障转移需要重新修改配置文件。
(3)自带的脚本还需要进一步补充完善,且用perl开发,二次开发困难。
5、分库分表
什么是分库分表?: 将一个表拆分多张表(库内分表与分库分表)
为什么需要分库分表?
1、微服务:基于业务,需要分拆需要分表2、读写分离
3、建索引,优化查询
4、换数据库oracle,sybase,db2
在上面几项做完后你发现仍然需要优化,此时就需要分库分表了(能不分尽量不分,不要过度拆分)
有哪些拆分方式?
1、横向拆分
数据量庞大的表:3000万条(B+树)- 树高过高,IO次数增加 拆成3张表结构一模一样的表:1000万条 (
表可以分区:可以解决数据量大的问题?高并发场景磁盘读写能力:300M/S,仍然没法解决)
而此时进行横向拆分会遇到一些问题:t_order->t_order_0,t_order_1 表主键怎么定义? 表怎么路由?
2、纵向拆分
拆库 根据业务拆!
拆分后产生的问题
1、扩库jion
2、主键重复问题
3、分页查询
4、关联查询
5、sum(distinct[colomn])
如果不同服务对应不同数据库,而每个数据库有相同的公共数据,此时则每个库会对应一张表,那此时如果要进行报表业务需要整合查询所有公共表的数据,此时就需要大量工作。
不过可以通过主从复制模式的特性去设计:此时设立一个从机然后去每个库的机器中读取logbin文件,则可以达到整合数据的效果。
彩蛋:面试官:你怎么设计强一致性的缓存和数据库数据一致性?
此时你或许会想:??,缓存和数据库一般不是保证最终一致性?面试官在搞我?
然而在一些金融项目中,可能有部分场景需要强一致性,那么此时就可以利用主从复制的同步复制方式进行了。
设计方案:使用阿里的cannl中间件读取主机的binlog文件然后传给mq集群,由mq的传给消费者,然后消费者对缓存数据进行修改,修改完成后返回ack,此时mysql才能进行commit操作。
其中使用mq是怕缓存操作失败,此时就可以使用mq再次发送。
好了,去看了ShardingSphere的官网才知道学习ShardingSphere(国人写的)不用多说什么,官网的中文文档非常详细且全,没必要去看其他的文章。
https://shardingsphere.apache.org/document/legacy/4.x/document/cn/overview/