分布式数据库架构

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 statusG

开启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:workspaceMycat-Server-Mycat-server-1675-releasesrcmain
#设置堆外内存大小
-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">8066property>

4.2、数据非分片

4.2.1、配置初始化信息

应用连接mycat的话，也需要设置用户名、密码、被连接数据库信息，要配置这些信息的话，可以修改server.xml，在其内部添加内容如下：



user name="mycat">
    
    property name="password">mycatproperty>
    
    property name="schemas">userdbproperty>
    
    
user>

4.2.2、配置虚拟数据库&表


DOCTYPE mycat:schema SYSTEM "schema.dtd">
mycat:schema xmlns:mycat="http://io.mycat/">

	
	
	
	
	schema name="userdb" checkSQLschema="true" dataNode="localdn" sqlMaxLimit="500">
		
		
		
		
		table name="tb_user" dataNode="localdn" primaryKey="user_id"/>
	schema>

	
	
	
	
	dataNode name="localdn" dataHost="localdh" database="user"/>

	
	
	
	
	
	
	
	
	
	
	
	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


DOCTYPE mycat:schema SYSTEM "schema.dtd">
mycat:schema xmlns:mycat="http://io.mycat/">

	
	
	
	
	schema name="userdb" checkSQLschema="true" dataNode="localdn" sqlMaxLimit="500">
		
		
		
		
		
		
		table name="tb_user" dataNode="localdn" primaryKey="user_id" subTables="tb_user$1-3" rule="mod-long"/>
	schema>

	
	
	
	
	dataNode name="localdn" dataHost="localdh" database="user"/>

	
	
	
	
	
	
	
	
	
	
	
	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>
        
        columns>user_idcolumns>
        algorithm>mod-longalgorithm>
    rule>
tableRule>


function name="mod-long" class="io.mycat.route.function.PartitionByMod">
		
		
		property name="count">3property>
	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


property name="sequnceHandlerType">0property>

property name="sequnceHandlerPattern">(?:(s*nexts+values+fors*MYCATSEQ_(w+))(,|)|s)*)+property>
property name="sequenceHanlderClass">io.mycat.route.sequence.handler.HttpIncrSequenceHandlerproperty>

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">1property>

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">3property>

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 位

* 一共 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">2property>

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。同时配置主从读写分离。


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">
    
    
    property name="count">2property>
function>

3）进行批量数据添加，可以发现数据落在了不同的库中。

4）读写分离验证

设置log4j2.xml的日志级别为DEBUG


Configuration status="DEBUG">
		........
        asyncRoot level="DEBUG" includeLocation="true">
			........
        asyncRoot>
    Loggers>
Configuration>

基于mysql服务进行数据查看，观察控制台信息，可以看到对于read请求的数据源，分别使用的是配置文件的配置。

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net

相关推荐: [Kotlin Tutorials 22] 协程中的异常处理

协程中的异常处理 Parent-Child关系如果一个coroutine抛出了异常, 它将会把这个exception向上抛给它的parent, 它的parent会做以下三件事情: 取消其他所有的children. 取消自己. 把exception继续向上传递…

分布式数据库架构分布式数据库架构

分布式数据库架构

1、MySQL常见架构设计

1.1、主从复制

1.1.1、主从复制搭建

1.1.2、 MySQL复制原理

异步复制执行流程

半同步复制执行流程

主从异步复制日志效果

1.1.3、主从半同步复制搭建

1.2、主主复制

1.2.1、主主复制搭建

1.3、级联复制架构

1.4、双主与级联复制结合架构

2、Mysql高可用实践

2.1、keepAlived高可用配置

3、数据切分核心思想

3.1、为什么要进行数据切分？

3.2、数据拆分方式

垂直拆分

水平拆分

数据切分带来的问题

3.3、Mycat中间件使用

Mycat特性

Mycat源码的本地部署运行

MyCat核心概念

4、Mycat企业级应用实践

4.1、环境参数配置

4.2、数据非分片

4.2.1、配置初始化信息

4.2.2、配置虚拟数据库&表

4.2.3 测试

4.3、根据ID取模数据分片

4.4、全局序列号

4.4.1、基于本地文件方式生成

4.4.2、基于数据库生成

4.4.3、基于zookeeper生成

7.4.4）基于时间戳生成

5、MyCat分库&读写分离

服务器托管，北京服务器托管，服务器租用，机房机柜带宽租用

分布式数据库架构

1、MySQL常见架构设计

1.1、主从复制

1.1.1、 主从复制搭建

1.1.2、 MySQL复制原理

异步复制执行流程

半同步复制执行流程

主从异步复制日志效果

1.1.3、 主从半同步复制搭建

1.2、主主复制

1.2.1、主主复制搭建

1.3、级联复制架构

1.4、双主与级联复制结合架构

2、Mysql高可用实践

2.1、keepAlived高可用配置

3、数据切分核心思想

3.1、为什么要进行数据切分？

3.2、数据拆分方式

垂直拆分

水平拆分

数据切分带来的问题

3.3、Mycat中间件使用

Mycat特性

Mycat源码的本地部署运行

MyCat核心概念

4、Mycat企业级应用实践

4.1、环境参数配置

4.2、数据非分片

4.2.1、配置初始化信息

4.2.2、配置虚拟数据库&表

4.2.3 测试

4.3、根据ID取模数据分片

4.4、全局序列号

4.4.1、基于本地文件方式生成

4.4.2、基于数据库生成

4.4.3、基于zookeeper生成

7.4.4）基于时间戳生成

5、MyCat分库&读写分离

服务器托管，北京服务器托管，服务器租用，机房机柜带宽租用

1.1.1、主从复制搭建

1.1.3、主从半同步复制搭建