Spring Cloud 数据库篇----MySQL架构

      MySQL数据是关系型数据库，在不同的OLTP场景中有着很广泛的应用，使用的方式也是有很多种。从数据库的业务需求、架构设计、运营维护、迁移扩容，不同的应用场景有着不同的侧重点，这些侧重点适应于业务的场景或者是解决业务的问题。

首先会从MySQL的架构层面整理，具体的MySQL业务实践处理后面会继续提供出来。

一 、Mysql基础架构

(1)MySql单例架构

      MySQL单实例，就是在服务器上部署一个MySQL实例来对外提供服务，这是最开始接触MySQL数据库会使用的方式，也是常见学习、研究MySQL数据库的使用方式。

      Mysql的单例模式是Mysql使用的第一阶段，通常这种情况下Mysql数据可和应用程序在同一个服务器中。这种方式的好处就是部署和使用简单，之间通过编译安装或者二进制包解压安装，很快可以使用一个Mysql数据库环境。这种方式依赖性少不需要依赖其他第三方工具或者软件，维护也比较简单。

    这种方式使用起来比较简单，只是适合学习和开发环境使用，涉及到业务的使用就要考虑备份和灾备。

（2） MySql 主从架构（Master---slave）

   

      MySQL master-slave主从环境，是在MySQL单实例环境的基础上，将MySQL进行全库备份，再恢复出一个或多个MySQL实例，通过change master命令，指定新恢复出的MySQL实例，从那个MySQL节点上读取变化日志，并在本地应用，使新恢复的实例与原来的MySQL实例数据一致保持一致。所以，原来的数据一致变化的实例，叫master主节点；从master节点获取日志，并在本地应用，使数据与master阶段保持一致的节点，叫slave从节点；这样的架构环境，就叫 master-slave主从环境。

       Mysql的Master--slave数据库的架构，可使用线上数据有多份，实现了一定的数据备份功能，提高了数据库的性能、可用性和扩展性。Slave从库的数据只通过日志应用日志变化，一般不会主动更改数据，但是可以对外提供数据读取功能。Mysql的主从架构可以非常灵活，1个Master节点可以有1个或者多个slave节点；而一个slave节点，也可以当做其他节点的slave节点。如果一个slave节点后面还有其他节点作为这个节点的slave从节点，就叫级联复制

主从架构的拓展：读写分离

原理：1个Master配1个或者多个slave，使用的过程中写、更新、删除等数据操作全部在Master主数据库中，读数据则在slave从数据库中， 这样加大了数据的吞吐量，提高了数据操作效率。

常用的读写分离组件：Atlas、amoeba、cobar、MaxScale、Mysql-Proxy等

（3）Mysql MHA高可用架构

   主从架构虽然可以实现数据的多机备份，但是每个数据之间还是独立分开的。当Master主数据出现故障的时候，整个架构就瘫痪了。因此需要高可用 （内部组件故障仍可用） 的数据库集群MHA。

   数据库的高可用MHA建立在主从架构基础上，Master的固定IP，改为虚拟的VIP。应用通过VIP地址来操作数据库，当Master数据库宕机的时候，高可用组件会检测到宕机故障，这个时候就会找到含有最新binlog位置点的slave，通过中继日志将数据恢复到其他的slave，将包含最新binlog位置点的slave提升为master，将其他从库slave指向新的master原slave01 并开启主从复制，将保存下来的binlog恢复到新的master上提供数据库服务

二、业务需求架构

 前三种基础架构就已经能解决绝大数MySql场景和问题，但是随着业务需求的变化数据库的设计也逐渐不能满足。所以需要在基础架构上新增特殊业务的架构设计。

（1）MySQL+分布式Proxy 水平扩展

      场景：如果业务规模进一步扩大，读写量级尤其是写的量级达到非常大的地步，比如每秒数据写入几十万，甚至几百万，每天的数据量有几亿甚至几十亿的规模，这样的读写就远远不是一个master节点可以支撑的，这时就必须要进行扩展了。

一般Mysql 的扩展分为：

•   横向扩展（水平扩展） 不修改数据库的库表结构，而是对整体数据拆分不同分片，用更多的分片支撑更大量的请求
•   纵向扩展（垂直扩展） 将表和表分离或者是修改表的结构，按照访问的差异性将列拆分
•   分库分表                     通过策略分配将请求分配到不同数据库的相同表

这三种扩展方式可以分开使用也可以结合使用，但是对于高并发的请求，显然是横向扩展最为有效。下面就介绍横向扩展：

    一个服务器上的数据库和表的承载能力，受限于服务器的资源限制，即使提高硬件配置也会有瓶颈。但是使用一个中间件proxy代理数据库和表，代理层通过规则映射到多台服务器上的数据库和表，相当于使用多台服务器支撑数据服务。那么支撑的能力就和代理的服务器的个数成正比。服务器越多，支撑的访问量就会越大，性能也会越稳定。而这样的中间分片proxy，推荐MyCat，对底层分片可以几十、几百甚至是几千个。

   水平扩展有他对应的有点，但是在实际使用的过程中还是会有很多地方需要处理，水平扩展是分片策略实现，那么这个策略的片键选择、跨节点访问、分布式事务等问题，需要结合相应的业务去使用。

（2） TokuDB、MyRocks、InnoDB 高性能写入

    

    场景：MySQL数据库水平拆分，可以对于大数据量的读写进行线性扩展，但相应地底层服务器数量也需要比较多；但对于数据写入量非常大，数据读很少，数据总量大的情况，使用高性能写入架构，会更合适一些。

    业务数据写入量非常大，读取量非常高的情况，一般主要对数据insert写入性能，同时对数据压缩效率有特别高的要求。这种特殊的写入要求，需要对数据写入有特殊的优化和设计，并且有比较好的压缩效率和算法，能够将写入的大量数据进行压缩，节省空间。这种写入架构， 通常可以看做是MySQL数据库的一种特殊的存储引擎

      具体到实现而言，MySQL的高性能写入集群，可以使用TokuDB存储引擎。近几年Facebook也开源了其内部实现的MyRocks，可以作为高性能写入的存储引擎。MySQL默认的InnoDB存储引擎，在新的5.7及以后版本优化后，写入性能和压缩性能也有了更高的性能，也可以作为数据写入的一种选择。

（3）MySQL + 缓存（Memcached、Redis等）

      

场景：MySQL数据库水平拆分，可以对于大数据量的读写进行线性扩展，但相应地底层服务器数量也需要比较多；但对于数据写入量非常大，数据读很少，数据总量大的情况，使用高性能写入架构，会更合适一些。

      数据库缓存框架，适用于将少量的热数据放到内存中以此来提高访问的效率。因为从内存中的读取速度，远大于IO读取数据，cpu的消耗也会少很多。在业务场景中，用户请求数据，先在缓存中读取数据，魂村中有数据就直接响应。没有数据，则去数据库中获取数据，并将数据提交到缓存，以供下次访问。

     缓存系统常用的技术架构有Memcached 和Redis。Memcached是比较经典的缓存系统，在之前常与LAMP、LNMP流行架构结合使用。Redis是几年新兴的Key-Value键值型NoSQL数据库，除了作为缓存，还可以持久化作为Key-Value数据库使用。

（4）MySQL + 小文件系统（MongoDB、Ceph等） 大字段存取架构

      

      场景：在MySQL数据库中，通常是存储符合关系型数据库原理的小字段，比如数值型、字符型数据；但在实际环境中，除了这些常用字段，还会有一些大字段，比如用户头像这种图片文件、上传的音频、视频文件、帖子内容等大text字段，另外还有一些JSON文件、XML文件等，这些可以以二进制形式存储在MySQL数据库中，但读取和管理都会比较麻烦。这时，就可以使用小文件系统来结合MySQL来使用。

    小文件系统，是可以存储并快速访问结构化数据的系统。对于图片、音频、视频、TXT文件、JSON文件、XML文件等大字段，一般就只有简单的读写操作，将这些字段存入到小文件系统中，并将对应的访问链接存入到MySQL数据库的表中。这样通过数据库表，可以快速读写文件位置信息，在小文件系统中，通过文件位置信息，可以实现对大字段的快速读写访问。

具体实现而言，小文件系统也有很多技术软件，比较常见的有MongoDB文档型NoSQL数据库、Ceph分布式小文件系统等。

（5）MySQL + Inforbright/Greenplum 统计分析架构

场景：在MySQL数据库上实时响应业务需要的查询，通常是指OLTP业务，但对于已经产生的数据，场景：通常会在第二天之后，有结果汇总和统计分析需求。这类OLAP需求通常执行频率较低，但每次执行消耗的资源很大，如果与OLTP一样在一个系统上运行，就会造成这两大类业务的相互影响。这时就可以使用MySQL数据库与OLAP统计业务分类结合的架构。

MySQL产生了业务数据后，通常需要在第二天，要对前一天的数据进行各个角度、各个维度的统计、聚合、分析，以体现和反映业务的运营情况。这是让MySQL支持线上OLTP业务，通过数据流转程序，将每天产生的数据流转到离线的数据仓库系统中，在数据仓库系统中，进行各种数据统计分析、结果汇总，并将数据统计结果再流转到结果展示库中。这样就可以很好地实现线上OLTP和线下OLAP的结合使用和执行。

具体实现而言，对于MySQL数据库可以结合的OLAP数据仓库架构，可以选用Inforbright数据仓库，也可以选用 Greenplum分布式MPP数据库仓库。相对而言，Inforbright数据仓库比较轻量级，与MySQL使用类似；Greenplum分布式MPP数据仓库可以支撑海量数据的统计分析，功能、性能、容量等也比Inforbright要更强一下，成本也更大一些。

总结

      业务的开发，在MySQL的架构设计上来说，上面所述的是固定的架构，能应对一些普遍的业务，但是不要为了架构了而去强行的使用某些技术，按照自己的业务特性去设计会更好。

下面可以推荐一些架构的组合：

• MySQL+MHA高可用架构 与 MySQL分布式Proxy水平扩展架构 组合
• MySQL+MHA高可用架构 与 MySQL小文件系统大字段存取架构 组合
• MySQL+MHA高可用架构 与 MySQL缓存高并发读架构 组合
• MySQL分布式Proxy水平扩展架构 与 MySQL小文件系统大字段存取架构 组合
• MySQL分布式Proxy水平扩展架构 与 MySQL缓存高并发读架构 组合
• MySQL高性能写入架构  与 MySQL Inforbright/Greenplum统计分析架构 组合

下面会提供一个组合框架易工参考：

MySQL+MHA高可用架构 、MySQL分布式Proxy水平扩展架构、 MySQL缓存高并发读架构、 MySQL小文件系统大字段存取架构、MySQL Inforbright/Greenplum统计分析架构。