分布式数据库架构
1、MySQL常见架构设计
对于mysql架构,一定会使用到读写分离,在此基础上有五种常见架构设计:一主一从或多从、主主复制、级联复制、主主与级联复制结合。
1.1、主从复制
这种架构设计是使用的最多的。在读写分离的基础上,会存在一台master作为写机,一个或多个slave作为读机。因为在实际的情况下,读的请求量一般是远远大于写请求的。
采用这种架构之后,当应用写入输入时,会把数据写入到master节点,然后由master节点将写入数据复制到slave节点上。
缺点:
- master单机故障
- 对master进行维护时,无法接收写请求
- master复制延迟,查询数据延迟
- slave提升为master后,可能会发生数据丢失(数据不一致)
1.1.1、 主从复制搭建
1、首先需要在两台机器上安装mysql镜像以及创建mysql容器
docker pull mysql:5.7
docker run --name mysql3307 -p 3307:3306 --privileged=true -ti -e MYSQL_ROOT_PASSWORD=123456 -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -v /home/mysql/docker-data/3307/conf:/etc/mysql/conf.d -v /home/mysql/docker-data/3307/data/:/var/lib/mysql -v /home/mysql/docker-data/3307/logs/:/var/log/mysql -d mysql:5.7
2、需要在两台机器上的/home/mysql/docker-data/3307/conf目录下,需要创建mysql的配置文件my.cnf。
my.cnf配置文件内容如下:
# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.7/en/server-configuration-defaults.html
[mysqld]
#
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
#
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
#
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M
#datadir=/home/mysql/docker-data/3307/data
#socket=/home/mysql/docker-data/3307/mysql.sock
character_set_server=utf8
init_connect='SET NAMES utf8'
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
#log-error=/home/mysql/docker-data/3307/logs/mysqld.log
#pid-file=/home/mysql/docker-data/3307/mysqld.pid
lower_case_table_names=1
#指定主机号,不允许出现重复
server-id=423307
#开启binlog
log-bin=mysql-bin
auto_increment_increment=2
auto_increment_offset=1
#rpl_semi_sync_master_enabled=1
#rpl_semi_sync_master_timeout=10000
3、在master的docker容器中添加mysql权限,开启备份机复制,并且设置备份用户信息。
#添加权限
GRANT REPLICATION SLAVE,FILE,REPLICATION CLIENT ON *.* TO 'repluser'@'%' IDENTIFIED BY '123456';
#刷新权限
FLUSH PRIVILEGES;
4、设置并刷新权限后,重启mysql服务器,可以查看master上的binlog信息。
show master status;
注意:至此上述步骤两台机器上都需要执行,参数上的设置按实际情况来定。
5、接着在slave中进入到mysql容器,设置master信息,用于标注当前slave的master是谁。
change master to master_host='localhost',master_port=3307,master_user='repluser',master_password='123456',master_log_file='mysql-bin.000002',master_log_pos=154;
参数解析
change master to master_host='master的ip',
master_port=master的端口号,
master_user='repluser',master_password='123456',
master_log_file='master中的binlob文件',
master_log_pos=master中的position位置信息;
6、设置完成后,还要开启slave中的IO和SQL线程,这两个线程主要用于slave中进行数据备份,可以先查看slave中这两个线程的状态。
show slave status\G
开启slave中的IO和SQL线程
start slave;
至此mysql主从复制搭建完成。
7、 相关状态信息的查看
查看slave中的binlog是否已经开启
show global variables like "%log%";
接着还可以查看master、slave中的进程信息
在master mysql中输入:
show processlist;
从上图中可以看出:master已经把所有的binlog发送给slave,并且等待更多的更新操作。
在slave mysql中输入:
show processlist;
从上图可以看出:在slave它已经连接到了master,正在等待master发送事件,并且slave已经读取了所有的relay log信息,并且正在等待更多的更新操作。
8、测试验证
连接主库,并在主库中创建数据库,创建数据库表以及添加行记录。此时会发现从库中也会创建相应的数据库和数据库表和行记录。
1.1.2、 MySQL复制原理
在mysql中,其有两种复制机制,分别是:异步复制、半同步复制。默认采用异步复制。(上述主从复制操作为异步复制)
异步复制执行流程
- 1、应用事务提交到master
- 2、master接收到应用事务提交请求后,会更新内部的binlog日志,接着让mysql引擎执行事务操作,并返回给客户端执行结果信息。同时在master中会存在一个事件监听,其会一直监听master中binlog日志文件的改变,一旦发现日志文件发生改变,则会触发dump线程。
- 3、dump线程被触发后,会通知slave中的IO线程现在有事务操作需要进行同步。
- 4、slave中IO线程接收到通知后,会从slave中relay-log.info文件中获取slave中的binlog日志文件和pos位置信息。接着会把这部分信息发送给master的dump线程。
- 5、master的dump线程接收到这些信息后,会根据slave发送的binlog日志文件和pos位置,将最新的binlog日志和pos位置后面的内容同步给slave的IO线程。
- 6、slave的IO线程接收到这些信息后,会将这部分内容同步到slave的relay-bin文件中。
- 7、当relay-bin文件发生改变后,会触发slave线程执行sql操作。(异步操作)
- 8、当slave向relay-bin写入完成后,还会向master返回一个ACK消息,通知slave已经执行成功。
总结:对于这一系列操作,可以发现master和slave在进行同步时是以异步的方式完成的,master写入完binlog后,会马上通过引擎进行事务提交并向客户端返回响应,对于与slave同步的操作,则是异步完成的。
虽然这种方式的RT很快,但是很容易出现数据不一致的情况。
半同步复制执行流程
- 半同步复制与异步复制的工作流程大体相似,但不同的是,当master中的binlog日志写入完成后,其不会马上通过引擎进行事务提交,而会处于等待,等到slave同步完成向master返回ACK通知后,才会唤醒等待,继续向下执行。
- 等待的时长,默认为10秒,但该时间可以配置。
- 半同步复制尽量的避免的主从数据不一致的情况,但是会造成吞吐量的降低。
对于这个问题,mysql也进行了解决,假设使用半同步复制进行备份时,slave节点挂掉了,那么当master等待10秒后,仍然会进行引擎提交,同时会将半同步复制切换为异步复制。等到slave节点重启后,又会自动的从异步复制切换到半同步复制。
主从异步复制日志效果
Mysql在进行复制操作时,默认是基于异步复制完成的。那为了更好的体会异步复制的效果,可以通过mysql日志来查看具体的复制过程效果。
启动主从两台Mysql服务器。
查看master的Mysql日志信息
docker logs -f mysql3307 | grep binlog_dump
根据当前查看的日志信息,在master中已经开启了dump线程连接到了id为273307的slave节点,并且该id就是在slave的mysql配置文件中设置的id。
同时pos内容包括当前的binlog日志和pos位置。
查看slave的mysql日志信息
根据slave中的日志信息,可以看到,当前slave中已经开启了relay-log日志,其对应文件信息就是xxxxx-relay-bin。其内部保存的就是slave中的相关binlog信息和pos位置信息。
同时在slave中也已经开启了SQL Thread,并且根据信息可以,它会从xxxx-relay-bin.000001文件的4位置开始复制。
同时在slave中也开启了IO Thread,其已经连接到master,并且会从master的binlog日志的154的位置开启复制。
查看master当前的binlog日志信息
#确定当前master正在使用的binlog日志文件
cat mysql-bin.index
#查看当前binlog日志文件内容
tail -f mysql-bin.000002
查看slave当前的日志信息
cat relay-log.info
cat master.info
cat xxxxxxxxxx-relay-bin.index
监控slave日志信息
tail -f 8122977f8b0a-relay-bin.000002
master中新增数据,触发主从同步
- 查看master修改前后的binlog日志
cat mysql-bin.000002
- 查看slave复制前后的relay-bin日志
tail -f 41dc8a520939-relay-bin.000002
1.1.3、 主从半同步复制搭建
1、配置
进入mysql容器,加载lib,主从节点都要配置,因为主从节点间会存在切换。
install plugin rpl_semi_sync_master soname 'semisync_master.so';
install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
查看插件信息
show plugins;
2、启用半同步(务必先启用从库,再启用主库)
#先启用从库,再启用主库
#从库:
set global rpl_semi_sync_slave_enabled= {0|1}; # 1:启用,0:禁止
#主库:
set global rpl_semi_sync_master_enabled= {0|1}; # 1:启用,0:禁止
set global rpl_semi_sync_master_timeout=10000; # 单位为ms
3、重启从库IO Thread
stop slave io_thread;
start slave io_thread;
4、截止到此已经完成半同步开启配置,可以查看主库状态信息和参数信息
#查询状态信息
show global status like "%sync%";
#查询参数信息
show global variables like '%sync%';
show global status like “%sync%”;
show global variables like ‘%sync%’;
根据上述的配置,当前主从两台服务器的复制方式已经改为半同步复制。接下来就可以来查看具体的效果。
- 正常的向master中添加数据,slave可以进行正常数据更新。
master打印日志信息如下: 开启半同步复制,关闭异步复制
- 关闭slave的IO Thread或者停止salve服务
再次向master中添加数据。此时可以发现,当进行数据提交时,会出现等待,过了十秒后,会对数据进行保存。同时slave中不会同步的进行数据更新。
如上图所示,超过时间后,半同步复制会转化为异步复制。此时复制机制就会由半同步复制转换为异步复制,当再次向master中添加数据,不会再次出现等待。
- slave中重新开启IO Thread。
异步复制会再次转换为半同步复制,其次,在slave IO Tthread关闭这段时间内的数据,会同步到slave中,不会出现数据丢失。
1.2、主主复制
对于主从复制来说,其内部会存在一台master以及一台或多台slave。但有一个非常明显的问题,master是单点存在。一旦master宕机,则无法进行数据的写入。为了解决这个问题,可以使用主主复制架构。
在主主复制架构中,会存在两台master,没有slave。并且会对这两台master进行读写分离,两台master会进行相互的复制。
主主复制架构图
在此架构中,两台master会进行双向复制,为什么这么做呢? 因为假设现在负责写的master宕机了,那么写的工作则会交给之前负责读的服务器来完成,相当于它即负责写又负责读。等到原先负责写的master恢复了,其在继续负责写工作。 反之亦然。因此才需要两者间进行双向复制。
此时缺点也非常明显,虽然master不存在单点了,但是对于读来说,如果并发量大的话,它肯定扛不住。对于主主复制架构来说,应用较少。
1.2.1、主主复制搭建
主主复制的搭建和主从非常类似,只不过主主复制会进行互指。
1、参照主从完成搭建。(按照上述主从复制结构搭建)
2、原slave端也要开启权限
#添加权限
GRANT REPLICATION SLAVE,FILE,REPLICATION CLIENT ON *.* TO 'repluser'@'%' IDENTIFIED BY '123456';
#刷新权限
FLUSH PRIVILEGES;
#重启mysql服务并查看binlog信息
show master status
3、在master这一端也要配置slave的相关配置
change master to master_host='localhost',master_port=3308,master_user='repluser',master_password='123456',master_log_file='mysql-bin.000002',master_log_pos=154;
start slave;
4、查看master和slave的进程列表:show processlist。可以发现他们现在互为主备。
master
slave
5、测试
当在两台服务器中添加数据,都可以完成双向同步。
1.3、级联复制架构
当读压力现在增大并且还想减小主从复制的性能消耗,可以采用级联复制架构。
写请求的入口仍为一个,但当master向slave进行复制时,对于slave可以分为多层, master只要向其中两台slave复制即可,然后再由slave将其数据复制到后面更多的slave中。
通过这种方式可以减轻master向slave复制的IO压力。
但是这种架构也存在一个弊端:slave的延迟会加大。
1.4、双主与级联复制结合架构
对于master在前面几种架构设计中,都存在单点问题, 对于master单点问题的解决,可以采用当前的架构。通过这种架构不仅可以解决master单点的问题,也可以解决slave延迟的问题。
2、Mysql高可用实践
以主主架构为例,现在不管写或者读,只要其中一个宕机,则会把它本身工作交给另外一台服务器完成。此时就需要对IP进行一个自动的指向。而且这种服务器IP切换,对于上层应用来说,应该是完全隐藏的,其无需知道当前是由谁来完成具体工作,其只需要来连接一个IP就可以。
对于这种需求,就需要通过keepAlived来完成IP的自动切换。
对于keepalived会在多台mysql服务器进行安装, 同时keepalived间也分为master和slave, 同时master会虚拟化一个VIP供应用进行连接。 如果一旦master挂掉后,会由slave节点继续工作,同时slave节点也会虚拟出相同VIP,供应用进行连接。
2.1、keepAlived高可用配置
1、安装keepalived
1. 下载keepalied安装包 http://www.keepalived.org/download.html
2. yum -y install openssl-devel gcc gcc-c++
3. mkdir /etc/keepalived
4. 上传安装包并解压 tar -zxvf keepalived-2.0.18.tar.gz
5. mv keepalived-2.0.18 /usr/local/keepalived
6. cd /usr/local/keepalived
7. ./configure && make && make install
8.创建启动文件
cp -a /usr/local/etc/keepalived /etc/init.d/
cp -a /usr/local/etc/sysconfig/keepalived /etc/sysconfig/
cp -a /usr/local/sbin/keepalived /usr/sbin/
2、编写执行shell脚本
进入/etc/keepalived。创建chk.sh,同时赋予执行权限:chmod +x chk.sh
#! /bin/bash
mysql -h 127.0.0.1 -u root -p123456 -P 3312 -e "show status;" >/dev/null 2>&1
if [ $? == 0 ]
then
echo " $host mysql login successfully "
exit 0
else
echo " mysql login faild"
killall keepalived
exit 2
fi
3、编写keepAlived配置文件
cd /etc/keepalived
vi keepalived.conf
! Configuration File for keepalived
#简单的头部,这里主要可以做邮件通知报警等的设置,此处就暂不配置了;
global_defs {
#notificationd LVS_DEVEL
router_id MYSQL_4 #唯一标识不允许出现重复
script_user root
enable_script_security
}
#预先定义一个脚本,方便后面调用,也可以定义多个,方便选择;
vrrp_script chk_haproxy {
script "/etc/keepalived/chk.sh"
interval 2 #脚本循环运行间隔
}
#VRRP虚拟路由冗余协议配置
vrrp_instance VI_1 { #VI_1 是自定义的名称;
state BACKUP #MASTER表示是一台主设备,BACKUP表示为备用设备【我们这里因为设置为开启不抢占,所以都设置为备用】
nopreempt #开启不抢占
interface ens33 #指定VIP需要绑定的物理网卡
virtual_router_id 11 #VRID虚拟路由标识,也叫做分组名称,该组内的设备需要相同
priority 130 #定义这台设备的优先级 1-254;开启了不抢占,所以此处优先级必须高于另一台
advert_int 1 #生存检测时的组播信息发送间隔,组内一致
authentication { #设置验证信息,组内一致
auth_type PASS #有PASS 和 AH 两种,常用 PASS
auth_pass 111111 #密码
}
virtual_ipaddress {
192.168.200.200 #指定VIP地址,组内一致,可以设置多个IP
}
track_script { #使用在这个域中使用预先定义的脚本,上面定义的
chk_haproxy
}
}
4、启动keepAlived
systemctl start keepalived
5、查看keepAlived执行状态
ps -ef|grep keepalived
6、可以通过tail -f /var/log/messages
7、查看ip信息,此时可以发现出现了配置的虚拟ip
ip a
8、测试
通过navicat使用虚拟IP连接mysql,当前连接IP为VIP。可以连接成功。
3、数据切分核心思想
3.1、为什么要进行数据切分?
当前微服务架构非常流行,很多都会采用微服务架构对其系统进行拆分。 而虽然产生了多个微服务,但因为其用户量和数据量的问题,很有可能仍然使用的是同一个数据库。
但是随着用户量和数据量增加,就会出现很多影响数据库性能的因素,如:数据存储量、IO瓶颈、访问量瓶颈等。此时就需要将数据进行拆分,从一个库拆分成多个库。
3.2、数据拆分方式
垂直拆分
垂直拆分是按照业务将表进行分类并分布到不同的数据节点上。在初始进行数据拆分时,使用垂直拆分是非常直观的一种方式。
垂直拆分的优点:
- 拆分规则明确,按照不同的功能模块或服务分配不同的数据库。
- 数据维护与定位简单。
垂直拆分的缺点:
- 对于读写极其频繁且数据量超大的表,仍然存在存储与性能瓶颈。简单的索引此时已经无法解决问题。
- 会出现跨库join。
- 需要对代码进行重构,修改原有的事务操作。
- 某个表数据量达到一定程度后扩展起来较为困难。
水平拆分
为了解决垂直拆分出现的问题,可以使用水平拆分继续横向扩展,首先,可以如果当前数据库的容量没有问题的话,可以对读写极其频繁且数据量超大的表进行分表操作。由一张表拆分出多张表。
在一个库中,拆分出多张表,每张表存储不同的数据,这样对于其操作效率会有明显的提升。而且因为处于同一个库中,也不会出现分布式事务的问题。
而拆分出多张表后,如果当前数据库的容量已经不够了,但是还要继续拆分的话,就可以进行分库操作,产生多个数据库,然后在扩展出的数据库中继续扩展表。
水平拆分的优点:
- 尽量的避免了跨库join操作。
- 不会存在超大型表的性能瓶颈问题。
- 事务处理相对简单。
- 只要拆分规则定义好,很难出现扩展性的限制。
水平拆分的缺点:
- 拆分规则不好明确,规则一定会和业务挂钩,如根据id、根据时间等。
- 不好明确数据位置,难以进行维护。
- 多数据源管理难度加大,代码复杂度增加。
- 也会存在分布式事务问题
- 数据库维护成本增加
数据切分带来的问题
- 按照用户ID求模,将数据分散到不同的数据库,具有相同数据用户的数据都被分散到一个库中。
- 按照日期,将不同月甚至日的数据分散到不同的库中。
- 按照某个特定的字段求模,或者根据特定范围段分散到不同的库中。
数据切分带来的核心问题
- 产生引入分布式事务的问题。
- 跨节点 Join 的问题。
- 跨节点合并排序分页问题。
3.3、Mycat中间件使用
当对数据拆分后会产生诸多的问题,对于这些问题的解决,可以借助于数据库中间件来进行解决,现在时下比较流行的是使用Mycat。
Mycat是一款数据库中间件,对于应用程序来说是完全透明化的,不管底层的数据如何拆分,应用只需要连接Mycat即可完成对数据的操作。同时它还支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流数据库。但是Mycat不会进行数据存储,它只是用于数据的路由。
其底层是基于拦截思想实现,其会拦截用户发送过来的SQL语句,首先对SQL语句做了一些特定的分析:如分片分析、路由分析、读写分离分析、缓存分析等,然后将此SQL发往后端的真实数据库,并将返回的结果做适当的处理,最终再返回给用户。
Mycat特性
- 支持SQL92标准
- 遵守Mysql原生协议,跨语言,跨平台,跨数据库的通用中间件代理。
- 基于心跳的自动故障切换,支持读写分离,支持MySQL主从,以及galera cluster集群。
- 支持Galera for MySQL集群,Percona Cluster或者MariaDB cluster
- 基于Nio实现,有效管理线程,高并发问题。
- 支持数据的多片自动路由与聚合,支持sum,count,max等常用的聚合函数。
- 支持单库内部任意join,支持跨库2表join。
- 支持通过全局表,ER关系的分片策略,实现了高效的多表join查询。
- 支持多租户方案。
- 支持分布式事务(弱xa)。
- 支持全局序列号,解决分布式下的主键生成问题。
- 分片规则丰富,插件化开发,易于扩展。
- 强大的web,命令行监控。
- 支持前端作为mysq通用代理,后端JDBC方式支持Oracle、DB2、SQL Server 、 mongodb 。
- 支持密码加密
- 支持服务降级
- 支持IP白名单
- 支持SQL黑名单、sql注入攻击拦截
- 支持分表(1.6)
- 集群基于ZooKeeper管理,在线升级,扩容,智能优化,大数据处理(2.0开发版)。
Mycat源码的本地部署运行
**源码下载:**https://codeload.github.com/MyCATApache/Mycat-Server/zip/Mycat-server-1675-release
默认端口:8066
配置启动参数:
-DMYCAT_HOME=D:\workspace\Mycat-Server-Mycat-server-1675-release\src\main
#设置堆外内存大小
-XX:MaxDirectMemorySize=512M
注意:为什么要设置堆外内存:当使用mycat对非分片查询时,会把所有的数据查询出来,然后把这部分数据放在堆外内存中
在Mycat有核心三个配置文件,分别为:sever.xml、schema.xml、rule.xml
- server.xml:是Mycat服务器参数调整和用户授权的配置文件。
- schema.xml:是逻辑库定义和表以及分片定义的配置文件
- rule.xml:是分片规则的配置文件,分片规则的具体一些参数信息单独存放为文件,也在这个目录下,配置文件修改需要重启MyCAT。
MyCat核心概念
在学习Mycat首先需要先对其内部一些核心概念有足够的了解。
- 逻辑库:Mycat中的虚拟数据库。对应实际数据库的概念。在没有使用mycat时,应用需要确定当前连接的数据库等信息,那么当使用mycat后,也需要先虚拟一个数据库,用于应用的连接。
- 逻辑表:mycat中的虚拟数据表。对应时间数据库中数据表的概念。
- 非分片表:没有进行数据切分的表。
- 分片表:已经被数据拆分的表,每个分片表中都有原有数据表的一部分数据。多张分片表可以构成一个完整数据表。
- ER表:子表的记录与所关联的父表记录存放在同一个数据分片上,即子表依赖于父表,通过表分组(Table Group)保证数据Join不会跨库操作。表分组(Table Group)是解决跨分片数据join的一种很好的思路,也是数据切分规划的重要一条规则
- 全局表:可以理解为是一张数据冗余表,如状态表,每一个数据分片节点又保存了一份状态表数据。数据冗余是解决跨分片数据join的一种很好的思路,也是数据切分规划的另外一条重要规则。
- 分片节点(dataNode):数据切分后,每一个数据分片表所在的数据库就是分片节点。
- 节点主机(dataHost):数据切分后,每个分片节点(dataNode)不一定都会独占一台机器,同一机器上面可以有多个分片数据库,这样一个或多个分片节点(dataNode)所在的机器就是节点主机(dataHost),为了规避单节点主机并发数限制,尽量将读写压力高的分片节点(dataNode)均衡的放在不同的节点主机(dataHost)。
- 分片规则(rule):按照某种业务规则把数据分到某个分片的规则就是分片规则。
- 全局序列号(sequence):也可以理解为分布式id。数据切分后,原有的关系数据库中的主键约束在分布式条件下将无法使用,因此需要引入外部机制保证数据唯一性标识,这种保证全局性的数据唯一标识的机制就是全局序列号(sequence),如UUID、雪花算法等。
4、Mycat企业级应用实践
4.1、环境参数配置
在server.xml 文件中的system标签下配置所有的参数,全部为环境参数,可以根据当前需要进行开启和配置,如:设置mycat连接端口号
<property name="serverPort">8066</property>
4.2、数据非分片
4.2.1、配置初始化信息
应用连接mycat的话,也需要设置用户名、密码、被连接数据库信息,要配置这些信息的话,可以修改server.xml,在其内部添加内容如下:
<!--配置自定义用户信息-->
<!--连接用户名-->
<user name="mycat">
<!--连接密码-->
<property name="password">mycat</property>
<!--创建虚拟数据库-->
<property name="schemas">userdb</property>
<!--指定该库是否只读-->
<!--<property name="readOnly">true</property>-->
</user>
4.2.2、配置虚拟数据库&表
<?xml version="1.0"?>
<!DOCTYPE mycat:schema SYSTEM "schema.dtd">
<mycat:schema xmlns:mycat="http://io.mycat/">
<!--配置虚拟数据库-->
<!--name:虚拟逻辑数据库名称,对应server.xml中的schemas属性值-->
<!--dataNode:逻辑库中逻辑表的默认数据节点-->
<!--sqlMaxLimit:类似于SQL上添加limit,如schema为非分片库,则该属性无效-->
<schema name="userdb" checkSQLschema="true" dataNode="localdn" sqlMaxLimit="500">
<!--配置虚拟逻辑表-->
<!--name:逻辑表名称,必须唯一-->
<!--dataNode:逻辑表所处的数据节点,值必须与dataNode标签中的name属性对应。如果值过多可以用$连接,如:dn$1-99,dn$200-400-->
<!--primaryKey:逻辑表对应的真实表的主键id的字段名-->
<table name="tb_user" dataNode="localdn" primaryKey="user_id"/>
</schema>
<!--配置dataNode信息-->
<!--name:当前datanode名称-->
<!--dataHost:分片节点所处的节点主机,该值必须与dataHost标签中的name属性对应-->
<!--database:当前数据节点所对应的实际物理数据库-->
<dataNode name="localdn" dataHost="localdh" database="user"/>
<!--配置节点主机-->
<!--balance:用于进行读操作指向,有三个值可选
0:所有读操作都发送到当前可用的writeHost上
1:所有读操作都随机的发送到readHost上
2:所有读操作都随机发送在writeHost与readHost上
-->
<!--maxCon:指定每个读写实例连接池的最大连接。也就是说,标签内嵌套的writeHost、readHost标签都会使用这个属性的值来实例化出连接池的最大连接数-->
<!--minCon:指定每个读写实例连接池的最小连接,初始化连接池的大小-->
<!--name:当前节点主机名称,不允许出现重复-->
<!--dbType:当时使用的数据库类型-->
<!--dbDriver:当前使用的数据库驱动-->
<!--writeType:用于写操作指向,有三个值可选
0:所有写操作都发送到可用的writeHost上
1:所有写操作都随机发送到readHost上
2:所有写操作都随机发送在writeHost与readHost上
-->
<!--readHost是从属于writeHost的,即意味着它从那个writeHost获取同步数据。
因此,当它所属的writeHost宕机了,则它也不会再参与到读写分离中来,即“不工作了”。这是因为此时,它的数据已经“不可靠”了。
基于这个考虑,目前mycat 1.3和1.4版本中,若想支持MySQL一主一从的标准配置,并且在主节点宕机的情况下,从节点还能读取数据。
则需要在Mycat里配置为两个writeHost并设置banlance=1。”-->
<!--switchType:设置节点切换操作,有三个值可选
-1:不自动切换
1:自动切换,默认值
2:基于mysql主从同步的状态决定是否切换
-->
<!--slaveThreshold:主从同步状态决定是否切换,延迟超过该值就不切换-->
<dataHost balance="0" maxCon="100" minCon="10" name="localdh" dbType="mysql" dbDriver="jdbc" writeType="0" switchType="1" slaveThreshold="1000">
<!--查询心跳-->
<heartbeat>select user()</heartbeat>
<!--配置写节点实际物理数据库信息-->
<writeHost url="jdbc:mysql://localhost:3306" host="host1" password="root" user="root"></writeHost>
</dataHost>
</mycat:schema>
4.2.3 测试
通过navicat创建本地数据库连接并创建对应数据库,同时创建mycat连接。 在mycat连接中操作表,添加数据,可以发现,本地数据库中同步的也新增了对应的数据。
4.3、根据ID取模数据分片
当一个数据表中的数据量非常大时,就需要考虑对表内数据进行分片,拆分的规则有很多种,比较简单的一种就是,通过对id进行取模,完成数据分片。
1)修改schema.xml
table标签新增属性:subTables、rule
<?xml version="1.0"?>
<!DOCTYPE mycat:schema SYSTEM "schema.dtd">
<mycat:schema xmlns:mycat="http://io.mycat/">
<!--配置虚拟数据库-->
<!--name:虚拟逻辑数据库名称,对应server.xml中的schemas属性值-->
<!--dataNode:逻辑库中逻辑表的默认数据节点-->
<!--sqlMaxLimit:类似于SQL上添加limit,如schema为非分片库,则该属性无效-->
<schema name="userdb" checkSQLschema="true" dataNode="localdn" sqlMaxLimit="500">
<!--配置虚拟逻辑表-->
<!--name:逻辑表名称,必须唯一-->
<!--dataNode:逻辑表所处的数据节点,值必须与dataNode标签中的name属性对应。如果值过多可以用$连接,如:dn$1-99,dn$200-400-->
<!--primaryKey:逻辑表对应的真实表的主键id的字段名-->
<!--subTables:分表的名称。可以存在多个,tb_user1,tb_user2,tb_user3.如果分表较多,可以通过$连接:tb_user$1-3-->
<!--rule:分片规则,对应rule.xml中配置-->
<table name="tb_user" dataNode="localdn" primaryKey="user_id" subTables="tb_user$1-3" rule="mod-long"/>
</schema>
<!--配置dataNode信息-->
<!--name:当前datanode名称-->
<!--dataHost:分片节点所处的节点主机,该值必须与dataHost标签中的name属性对应-->
<!--database:当前数据节点所对应的实际物理数据库-->
<dataNode name="localdn" dataHost="localdh" database="user"/>
<!--配置节点主机-->
<!--balance:用于进行读操作指向,有三个值可选
0:所有读操作都发送到当前可用的writeHost上
1:所有读操作都随机的发送到readHost上
2:所有读操作都随机发送在writeHost与readHost上
-->
<!--maxCon:指定每个读写实例连接池的最大连接。也就是说,标签内嵌套的writeHost、readHost标签都会使用这个属性的值来实例化出连接池的最大连接数-->
<!--minCon:指定每个读写实例连接池的最小连接,初始化连接池的大小-->
<!--name:当前节点主机名称,不允许出现重复-->
<!--dbType:当时使用的数据库类型-->
<!--dbDriver:当前使用的数据库驱动-->
<!--writeType:用于写操作指向,有三个值可选
0:所有写操作都发送到可用的writeHost上
1:所有写操作都随机发送到readHost上
2:所有写操作都随机发送在writeHost与readHost上
-->
<!--readHost是从属于writeHost的,即意味着它从那个writeHost获取同步数据。
因此,当它所属的writeHost宕机了,则它也不会再参与到读写分离中来,即“不工作了”。这是因为此时,它的数据已经“不可靠”了。
基于这个考虑,目前mycat 1.3和1.4版本中,若想支持MySQL一主一从的标准配置,并且在主节点宕机的情况下,从节点还能读取数据。
则需要在Mycat里配置为两个writeHost并设置banlance=1。”-->
<!--switchType:设置节点切换操作,有三个值可选
-1:不自动切换
1:自动切换,默认值
2:基于mysql主从同步的状态决定是否切换
-->
<!--slaveThreshold:主从同步状态决定是否切换,延迟超过该值就不切换-->
<dataHost balance="0" maxCon="100" minCon="10" name="localdh" dbType="mysql" dbDriver="jdbc" writeType="0" switchType="1" slaveThreshold="1000">
<!--查询心跳-->
<heartbeat>select user()</heartbeat>
<!--配置写节点实际物理数据库信息-->
<writeHost url="jdbc:mysql://localhost:3306" host="host1" password="root" user="root"></writeHost>
</dataHost>
</mycat:schema>
2)修改rule.xml
在schema.xml中已经指定规则为mod-long。因此需要到该文件中修改对应信息。
<tableRule name="mod-long">
<rule>
<!--当用用于id取模的字段-->
<columns>user_id</columns>
<algorithm>mod-long</algorithm>
</rule>
</tableRule>
<!--修改当前的分片数量-->
<function name="mod-long" class="io.mycat.route.function.PartitionByMod">
<!-- how many data nodes -->
<!-- 根据datanode数量进行取模分片,也就是要模几。 -->
<property name="count">3</property>
</function>
3)测试
-
向数据库中插入一千条数据,可以发现,其会根据id取模,放入不同的三张表中。
-
当根据id查询时,会通过对id的取模,确定当前要查询的分片。并且首先会先查询mycat中的ehcache缓存,再来查询数据分片。
-
当查询所有数据时,会查询所有数据分片。
4)缺陷
通过id取模分片这种方式实际中应用较少。主要因为两点问题:
根据id取模,1)散列不均匀,出现数据倾斜。2)动态扩容时,存在rehash,出现数据丢失。
1)数据散列不均匀,容易出现数据倾斜。每张表中的数据量差距较大。
2)动态扩容后,当需要新增表时,需要对模数修改,有可能就会造成当查询某个分片时,在该分片中找不到对应数据。
3)动态扩容后,要进行rehash操作。
4.4、全局序列号
当进行数据切分后,数据会存放在多张表中,如果仍然通过数据库自增id的方式,就会出现ID重复的问题,造成数据错乱。所以当拆分完数据后,需要让每一条数据都有自己的ID,并且在多表中不能出现重复。比较常见的会使用雪花算法来生成分布式id。
在Mycat中也提供了四种方式来进行分布式id生成:基于文件、基于数据库、基于时间戳和基于ZK。
4.4.1、基于本地文件方式生成
优点:本地加载,读取速度较快。
缺点:当MyCAT重新发布后,配置文件中的sequence会恢复到初始值。
生成的id没有含义,如时间。
MyCat如果存在多个,会出现id重复问题。
1)修改sequence_conf.properties
USER.HISIDS= #使用过的历史分段,可不配置
USER.MINID=1 #最小ID值
USER.MAXID=200000 #最大ID值
USER.CURID=1000 #当前ID值
2)修改server.xml
<!--设置全局序号生成方式
0:文件
1:数据库
2:时间戳
3:zookeeper
-->
<property name="sequnceHandlerType">0</property>
<!--进入序列匹配流程, 必须带有MYCATSEQ_或者 mycatseq_-->
<property name="sequnceHandlerPattern">(?:(\s*next\s+value\s+for\s*MYCATSEQ_(\w+))(,|\)|\s)*)+</property>
<property name="sequenceHanlderClass">io.mycat.route.sequence.handler.HttpIncrSequenceHandler</property>
3)测试
重启mycat,并查询是否修改成功
show @@sysparam
通过navicat插入数据
insert into tb_user(user_id,user_name) values('next value for MYCATSEQ_USER','wangwu')
通过程序插入数据
@Insert("insert into tb_user(user_id,user_name) values('next value for MYCATSEQ_USER',#{userName})")
void addUser(User user);
4.4.2、基于数据库生成
优点:能够进行id批量生成,在分布式下,可以避免id重复问题。
缺点:ID没有意义,对数据库有压力。
1)在实际数据库执行dbseq.sql中的sql语句,执行完毕后,会创建一张表。
2)修改sequence_db_conf.properties。
TB_USER=localdn
3)修改server.xml文件,修改全局序列号生成方式为数据库方式
<property name="sequnceHandlerType">1</property>
4)修改schema.xml。在table中添加自增属性
<table name="tb_user" dataNode="localdn" primaryKey="id" subTables="tb_user$1-3" rule="mod-long" autoIncrement="true"/>
5)测试
通过navicat新增记录
insert into tb_user(user_id,user_name) values('next value for MYCATSEQ_TB_USER','wangwu')
4.4.3、基于zookeeper生成
1)修改server.xml,更改生成模式
<property name="sequenceHandlerType">3</property>
2)修改myid.properties,配置zk连接信息
loadZk=true
zkURL=192.168.200.131:2181
clusterId=01
myid=mycat_fz_01
clusterNodes=mycat_fz_01
#server booster ; booster install on db same server,will reset all minCon to 1
#type=server
#boosterDataHosts=localhost1
3)修改sequence_distributed_conf.properties
INSTANCEID=ZK #声明使用zk生成
CLUSTERID=01
4)测试
启动mycatServer后,通过zk客户端查看节点信息。会发现新增了一个mycat节点
./zkCli.sh
ls /
插入数据
insert into tb_user(user_id,user_name) values('n
ext value for MYCATSEQ_TB_USER12','heima')
next value for MYCATSEQ_ 后的内容可以随意指定。
5)特性:
ID 结构:long 64 位,ID 最大可占 63 位
* |current time millis(微秒时间戳 38 位,可以使用 17 年)|clusterId(机房或者 ZKid,通过配置文件配置 5位)|instanceId(实例 ID,可以通过 ZK 或者配置文件获取,5 位)|threadId(线程 ID,9 位)|increment(自增,6 位)
* 一共 63 位,可以承受单机房单机器单线程 1000*(2^6)=640000 的并发。
* 无悲观锁,无强竞争,吞吐量更高
7.4.4)基于时间戳生成
优点:不存在上面两种方案因为mycat的重启导致id重复的现象,ID= 64 位二进制 (42(毫秒)+5(机器 ID)+5(业务编码)+12(重复累加),每毫秒可以并发 12 位二进制的累加。
缺点:数据类型太长,建议采用bigint(最大取值18446744073709551615)
1)修改server.xml。更改生成方式
<property name="sequenceHandlerType">2</property>
2)修改sequence_time_conf.properties
#sequence depend on TIME
#WORKID与DATAACENTERID: 0-31 任意整数。多mycat节点下,每个节点的WORKID、DATAACENTERID不能重复,组成唯一标识,总共支持32*32=1024 种组合
WORKID=01
DATAACENTERID=01
3)测试
新增数据
insert into tb_user(user_id,user_name) values('next value for MYCATSEQ_TB_USER12','heima')
next value for MYCATSEQ_ 后的内容可以随意指定。
5、MyCat分库&读写分离
之前已经基于id取模完成了分表操作,但是一个数据库的容量毕竟是有限制的,如果数据量非常大,分表已经满足不了的话,就会进行分库操作。
当前分库架构如下:
现在存在两个主库,并且各自都有从节点。 当插入数据时,根据id取模放入不同的库中。同时主从间在进行写时复制的同时,还要完成主从读写分离的配置。
1)修改schema.xml。配置多datenode与datahost。同时配置主从读写分离。
<?xml version="1.0"?>
<!DOCTYPE mycat:schema SYSTEM "schema.dtd">
<mycat:schema xmlns:mycat="http://io.mycat/">
<schema name="userdb" checkSQLschema="true" dataNode="dn09" sqlMaxLimit="500">
<table name="tb_user" dataNode="dn09,dn10" primaryKey="user_id" rule="mod-long"/>
</schema>
<dataNode name="dn09" dataHost="dh09" database="user"/>
<dataNode name="dn10" dataHost="dh10" database="user"/>
<dataHost name="dh09" balance="1" maxCon="100" minCon="10" dbType="mysql" dbDriver="jdbc" writeType="0" switchType="1" slaveThreshold="1000">
<!--查询心跳-->
<heartbeat>select user()</heartbeat>
<!--配置写节点实际物理数据库信息-->
<writeHost url="jdbc:mysql://192.168.200.142:3309" host="host1" user="root" password="123456">
<!--配置读节点实际物理数据库信息-->
<readHost host="host2" url="jdbc:mysql://192.168.200.145:3309" user="root" password="123456" ></readHost>
</writeHost>
</dataHost>
<dataHost name="dh10" balance="1" maxCon="100" minCon="10" dbType="mysql" dbDriver="jdbc" writeType="0" switchType="1" slaveThreshold="1000">
<!--查询心跳-->
<heartbeat>select user()</heartbeat>
<!--配置写节点实际物理数据库信息-->
<writeHost url="jdbc:mysql://192.168.200.142:3310" host="host1" user="root" password="123456">
<!--配置读节点实际物理数据库信息-->
<readHost host="host2" url="jdbc:mysql://192.168.200.145:3310" user="root" password="123456" ></readHost>
</writeHost>
</dataHost>
</mycat:schema>
2)修改rule.xml。配置取模时的模数
<function name="mod-long" class="io.mycat.route.function.PartitionByMod">
<!-- how many data nodes -->
<!-- 根据datanode数量进行取模分片,也就是要模几。 -->
<property name="count">2</property>
</function>
3)进行批量数据添加,可以发现数据落在了不同的库中。
4)读写分离验证
设置log4j2.xml的日志级别为DEBUG
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="DEBUG">
........
<asyncRoot level="DEBUG" includeLocation="true">
........
</asyncRoot>
</Loggers>
</Configuration>
基于mysql服务进行数据查看,观察控制台信息,可以看到对于read请求的数据源,分别使用的是配置文件的配置。文章来源:https://www.toymoban.com/news/detail-499699.html
文章来源地址https://www.toymoban.com/news/detail-499699.html
到了这里,关于分布式数据库架构的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!