基于Mycat 的分布式技术在收集与分发系统中的应用

刘 洋，高 鹏，徐 娟，陈旭辉

（甘肃省气象信息与技术装备保障中心，甘肃 兰州 730020）

引言

随着科技的进步，气象数据的种类和数量在不断上升，由原来单一的、小规格的数据累积成了海量数据［1］。数据量的急剧增长会导致单机的存储能力严重不足，特别是在汛期，高频率的查询使单机的处理能力和响应性能严重的下降，数据不能实时入库，给用户的使用带来极大的不便，同时给数据库的管理者带来了很大的负担，而分布式数据库［2-3］是在集中式数据库基础上发展而来的，其最显著的特点就是数据分布在地理位置不同的机器上，但是所有的数据在逻辑上是集中管理的，分布式数据库的出现克服了传统集中式数据库的许多缺点，成为大数据处理和存储的方案之一［4-6］，分布式数据库已被广泛的应用到各行各业［7-9］。目前，气象业务中的收集与分发系统所采用的Mysql 数据库是单机版的，高并发的数据量会导致单机的存储能力和响应性能严重下降，极大的削弱了系统的服务能力。

针对现有数据库存在的问题，本文提出了基于Mycat 的分布式数据库集群架构，利用分布式存储中间件Mycat 对数据进行了读写分离，从而极大的提高了数据库的读写性能以及可扩展性；利用Haproxy［10-11］实现了Mycat 的高可用性；同时使用keepalived［12］实现了Haproxy 的高可用，解决了传统的集中式数据库单点故障的问题，保障了气象数据传输的稳定性和有效性。

1 基于Mycat 分布式数据库的设计

采用Mycat+Mysql+Haproxy+Keepalived 的技术架构来构建关系型分布式集群系统，其整体架构如图1 所示。为了保证系统的高性能、高并发和高可用，所有的模块都是基于集群进行构建，遵循自底向上的技术路线。

1.1 Mysql 数据库集群的实现

主从复制是实现Mysql 高可用性、负载均衡以及读写分离的基础，Mysql 的主从复制有多种形式，本文采用一主一从的形式，即一个写节点（Master）和一个读节点（Slave），写节点负责所有应用的写操作，读节点负责所有应用的读操作，一主一从的架构部署简单并且高效，不仅可以实现高可用，还能够实现读写分离，进而提升集群的并发能力。

图1 基于Mycat 的分布式集群架构

1.2 Mycat 实现Mysql 的读写分离和高可用性

Mycat 是基于阿里巴巴Cobar 项目的开源分布式数据库系统，其架构如图2 所示，Mycat 是介于数据库和应用之间，负责资源的调度和服务，后端是物理数据库，Mycat 支持Mysql，SQL Server，Oracle，DB2 等主流数据库。其原理是对用户发送的SQL 语句进行拦截，首先对SQL 语句做一些特定的分析，如路由分析、读写分离分析等，根据分析的结果，将对应的SQL 语句发送至后端的物理数据库，并将返回结果进行处理后再输出给用户，对用户而言Mycat 完全是透明的，为了防止Mycat 服务器单点故障，Mycat 的部署采用灾备方式，当其中的一台服务器宕机后，另外的一台会立即接管相应的服务，避免因单机故障导致服务中断，从而实现了Mycat 的高可用性。同时，Mycat 内置了一些功能，可以对后端真实的物理节点进行定期的检测，如果发现有故障节点，Mycat 可以进行节点之间的自动切换，从而提高了数据库的可靠性。

图2 Mycat 的原理架构图

1.3 Haproxy 实现Mycat 负载均衡和高可用性

Haproxy 是一款提供高可用和负载均衡的代理软件。为了实现Mycat 的高可用性，避免Mycat 服务器的单点故障，文中采用Haproxy 来检测Mycat 的存活，如果Haproxy 发现其中的某个Mycat 服务器已经宕机，它会把用户的请求自动转发到存活的Mycat 节点上，从而实现了Mycat 服务的高可用性，保证了服务的可靠性。同时，随着气象数据的越来越多，种类越来越复杂，单一的Mycat 节点承载能力有限，过多的数据量随时都有可能导致单个节点宕机，所以需要再增加一个Mycat 节点，在这种情况下，就必须要通过负载均衡来实现流量的合理调度。Haproxy 提供了多种负载均衡的算法，文中采用了最常用的轮询算法，Haproxy 会把请求轮询的转发到每一个服务器上，按照权重来分配。

1.4 Keepalived 实现Haproxy 高可用性

为了实现一个高性能，高可靠的分布式数据库服务系统，Haproxy 采用了热备模式，防止单节点故障的发生，文中利用Keepalived 并编写监测程序实时监控Haproxy 的健康状态，随时对故障进行转移，从而实现Haproxy 的高可用，Keepalived 主要是通过虚拟路由冗余协议实现高可用功能。

2 性能测试及分析

为了验证基于Mycat 的分布式数据库的性能，文中搭建了六台虚拟机并部署了分布式数据库测试环境，虚拟机的配置为CentOS-7.3.1611-x86_64，32Core，16G Mem。所有应用的部署都是在Windows 下通过Xshell 来实现的，所需要的依赖包都是通过Yum 方式进行安装。

2.1 Mysql 数据库读写分离和主从切换测试

读写分离，即把应用对数据库的读操作和写操作放在不同的节点上执行，其中写操作在Mysql 的主节点上执行，包括Insert，Delete，Update 操作，读操作在从节点上执行，包括Select 操作。在测试的过程中，开启debug 模式，进行Insert 语句和Select 语句操作，通过查看日志mycat.log 确认读和写SQL 被路由到哪个服务器上，从而实现了数据的读写分离。

主从切换，即当Mysql 的其中一个节点宕机之后会自动切换到备用节点上，读和写的操作全部由备用节点来承担。主从切换测试之前需要将dataHost 标签中的switchType 属性值设置为1，并配置心跳检测，停止Mysql 写节点服务之后，进行写和读操作，查看mycat.log 确认读和写的SQL 被路由到Mysql 的哪个节点上，测试结果可知当Mysql 写节点宕机之后，读和写的操作全部由Mysql 的从节点来承载，从而实现了主从切换。

2.2 Mycat 高可用性测试

Haproxy 是专门用来检测mycat 状态和进行负载均衡的软件，Haproxy 负责将请求分发到Mycat上，实现了Mycat 多节点的集群高可用和负载均衡，通过监听Mycat 服务器的48700 端口来实现，通过检测可知Mycat 状态是否正常，如果正常则显示为UP，如果异常则显示为DOWN，同时可以查看Mycat服务运行的时长。通过Haproxy 所在的其中一台服务器访问双机热备的mycat，本文选取第一台Haproxy 的服务器，对访问的几种可能性进行了测试，测试结果如表1 所示。从表1 可知Haproxy 只会将请求转发到存活的Mycat 上，Haproxy 会自动将宕机的Mycat 服务器从集群中移除，故障恢复后会自动将Mycat 服务器添加到集群中，Haproxy 这些操作对用户来说是完全透明的，即只要有一台Mycat 的服务器正常，用户都能够对数据进行访问。

表1 HAProxy 高可用性测试结果

2.3 Keepalived＋Haproxy 高可用性测试

为了避免Haproxy 服务单点故障，文中将Haproxy部署为双机热备模式，即当两个节点上的任何一个Haproxy 服务在线，都能够对外提供服务。Haproxy的高可用性是通过Keepalived 来实现的，Keepalived主要作用是负责抢占虚拟IP，抢占虚拟IP 有优先级，一般主服务器比备服务器的优先级高。通过模拟故障，对几种组合进行了测试，测试结果如表2，首先停止Haproxy 进程，然后通过虚拟IP 访问Haproxy 的Web 页面，检测该页面是否能够正常提供服务，比如，节点keep-ha-node1 上的Haproxy 服务停止后，通过虚拟IP 地址192.168.6.125（URL：http：／ ／192.168.6.125：8099／stats）访问Haproxy 的Web 页面正常，则表明当节点keep-ha-node1 的Haproxy 服务宕机之后，节点keep-ha-node2 上的Keepalived 抢占了虚拟IP，虚拟IP 漂移到节点keep-ha-node2 上，保证了服务不中断，实现了Haproxy 的高可用，其它组合情况测试类同。

2.4 分布式数据库读写性能测试

为了能够更准确的测试分布式数据库的性能，文中对单机Mysql 数据库和基于Mycat 的分布式数据库分别进行了性能测试，使用sysbench-0.5［13］作为压力测试工具，sysbench 是一个模块化的、跨平台和多线程基准测试工具，主要用于评估各种不同系统参数下数据库的负载情况。为了让测试结果更可靠，在整个测试过程中，不允许测试的虚拟机在物理机之间进行迁移，避免不同物理机对测试结果造成的影响。

表2 Keepalived＋HAproxy 高可用性测试结果

sysbench-0.5 对数据库OLTP 基准测试一般分为三个步骤：数据准备阶段；数据测试阶段；数据清理阶段。在数据准备阶段，共有10 张表，每个表插入1000 万行数据，数据都是随机产生的，10 张表的数据量大约为23GB，插入数据耗时26min。一般应用都会存在热点数据，同时innodb 引擎也是支持热点数据，所以在测试过程中需要开启热点模式，取5%的热点数据，压测时间为1800s，并发数依次递增｛8，16，32，64，128，256，512｝，每测试一个用例，需要清理主机的缓存和重启Mysql 实例，防止缓存影响其它测试结果，sysbench 压力测试工具中的脚本oltp.lua 中的参数oltp-read-only=on 表示只进行读操作，oltp-read-only=off 表示进行读写操作，本文共进行了两组基准压力测试，分别记录了TPS（Transactions Per Second，每秒处理的事务数）、QPS（Queries Per Second，每秒的查询数）、平均响应时间和95%的平均的响应时间，响应时间的单位为秒（s），在对每一个用例进行测试的同时要监控主机CPU、内存和磁盘IO 的使用情况，从而可以快速的定位系统性能的瓶颈。

2.4.1 基准测试一

基准测试一是对单机Mysql 数据库进行性能测试，使用压力测试工具中的oltp.lua 脚本，设置相关的参数，分别对Mysql 数据库进行只读操作和读写操作的压力测试，在测试的过程中，发现主机CPU的占有率非常高，使用perf 工具得知是热点函数_raw_spin_lock 和ut_delay 占用CPU 资源，这两个函数占用了78%的CPU 资源，这是由于锁的争用导致的。Mysql 提供了控制参数innodb_spin_wait_delay和innodb_sync_spin_loops 需要修改这两个参数的值，修改后CPU 的使用率降低了，对单机Mysql 只读压力测试结果如表3，对单机Mysql 读写压力测试结果如表4。

2.4.2 基准测试二

基准测试二是对基于Mycat 的分布式数据库进行性能测试，分布式数据库的架构为Mycat+Mysql+Haproxy+Keepalived，设置压力测试工具中oltp.lua脚本相关的参数，分别进行只读和读写压力测试，对分布式数据库只读的测试结果如表5 所示，对分布式数据库读写的测试结果如表6 所示。

表3 单机Mysql 只读压力测试

表4 单机Mysql 读写压力测试

表5 基于Mycat 分布式数据库只读压力测试

表6 基于Mycat 分布式数据库读写压力测试

2.5 结果分析

表3 和表5 分别是对单点数据库和分布式数据库只读压力测试的结果，从表3 可知，当并发量为128 时，Mysql 数据库的性能最佳，QPS 可以达到12.4 万，随着并发量的增加，QPS 和TPS 在逐渐减小。平均响应时间在不断的增加，数据库的性能在不断的下降，系统出现了瓶颈，单点的数据库已经无法应对高并发的数据量，从对比实验表5 可知，随着并发量的增加，TPS 和QPS 的值一直在递增，并发量越大，性能对比越明显，平均响应时间也要比单点数据库小很多，表明了分布式数据库的优越性。表4 和表6 分别是对单点数据库和分布式数据库混合读写压力测试的结果，从表4 可知，当并发量为256 时，Mysql 数据库的性能最佳，随着并发量增加，TPS 和QPS 在不断减小，平均响应时间在增加，单点的数据库性能已经出现了瓶颈，从对比实验表6 可知，随着并发量的增加，TPS 和QPS 的值一直在递增，在同等的并发条件下，数据库没有出现瓶颈，从而验证了分布式数据库集群架构Mycat+Mysql+Haproxy+Keepalived 有效性和可行性。

3 结论与讨论

为了避免收集与分发系统中Mysql 数据库单点故障的问题，文中设计了基于Mycat+Mysql+Haproxy+Keepalived 的高可用分布式关系型数据库集群系统，该架构具有Mycat 高可用、Haproxy 高可用、Mysql 高可用、Mysql 读写分离的特点，同时对Mysql单点数据库和基于Mycat 的分布式数据库进行了压力测试，从不同的指标评价了分布式数据库架构的性能，从测试结果可知该架构可以实现对二维关系型气象数据分散存储和并发访问服务。但是，随着气象数据的不断增加，对分布式数据库的弹性扩展和性能调优是必然的趋势。

因此，在未来的研究工作中主要从以下几个方面进行开展：（1）分布式数据库节点的扩容，即对数据库进行弹性扩展。（2）为了能够提高数据查询的吞吐量，考虑对数据库进行分库和分表。（3）为了增强访问的并发量，对Mycat 和Mysql 进行调优。