一，引言
随着某公司的业务不断发展，目前没有一种数据库架构可以解决所有的应用接入问题，这取决于应用和业务本身的环境。为了更好的满足需求，如业务的发展、数据访问量的增加及成本等方面，从长远考虑，计划这些业务数据用免费的MySQL来存，但单机的MySQL往往无法直接抗住这些业务数据。为更好的满足应用、业务需求以及支撑未来的发展，本次采用基于关系型数据库mysql的架构进行分析，参考产品、研发人员的需求，讨论和选定具体使用哪种架构，以及研发人员在开发过程中一定遵循这6种mysql架构的哪些使用规则。做到研发人员透明的使用mysql数据库，不必关心数据库的并发、冗余、高可用等问题。

二， 现状以及需求分析
2.1 现有的数据平台架构
数据平台现有的应用程序在访问数据库时，只能连接一个数据库；而数据平台的这些数据库都有多个拷贝。应用程序只连接一个数据库会造成数据库的压力不均，有的数据库压力大，有的压力小，不能很好快速处理业务请求。针对这样的现状使用开源的负载均衡软件HAPROXY加以缓解，但是不能从根本上解决问题。
在相应的前端应用程序所在服务器上都部署haproxy。应用程序连接haproxy，haproxy将请求轮询到多个被复制的从数据库上。
2.2 数据平台haproxy存在的优缺点
在原有的数据平台上，部署了haproxy优化了访问不均衡的缺陷，以下是总结的几点优点：
a、因为haproxy和应用程序部署在同一台服务器上，所以应用可以通过127.0.0.1回环地址+端口的方式访问haproxy，这样可以减少网络流量。
b、haproxy此时的功能是把访问均衡分发到相同数据库不同服务器的功能。
c、haproxy有健康监测真实服务器的功能，当达到宕机条件时它不会再向这个服务器分发连接。
d、因为前端应用程序没有共用haproxy，所以当haproxy出现问题只是影响本机应用程序的访问。
e、这样使用haproxy的方案可以缓解mysql同步延迟的问题。
虽然均衡了访问请求至每个服务器上，但是还没有从根本上解决mysql主从延迟过大，使返回给客户的数据晚于实际数据，因公司是金融行情行业，实时性要求很高，延时带来的用户体验是非常不理想。以下是平台的haproxy的一些缺点总结：
a、haproxy和应用程序部署在一起，这样并没有改变原来客户的访问量。
b、haproxy没有经过大并发的压力测试，不知道大压力下效果会怎样。
c、前端应用程序和haproxy没有联调测试过，不能确定对所有的应用程序都能良好使用。
d、因为是刚开始使用，还有一个摸索期，后续可能出现的问题，无法预估和预防。
e、数据平台刚配合前端应用程序使用haproxy，部署该软件分散且多，维护成本比较大。
f、负责均衡连接数的haproxy存在单点故障风险，应用连接haproxy，若haproxy软件本身存在问题，在排查故障过程中，增加排除难度且影响业务。
2.3 需求分析
分析了数据平台现有的优缺点，在实际业务场景下就会有很多用户的痛点，亦结合目前的数据平台日常维护，常见问题如下：
（1）各业务线数据独立存储，数据在不同部门相互独立存储，独立维护，彼此间相互孤立，相互之间在功能上不关联互助、信息不共享互换，数据孤岛现象严重。
（2）访问量过大时，由于数据库架构不合理，导致各个实例上的连接数过大，数据落库延迟较大，用户体验不佳。
（3）有的业务线用户热度不大，连接数很少，造成物理资源浪费。
（4）多条业务线，数据独立部署，运维成本过高，运维人员的工作量也很大。

三，分析架构方案
根据不同业务场景和应用环境，我们设计了6种mysql部署架构。
3.1 mysql常规用法
3.1.1 拓扑图

3.1.2 使用场景
此架构主要用于应用程序记录简单日志和一些调度规则等等的事项，应用程序没有高的并发要求；应用程序在第一次读取数据记录后就不会在进行访问了，即使访问频度也有限；且数据记录变动也比较少。结合公司业务，例如，可用于存储BI部门的用户分析系统源数据的历史记录，这些源数据已经用于分析过的，作为公司的数据财富储备，可能目前由于技术、需求等原因，还有一些有价值的数据待挖掘，为后人留下数据资源。
3.1.3 实施
（1）机器硬件需求
a、最小部署单元：1台中间件层服务器+1台备份服务器
b、网络要求：中间层服务器要有内外网ip地址，数据库层只需要内网地址即可；网络带宽最好使用千兆交换机。
（2）使用规范
a、备份内容
一般情况下, 我们需要备份的数据分为以下几种：
数据
二进制日志, InnoDB事务日志
代码(存储过程、存储函数、触发器、事件调度器)
服务器配置文件
b、备份方式的选择：
根据不同的引擎，选择备份方式，依据mysql引擎使用率，先来介绍下Innodb和MyIASM这两种引擎。
Innodb引擎支持数据库ACID事务，并且实现了SQL标准的四种隔离级别，该引擎还提供了行级锁和外键约束。MyIASM是MySQL默认的引擎，它不支持数据库事务，也不支持行级锁和外键，因此当INSERT(插入)或UPDATE(更新)数据时需要锁定整个表，效率便会低一些。不过和Innodb不同，MyIASM中存储了表的行数，于是SELECT COUNT(*) FROM TABLE时只需要直接读取已经保存好的值而不需要进行全表扫描。如果表的读操作远远多于写操作且不需要数据库事务的支持，那么MyIASM也是很好的选择。两种引擎的主要区别：
1、MyIASM是非事务安全，InnoDB是事务安全
2、MyIASM锁的粒度是表级，InnoDB支持行级锁
3、MyIASM支持全文类型索引，InnoDB不支持全文索引
4、MyIASM相对简单，效率上要优于InnoDB，小型应用可以考虑使用MyIASM
5、MyIASM表保存成文件形式，可跨平台更加方便
6、应用场景不同，MyIASM管理非事务表，提供高速存储和检索以及全文搜索能力，如果再应用中执行大量select操作，应该选择MyIASM 。InnoDB用于事务处理，具有ACID事务支持等特性，如果在应用中执行大量insert和update操作，应该选择，InnoDB。
表引擎确定后，备份方式比较如表一所示：

c、备份工具
这里我们列举出常用的几种备份工具：
mysqldump : 逻辑备份工具, 适用于所有的存储引擎, 支持温备、完全备份、部分备份、对于InnoDB存储引擎支持热备
cp, tar 等归档复制工具: 物理备份工具, 适用于所有的存储引擎,冷备、完全备份、部分备份
lvm2 snapshot: 几乎热备, 借助文件系统管理工具进行备份
mysqlhotcopy: 名不副实的的一个工具, 几乎冷备, 仅支持MyISAM存储引擎
xtrabackup: 一款非常强大的InnoDB/XtraDB热备工具, 支持完全备份、增量备份, 由percona提供
3.2 master-slave复制
3.2.1 拓扑图

3.2.2 使用场景
此架构用于读写分离，写入数据应用程序和读取数据应用程序是相互独立的，读取的并发要求比较高，且业务连续性也相对较高。读写程序，例如行情中的分时ddx数据，基于公司level2的逐单分析功能，是一个短中线兼顾的技术指标，展示主力强度的一个数据参考，该数据是通过读取实时行情中的数据，二次计算然后结果写入mysql数据库主库。读取应用程序在产品开发中为最常见的，很多不同类型的行情展示即为只读应用。
3.2.3 实施
机器硬件需求：
a、最小部署单元：1台中间件层服务器+4台服务器做主从复制
b、中型部署单元：1台中间件层服务器+6台服务器做主从复制
c、网络要求：中间层要有内外网ip地址，数据库层只需要内网地址即可；网络带宽最好使用千兆交换机。
在读写程序或者只读程序之下，数据库层之上，我们姑且命名为中间件层。中间件层，可根据读写程序的并发量，读写程序和atlas部署关系一对一，atlas中的读选项配置多个haproxy地址。中间件层的haproxy部署多个，haproxy和mysql从库部署关系是一对多。
数据库层，如果是最小部署单位，1主4从，mysql顶层的主库复制2台从库，其中的从库之一又担任另外2台从库的主库（二级主库），若顶层主库故障，可切换至二级主库。
3.3 mysql cluster网络集群
3.3.1 拓扑图

3.3.2 使用场景
mysql ndb cluster是mysql的官方出品的分布式数据库部署架构，我们可以从MySQL的官网上下载到http://dev.mysql.com/downloads/cluster/，他的特点是高并发、高性能、高冗余。例如，主播房间送礼物的用户排名、主播的排行榜等，因实时性较强，存在二次运算才得到的结果，特别是主播的排名，会根据播放时长、收到的礼物、和观众互动等等计算系数二次计算，复杂的计算，且要求实时性，对数据库库性能要求极高，而往往性能越好，成本越高。mysql cluster集群是基于内存的，该架构适用于有产品价值，且对数据库性能要求较高的应用。
3.3.3 实施
机器硬件需求：
a、最小部署单元：1台中间件层服务器+4台服务器mysqlndb cluster
b、中型部署单元：1台中间件层服务器+8台服务器mysqlndb cluster
c、网络要求：中间层要有内外网ip地址，数据库层只需要内网地址即可；网络带宽一定要使用千兆交换机。
d、服务器要求：内存需求非常，因为数据都在内存。
3.4 mysql数据的分片
3.4.1 拓扑图

3.4.2使用场景
对超过1000万的超级大表可以做水平分割，可以均衡mysql服务器负载，适合大数据表的应用，例如，表数据量很大，表字段中有时间变量，且对该表操作时，大量涉及这个字段，可按月分片。亦可作为海量数据实时查询的一种简单有效方案，比如100亿条频繁查询的记录需要在3秒内查询出来结果，除了基于主键的查询，还可能存在范围查询或其他属性查询，此时Mycat可能是最简单有效的选择。
3.4.3实施
机器硬件需求
a、最小部署单元：1台中间件层服务器+1台服务器
b、中型部署单元：1台中间件层服务器+3台服务器
c、逻辑需求：对业务的要求比较苛刻，开发在处理数据时一定要遵循一定的规则
Mycat的使用，个人认为比较依赖业务，实施前需了解mycat，分析业务，再确定分表方案，然后再性能测试、约束编程，最后部署。
该拓扑图中是Mycat分片部署方案，其实不同的表用不同的存储方式也是可以的，例如表1用mysql，表2用Mongodb，表3用galera cluster等等，让不同的表根据其访问模式，都达到最佳状态。
3.5 mariadb的多源复制
3.5.1 拓扑图

多源复制是MySQL 5.7之后新增的功能之一，即可以实现多主一从的复制。
3.5.2 使用场景
适合大批的并发写入，也适合后期对数据做深层次的用户行为挖掘，实现数据汇总。例如，我们的主服务器进行了分库分表的操作，为了实现后期的一些数据统计功能，往往需要把数据汇总在一起再统计，多源复制可达到对从服务器进行数据汇总。我们还可以在从服务器上对主服务器的数据进行备份，在MySQL 5.7之前每一个主服务器都需要一个从服务器，这样很容易造成资源浪费，同时也加大了DBA的维护成本，利用多源复制可以把多个主服务器的数据同步到一个从服务器进行备份。
3.5.3 实施
机器硬件需求：
a、最小部署单元：3台服务器
b、中型部署单元：多台服务器
3.6 mysql环形复制
3.6.1 拓扑图

3.6.2 使用场景
应用程序有多节点写入服务器，且服务器的数据最终会一直，做到了高可用、高并发，但是数据同步是个问题，可能会慢各个服务的数据库在同一时刻会不同，还有一些特殊的字段类型要另行处理。
3.6.3 机器硬件需求
a、最小部署单元：1台中间件层服务器+2台服务器做环形复制
b、中型部署单元：1台中间件层服务器+4台服务器做环形复制
c、网络要求：中间层要有内外网ip地址，数据库层只需要内网地址即可；网络带宽最好使用千兆交换机。
中间件层，可根据读写程序的并发量，读写程序和atlas部署关系一对一，atlas中的读选项配置多个haproxy地址，atlas中的写选项可以配置多个mysql节点地址，因为写程序只要成功写入一个节点，则其他节点不再写入。中间件层的haproxy部署多个。
结构：A -> B -> C -> D -> A
最简单的，如果允许的话。 停止四台MYSQL 。然后让他们的数据全部一样。
3.7 部署过程分析
六种mysql部署方案步骤如下：
1、首先部署方案一（见2.1章节）和方案二（见2.2章节）架构。
2、对方案一、二做一定的并发等测试工作。
3、待方案一和方案二正式上线，我们在陆续上线其他方案；以适应不同的应用需求环境。
4、在使用方案一和方案二时我们要和开发多做沟通，尽力满足应用程序的环境，但是开发人员也要尽力配合程序向mysql数据库架构的规则靠拢。

四， 总结
鉴于公司属于互联网金融行业，选择mysql作为搭建统一存储服务的基础实例，无非是因为开源，免费，支持非WINDOWS操作系统（并且运行速度比在WINDOWS上还要快），速度快，支持二次开发（除有需要特定应用，一般是不需要二次开发的）等优点。根据公司的具体业务、现有物理资源，研究以上的架构方案，其使用场景各有不同，根据具体需求，合理选择，规范化分配资源，达到性能稳定且使用率高的统一存储服务平台。