MySQL 高可用架构在业务层面的分析研究

前言：        

  相对于传统行业的相对服务时间 9x9x6 或者 9x12x5 。由于互联网电子商务以及互联网游戏的实时性，所以服务要求 7*24 小时，业务架构无论是应用还是数据库，都须要容灾互备，在 mysql 的体系中，最好通过在最開始阶段的数据库架构阶段来实现容灾系统。所以这里从业务宏观角度阐述下 mysql 架构的方方面面。

一。 MySQL 架构设计 — 业务分析

（ 1 ）读多写少

虚线表示跨机房部署，比方电子商务系统。一个 Master 既有读也有些写。对读数据一致性须要比較重要的。读要放在 Master 上面。

M(R) 仅仅是一个备库。仅仅有 M(WR) 挂了之后，才会切换到 M(R) 上，这个时候 M(R) 就变成了读写库。

比方游戏系统。有非常多Salve会挂载后面一个M(R)上面。

（ 2 ）读多写少 MMS- 电商

假设是电子商务类型的。这样的读多写少的。通常是 1 个 master 拖上 4 到 6 个 slave ，全部 slave 挂载在一个 master 也足够了。

切换的时候。把 M1 的读写业务切换到 M2 上面，然后把全部 M1 上的 slave 挂到 M2 上面去。例如以下所看到的：

（ 3 ）读多写少 MMSS- 游戏

假设是游戏行业的话，读非常多蛮明显的，会出现一般 1 个 Master 都会挂上 10 个以上的 Slave 的情况，所以这个时候。能够把一部分 Slave 挂载新的 M(R) 上面。

至少会降低一些压力，这样至少server挂掉的时候，不会对全部的slave有影响。另一部分在M(R)上的slave在继续，不会对全部的slave受到影响。见图3，

图 3

（ 4 ）读少写多

          意味着读并不会影响写的效率。所以读写都能够放在一个 M1(WR) ，而另外一个不提供读也不提供写，仅仅提供 standby 冗余异地容灾。

    这个异地容灾是非常重要的，否则假设是单机的，单边的业务。万一 idc 机房故障了，一般就会影响在线业务的。这样的 造成业务 2 小时无法应用，对于在线电子商务交易来说。影响是蛮大的，所以为了最大限度的保证 7*24 小时，必须要做到异地容灾， MM 要跨 idc 机房。尽管对资源有一些要求，可是对 HA 来说是必不可少的，一定要有这个 MM 机制。

          做切换的时候，把全部的读写从 M1 直接切换到 M2 上就能够了。

（ 5 ）读写平分秋色

读和写差点儿相同。可是读不能影响写的能力，把读写放在 M1(WR) 上，然后把一部分读也放在 M2(R) 上面，当然 M1 和 M2 也是跨机房部署的。

          切换的时候，把一部分读和全部写从 M1 切换到 M2 上就能够了。

二： MySQL 架构设计 — 常见架构

（ 1 ）强一致性

  对读一致性的权衡。假设是对读写实时性要求非常高的话。就将读写都放在 M1 上面。 M2 仅仅是作为 standby ，就是採取和上面的一（ 4 ）的读少写多的一样的架构模式。

          比方，订单处理流程。那么对读须要强一致性。实时写实时读，相似这样的涉及交易的或者动态实时报表统计的都要採用这样的架构模式

（ 2 ）弱一致性

假设是弱一致性的话。能够通过在 M2 上面分担一些读压力和流量，比方一些报表的读取以及静态配置数据的读取模块都能够放到 M2 上面。比方月统计报表，比方首页推荐商品业务实时性要求不是非常高。全然能够採用这样的弱一致性的设计架构模式。

（ 3 ）中间一致性

假设既不是非常强的一致性又不是非常弱的一致性，那么我们就採取中间的策略。就是在同机房再部署一个 S1(R) ，作为备库，提供读取服务。降低 M1(WR) 的压力，而另外一个 idc 机房的 M2 仅仅做 standby 容灾方式的用途。

当然这里会用到 3 台数据库server。或许会添加採购压力。可是我们能够提供更好的对外数据服务的能力和途径。实际中尽可能两者兼顾。

（ 4 ）统计业务

比方 PV 、 UV 操作、页数的统计、流量的统计、数据的汇总等等，都能够划归为统计类型的业务。

数据库上做大查询的统计是非常消耗资源的。统计分为实时的统计和非实时的统计。由于 mysql 主从是逻辑 sql 的模式，所以不能达到 100% 的实时。假设是 online 要严格的非常实时的统计比方像火车票以及金融异地结算等的统计， mysql 这块不是它的强项，就仅仅有查询 M1 主库来实现了。

A ，可是对于不是严格的实时性的统计， mysql 有个非常好的机制是 binlog ，我们能够通过 binlog 进行解析 Parser ，解析出来写入统计表进行统计或者发消息给应用端程序来进行统计。这样的是准实时的统计操作，有一定的短暂的可接受的统计延迟现象。假设要 100% 实时性统计仅仅有查询 M1 主库了。

通过 binlog 的方式实现统计，在互联网行业，尤其是电商和游戏这块，差点儿相同能够解决 90% 以上的统计业务。

有时候假设用户或者客户提出要实时read-time了，大家能够沟通一下为什么须要实时，了解详细的业务场景，有些可能真的不须要实时统计，须要有所权衡，须要跟用户和客户多次有效沟通。做出比較适合业务的统计架构模型。

B 。另一种 offline 统计业务。比方月份报表年报表统计等。这样的全然能够把数据放到数据仓库里面或者第三方 Nosql 里面进行统计。

（ 5 ）历史数据迁移

历史数据迁移。须要尽量不影响如今线上的业务，尽量不影响如今线上的查询写入操作，为什么要做历史数据迁移？由于有些业务的数据是有时效性的。比方电商中的已经完毕的历史订单等，不会再有更新操作了。仅仅有非常easy的查询操作。并且查询也不会非常频繁。甚至可能一天都不会查询一次。

          假设这时候历史数据还在 online 库里面或者 online 表里面。那么就会影响 online 的性能，所以对于这样的，能够把数据迁移到新的历史数据库上。这个历史数据库能够是 mysql 也能够是 nosql 。也能够是数据仓库甚至 hbase 大数据等。

          实现途径是通过 slave 库查询出全部的数据。然后依据业务规则比方时间、某一个纬度等过滤筛选出数据，放入历史数据库 (History Databases) 里面。迁移完了，再回到主库 M1 上，删除掉这些历史数据。

这样在业务层面，查询就要兼顾如今实时数据和历史数据，能够在filter上面依据迁移规则把online查询和history查询对接起来。比方说一个月之内的在online库查询一个月之前的在history库查询，能够把这个规则放在DB的迁移filter层和应用查询业务模块层。假设能够的话，还能够配置更细化。通过应用查询业务模块层来影响DB的迁移filter层，比方曾经查询分为一个月为基准。如今查询业务变化了，以15天为基准。那么应用查询业务模块层变化会自己主动让DB的filter层也变化。实现半个自己主动化，更加智能一些。

（ 6 ） MySQL Sharding

像 oracle 这样的基于 rac 基于共享存储的方式。不须要 sharding 仅仅须要扩从 rac 存储就能实现了。可是这样的代价相对会比較高一些，共享存储一般都比較贵。随着业务的扩展数据的爆炸式增长，你会不停累计你的成本，甚至达到一个天文数字。

眼下这样的 share disk 的方式，除了 oracle 的业务逻辑层做的非常完好之外其它的解决方式都还不是非常完美。

Mysql 的 sharding 也有其局限性。 sharding 之后的数据查询訪问以及统计都会有非常大的问题， mysql 的 sharding 是解决 share nothing 的存储的一种分布式的方法，大体上分为垂直拆分和水平拆分。

（ 6.1 ）垂直拆分

能够横向拆分。能够纵向拆分。能够横向纵向拆分。还能够依照业务拆分。

Mysql 库里面的横向拆分是指，每个数据库实例里面都有非常多个 db 库。每个 db 库里面都有 A 表 B 表。比方 db1 库有 A 表 B 表， db2 库里也有 A 表和 B 表，那么我们把 db1 、 db2 库的 A 表 B 表拆分出来，把一个库分成 2 个，就拆分成 db1 、 db2 、 db3 、 db4 ，其中 db1 库和 db2 库放 A 表数据， db3 库和 db4 库放 B 表的数据。 db1 、 db2 库里面仅仅有 A 表数据， db3 、 db4 库里面仅仅有 B 表的数据。

打个比方。作为电商来说。每个库里面都有日志表和订单表，假如 A 表是日志表 log 表， B 表是订单表 Order 表，一般说来写日志和写订单没有强关联性，我们能够讲 A 表日志表和 B 表订单表拆分出来。那么这个时候就做了一次横向的拆分工作。将 A 表日志表和 B 表订单表拆分开来放在不同的库，当然 A 表和 B 表所在的数据库名也能够保持一致 (PS ：在不同的实例里面 ) ，例如以下图所看到的：

 

PS ：这样的拆分主要针对于不同的业务对表的影响不大，表之间的业务关联非常弱或者基本上没有业务关联。拆分的优点是不相关的数据表拆分到不同的实例里面，对数据库的容量扩展和性能提高的均衡来说，都是蛮有优点的。

 

6.1.2 纵向拆分

          把同一个实例上的不同的 db 库拆分出来，放入单独的不同实例中。

这样的拆分的适应场景和要求是db1和db2是没有多少业务联系的，相似6.1.2里面的A表和B表那样。假设你用到了跨库业务同一时候使用db1和db2的话，个人建议要又一次考虑下业务，又一次梳理下尽量把一个模块的表放在一个库里面，不要垮库操作。

          这样的库纵向拆分里面。单独的库 db1 ，表 A 和表 B 是强关联的。例如以下图所看到的：

 

PS ：看到非常多使用 mysql 的人，总是把非常多没有业务关联性的表放在一个库里面，或者总是把非常多个的 db 库放在同一个实例里面，就像使用 oracle 那样就一个 instance 的概念而已。

Mysql 的使用一大原则就是简单，尽量单一。简单的去使用 mysql ，库要严格的分开；表没有关系的，要严格拆分成库。

这样的话扩展我们的业务就非常方便简单了，仅仅须要把业务模块所在的db拆分出来。放入新的数据库server上就可以。

 

6.1.3  横向纵向拆分

有些刚起步的，開始为了高速出产品，就把所以的库全部的表都放在一个实例上，等业务发展后，就面临着数据拆分。这里就会把横向纵向拆分结合起来，一起实现，例如以下图所看到的：

 

6.1.4  业务拆分

          跟水平拆分有点相似，可是有不同的地方。

比方一个供应商，可能整个站点上有10个供应商，一个站点上面每个供应商都有一定的量，并且供应商之间的数据量规模都差点儿相同的规模。那么这个时候就能够使用供应商的纬度来做拆分。

          比方 usern 库中， a 、 b 、 c 表都是强关联的，都有完整的业务逻辑存在。这里仅仅实用户（供应商）纬度是没有关联的。那这个时候就能够把数据以用户的纬度来进行拆分。

          就是用户 1 和用户 2 各自都有一套完整的业务逻辑，并且彼此之间不关联。所以就能够把用户 1 和用户 2 数据拆分到不同的数据库实例上面。眼下非常多互联网公司或者游戏公司有非常多业务都是以用户纬度进行拆分的。比方 qunaer 、 sohu game 、 sina 等。

（ 6.2 ） 水平拆分

          水平拆分相对要简单一些。可是难度偏大，会导致分布式的情况、跨数据的情况、跨事务的情况能够分为大概三类。 1 是历史数据和实时数据拆分， 2 是单库多表拆分， 3 是多库多表拆分。

6.2.1  实时数据历史数据的拆分

和历史数据迁移是一样的逻辑，就是要将 online 库的数据迁移到 listory 的数据库里面。对于实时的读写来说，数据是放在 online db 库里面，对于时间较远的数据来说。是放在历史 History DB 记录库里面的，这里的历史库能够是 mysql 也能够是别的 nosql 库等。

        

 

6.2.2  单库多表拆分

          主要不是解决容量问题，而是解决性能问题而扩展的，添加当前实例仅仅有一个 DB 。有一个大表。一个大表就把整个实例占满了，这个时候就不能拆分 db 了。由于仅仅有一个单表。这个时候我们就仅仅能拆表了，拆表的方式主要是解决性能问题，由于单个表越大，对于 mysql 来说遍历表的树形结构遍历数据会消耗很多其它的资源。有时候一个简单的查询就可能会引起整个 db 的非常多叶子节点都要变动。表的 insert 、 update 、 delete 操作都会引起差点儿全部节点的变更。此时操作量会非常大，操作的时候读写性能都会非常低，这个时候我们就能够考虑把大表拆分成多个小表，工作经历中是依照 hash 取模打散成 16 个小表。也有依照 id 主键 /50 取模打散到 50 个小表其中，下图实例是打散成 2 个小表。

 

6.2.3  多库多表拆分

          在单库多表的基础上，假设单库空间资源已经不足以提供业务支撑的话，能够考虑多库多表的方式来做，攻克了空间问题和性能问题。只是会有一个问题就是跨库查询操作，查询就会有另外的策略。比方说加一个 logic db 层来实现跨库跨实例自己主动查询。简单例如以下图所看到的：

 

6.2.4 水平拆分小结

水平拆分原则：

-- a.  尽量均匀的拆分维度。

-- b.  尽量避免跨库事务。

-- c.  尽量避免跨库查询。

设计：

--a 依据拆分维度，做 mod 进行数据表拆分，大部分都是取模的拆分机制，比方 hash 的 16 模原则等。

--b 依据数据容量。划分数据库拆分

数据操作

--a 跨事务操作：分布式事务，通过预写日志的方式来间接地实现。

--b 跨库查询：数据汇总 or 消息服务

6.2.5  案例说明

u  案例：

–      依照用户维度进行拆分成 64 个分库。 1024 个分表

?

       user_id%1024 拆分到1024张分表中

?

       每个分库中存放1024/64张分表

?       取模的时候，能够用 id 的最后 4 位数据或者 3 位数字来取模就能够了。

 

u  操作 1 ：採用 Configure DB

–      拆分之后的查询操作，做一个 Configure DB ，这个 DB 存放的是全部实例的库表的映射关系，当我 APP 发来有一个请求查询 user1 的数据。那么这个 user1 的数据是存放在上千个实例中的哪一个库表呢？这个关联信息就在 Configure DB 里面。 APP 先去 Configure DB 里面取得 user1 的关联系信息 ( 比方是存放在 d_01 库上的 t_0016 表里面 ) 。然后 APP 依据关联信息直接去查询相应的 d_01 实例的 t_0016 表里面取得数据。

 

u  操作 2 ：採用 Proxy

–      拆分之后的查询操作。做一个 Proxy 。 APP 訪问 Proxy ， Proxy 依据訪问规则就能够直接路由到详细的 db 实例。生成新的 sql 去操作相应的 db 实例。然后通过 Proxy 协议进行操作把操作结果返回给 APP 。

–      优势是 Proxy 和 db 实例是在一个网段。这样 Proxy 与 db 实例的操作的时间是非常短的。

u  操作 3 ：採用 Data Engine

–      拆分之后的查询操作，有一个 Data Engine Service ，这个 DES 里面配置了全部数据库实例的映射关系，须要在 APP 应用端安装一个 Agent ，是同步逻辑，在 JDBC 层实现， DES 能够实现读写分离，原理能够參考 TDDL 的实现。

6.3  集群管理

纵向扩容：一个实例拆分成多个实例，纵向拆分比較简单，改动的东西比較少，拆分的时候要通知到 Configure DB 或者 DES 。以免拆分之后查询不到数据或者数据录入不到新的 db 上面。例如以下图所看到的：

 

横向扩容：比較复杂，在纵向扩容成 2 个库的基础之上，再一次对库的表进行扩容，所以须要及时通知 Configure DB 和 DES 更细库和表的路由连接信息。

----------------------------------------------------------------------------------------------------------------

<版权全部，文章同意转载，但必须以链接方式注明源地址，否则追究法律责任!>
原文章地址： http://blog.csdn.net/mchdba/article/details/39810363

----------------------------------------------------------------------------------------------------------- -----

PS：来自学习MySQL MySQL数据库运维课程的收获。