mysql 海量数据的存储和访问解决方案

第1章  引言

随着互联网应用的普遍普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，天天几十亿的PV无疑对数据库形成了至关高的负载。对于系统的稳定性和扩展性形成了极大的问题。经过数据切分来提升网站性能，横向扩展数据层已经成为架构研发人员首选的方式。水平切分数据库，能够下降单台机器的负载，同时最大限度的下降了了宕机形成的损失。经过负载均衡策略，有效的下降了单台机器的访问负载，下降了宕机的可能性；经过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；经过读写分离策略更是最大限度了提升了应用中读取（Read）数据的速度和并发量。目前国内的大型互联网应用中，大量的采用了这样的数据切分方案，Taobao,Alibaba,Tencent，它们大都实现了本身的分布式数据访问层（DDAL）。以实现方式和实现的层次来划分，大概分为两个层次（Java应用为例）：JDBC层的封装，ORM框架层的实现。就JDBC层的直接封装而言，如今国内发展较好的一个项目是被称做“变形虫”(Amoeba)的项目，由阿里集团的研究院开发，如今仍然处于测试阶段（beta版），其运行效率和生产时效性有待考究。就ORM框架层的实现而言，好比Taobao的基于ibatis和Spring的的分布式数据访问层，已有多年的应用，运行效率和生产实效性获得了开发人员和用户的确定。本文就是以ORM框架层为基础而实现的分布式数据访问层。本课题的难点在于分库后，路由规则的制定和选择以及后期的扩展性，好比：如何作到用最少的数据迁移量，达到扩充数据库容量（增长机器节点）的目的。核心问题将围绕数据库分库分表的路由规则和负载均衡策略展开。

第2章 基本原理和概念

2.1基本原理：

人类认知问题的过程老是这样的：what（什么）-?why(为何)-?how(怎么

作)，接下来，本文将就这三个问题展开讨论和研究：

2.1.1什么是数据切分

"Shard" 这个词英文的意思是"碎片"，而做为数据库相关的技术用语，彷佛最先见于大型多人在线角色扮演游戏中。"Sharding" 姑且称之为"分片"。Sharding 不是一门新技术，而是一个相对简朴的软件理念。众所周知，MySQL 5 以后才有了数据表分区功能，那么在此以前，不少 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具有分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(固然不是惟一指标)。数据库扩展性是一个永恒的话题，MySQL 的推广者常常会被问到：如在单一数据库上处理应用数据捉襟见肘而须要进行分区化之类的处理，是如何办到的呢? 答案是：Sharding。  Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。

经过一系列的切分规则将数据水平分布到不一样的DB或table中，在经过相应的DB路由 或者 table路由规则找到须要查询的具体的DB或者table，以进行Query操做。这里所说的“sharding”一般是指“水平切分”， 这也是本文讨论的重点。具体将有什么样的切分方式呢和路由方式呢？行文至此，读者不免有所疑问，接下来举个简单的例子：咱们针对一个Blog应用中的日志来讲明，好比日志文章（article）表有以下字段：

article_id(int),title(varchar(128)),content(varchar(1024)),user_id(int)

面对这样的一个表，咱们怎样切分呢？怎样将这样的数据分布到不一样的数据库中的表中去呢？其实分析blog的应用，咱们不可贵出这样的结论：blog的应用中，用户分为两种：浏览者和blog的主人。浏览者浏览某个blog，其实是在一个特定的用户的blog下进行浏览的，而blog的主人管理本身的blog，也一样是在特定的用户blog下进行操做的（在本身的空间下）。所谓的特定的用户，用数据库的字段表示就是“user_id”。就是这个“user_id”，它就是咱们须要的分库的依据和规则的基础。咱们能够这样作，将user_id为 1～10000的全部的文章信息放入DB1中的article表中，将user_id为10001～20000的全部文章信息放入DB2中的 article表中，以此类推，一直到DBn。 这样一来，文章数据就很天然的被分到了各个数据库中，达到了数据切分的目的。接下来要解决的问题就是怎样找到具体的数据库呢？其实问题也是简单明显的，既然分库的时候咱们用到了区分字段user_id，那么很天然，数据库路由的过程固然仍是少不了 user_id的。考虑一下咱们刚才呈现的blog应用，无论是访问别人的blog仍是管理本身的blog，总之我都要知道这个blog的用户是谁吧，也就是咱们知道了这个blog的user_id，就利用这个user_id，利用分库时候的规则，反过来定位具体的数据库，好比user_id是234，利用该才的规则，就应该定位到DB1，假如user_id是12343，利用该才的规则，就应该定位到DB2。以此类推，利用分库的规则，反向的路由到具体的DB，这个过程咱们称之为“DB路由”。

固然考虑到数据切分的DB设计必然是很是规，不正统的DB设计。那么什么样的DB设计是正统的DB设计呢？

咱们日常规规矩矩用的基本都是。日常咱们会自觉的按照范式来设计咱们的数据库，负载高点可能考虑使用相关的Replication机制来提升读写的吞吐和性能，这可能已经能够知足不少需求，但这套机制自身的缺陷仍是比较显而易见的（下文会说起）。上面提到的“自觉的按照范式设计”。考虑到数据切分的DB设计，将违背这个一般的规矩和约束，为了切分，咱们不得不在数据库的表中出现冗余字段，用做区分字段或者叫作分库的标记字段，好比上面的article的例子中的user_id这样的字段（固然，刚才的例子并无很好的体现出user_id的冗余性，由于user_id这个字段即便就是不分库，也是要出现的，算是咱们捡了便宜吧）。固然冗余字段的出现并不仅是在分库的场景下才出现的，在不少大型应用中，冗余也是必须的，这个涉及到高效DB的设计，本文再也不赘述。

2.1.2为何要数据切分

上面对什么是数据切分作了个概要的描述和解释，读者可能会疑问，为何须要数据切分呢？像 Oracle这样成熟稳定的数据库，足以支撑海量数据的存储与查询了？为何还须要数据切片呢？的确，Oracle的DB确实很成熟很稳定，可是高昂的使用费用和高端的硬件支撑不是每个公司能支付的起的。试想一下一年几千万的使用费用和动辄上千万元的小型机做为硬件支撑，这是通常公司能支付的起的吗？即便就是能支付的起，假若有更好的方案，有更廉价且水平扩展性能更好的方案，咱们为何不选择呢？

可是，事情老是不尽人意。日常咱们会自觉的按照范式来设计咱们的数据库，负载高点可能考虑使用相关的Replication机制来提升读写的吞吐和性能，这可能已经能够知足不少需求，但这套机制自身的缺陷仍是比较显而易见的。首先它的有效很依赖于读操做的比例，Master每每会成为瓶颈所在，写操做须要顺序排队来执行，过载的话Master首先扛不住，Slaves的数据同步的延迟也可能比较大，并且会大大耗费CPU的计算能力，由于write操做在Master上执行之后仍是须要在每台slave机器上都跑一次。这时候 Sharding可能会成为鸡肋了。 Replication搞不定，那么为何Sharding能够工做呢？道理很简单，由于它能够很好的扩展。咱们知道每台机器不管配置多么好它都有自身的物理上限，因此当咱们应用已经能触及或远远超出单台机器的某个上限的时候，咱们唯有寻找别的机器的帮助或者继续升级的咱们的硬件，但常见的方案仍是横向扩展, 经过添加更多的机器来共同承担压力。咱们还得考虑当咱们的业务逻辑不断增加，咱们的机器能不能经过线性增加就能知足需求？Sharding能够轻松的将计算，存储，I/O并行分发到多台机器上，这样能够充分利用多台机器各类处理能力，同时能够避免单点失败，提供系统的可用性，进行很好的错误隔离。

综合以上因素，数据切分是颇有必要的，且咱们在此讨论的数据切分也是将MySql做为背景的。基于成本的考虑，不少公司也选择了Free且Open的MySql。对MySql有所了解的开发人员可能会知道，MySQL 5 以后才有了数据表分区功能，那么在此以前，不少 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具有分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(固然不是惟一指标)。数据库扩展性是一个永恒的话题，MySQL 的推广者常常会被问到：如在单一数据库上处理应用数据捉襟见肘而须要进行分区化之类的处理，是如何办到的呢? 答案也是Sharding，也就是咱们所说的数据切分方案。

    咱们用免费的MySQL和廉价的Server甚至是PC作集群，达到小型机+大型商业DB的效果，减小大量的资金投入，下降运营成本，何乐而不为呢？因此，咱们选择Sharding，拥抱Sharding。

2.1.3怎么作到数据切分

说到数据切分，再次咱们讲对数据切分的方法和形式进行比较详细的阐述和说明。

数据切分能够是物理 上的，对数据经过一系列的切分规则将数据分布到不一样的DB服务器上，经过路由规则路由访问特定的数据库，这样一来每次访问面对的就不是单台服务器了，而是N台服务器，这样就能够下降单台机器的负载压力。

数 据切分也能够是数据库内的 ，对数据经过一系列的切分规则，将数据分布到一个数据库的不一样表中，好比将article分为article_001,article_002等子表，若干个子表水平拼合有组成了逻辑上一个完整的article表，这样作的目的其实也是很简单的。 举个例子说明，好比article表中如今有5000w条数据，此时咱们须要在这个表中增长（insert）一条新的数据，insert完毕后，数据库会针对这张表从新创建索引，5000w行数据创建索引的系统开销仍是不容忽视的。可是反过来，假如咱们将这个表分红100 个table呢，从article_001一直到article_100，5000w行数据平均下来，每一个子表里边就只有50万行数据，这时候咱们向一张只有50w行数据的table中insert数据后创建索引的时间就会呈数量级的降低，极大了提升了DB的运行时效率，提升了DB的并发量。固然分表的好处还不知这些，还有诸如写操做的锁操做等，都会带来不少显然的好处。

综上，分库下降了单点机器的负载；分表，提升了数据操做的效率，尤为是Write操做的效率。 行文至此咱们依然没有涉及到如何切分的问题。接下来，咱们将对切分规则进行详尽的阐述和说明。

上文中提到，要想作到数据的水平切分，在每个表中都要有相冗余字符 做为切分依据和标记字段，一般的应用中咱们选用user_id做为区分字段，基于此就有以下三种分库的方式和规则： （固然还能够有其余的方式）

按号段分：

(1) user_id为区分，1～1000的对应DB1，1001～2000的对应DB2，以此类推；

优势：可部分迁移

缺点：数据分布不均

(2)hash取模分：

对user_id进行hash（或者若是user_id是数值型的话直接使用user_id 的值也可），而后用一个特定的数字，好比应用中须要将一个数据库切分红4个数据库的话，咱们就用4这个数字对user_id的hash值进行取模运算，也就是user_id%4,这样的话每次运算就有四种可能：结果为1的时候对应DB1；结果为2的时候对应DB2；结果为3的时候对应DB3；结果为0的时候对应DB4，这样一来就很是均匀的将数据分配到4个DB中。

优势：数据分布均匀

缺点：数据迁移的时候麻烦，不能按照机器性能分摊数据

(3)在认证库中保存数据库配置

就是创建一个DB，这个DB单独保存user_id到DB的映射关系，每次访问数据库的时候都要先查询一次这个数据库，以获得具体的DB信息，而后才能进行咱们须要的查询操做。

优势：灵活性强，一对一关系

缺点：每次查询以前都要多一次查询，性能大打折扣

以上就是一般的开发中咱们选择的三种方式，有些复杂的项目中可能会混合使用这三种方式。 经过上面的描述，咱们对分库的规则也有了简单的认识和了解。固然还会有更好更完善的分库方式，还须要咱们不断的探索和发现。

第3章 本课题研究的基本轮廓

上面的文字，咱们按照人类认知事物的规律，what?why?how这样的方式阐述了数据库切分的一些概念和意义以及对一些常规的切分规则作了概要的介绍。本课题所讨论的分布数据层并不只仅如此，它是一个完整的数据层解决方案，它究竟是什么样的呢？接下来的文字，我将详细阐述本研究课题的完整思想和实现方式。

分布式数据方案提供功能以下：

（1）提供分库规则和路由规则（RouteRule简称RR），将上面的说明中提到的三中切分规则直接内嵌入本系统，具体的嵌入方式在接下来的内容中进行详细的说明和论述；

（2）引入集群（Group）的概念，保证数据的高可用性；

（3）引入负载均衡策略（LoadBalancePolicy简称LB）；

（4）引入集群节点可用性探测机制，对单点机器的可用性进行定时的侦测，以保证LB策略的正确实施，以确保系统的高度稳定性；

（5）引入读/写分离，提升数据的查询速度；

仅仅是分库分表的数据层设计也是不够完善的，当某个节点上的DB服务器出现了宕机的状况的时候，会是什么样的呢？是的，咱们采用了数据库切分方案，也就是说有N太机器组成了一个完整的DB ，若是有一台机器宕机的话，也仅仅是一个DB的N分之一的数据不能访问而已，这是咱们能接受的，起码比切分以前的状况好不少了，总不至于整个DB都不能访问。通常的应用中，这样的机器故障致使的数据没法访问是能够接受的，假设咱们的系统是一个高并发的电子商务网站呢？单节点机器宕机带来的经济损失是很是严重的。也就是说，如今咱们这样的方案仍是存在问题的，容错性能是经不起考验的。固然了，问题老是有解决方案的。咱们引入集群的概念，在此我称之为Group，也就是每个分库的节点咱们引入多台机器，每台机器保存的数据是同样的，通常状况下这多台机器分摊负载，当出现宕机状况，负载均衡器将分配负载给这台宕机的机器。这样一来，

就解决了容错性的问题。因此咱们引入了集群的概念，并将其内嵌入咱们的框架中，成为框架的一部分。

如上图所示，整个数据层有Group1，Group2，Group3三个集群组成，这三个集群就是数据水平切分的结果，固然这三个集群也就组成了一个包含完整数据的DB。每个Group包括1个Master（固然Master也能够是多个）和 N个Slave，这些Master和Slave的数据是一致的。好比Group1中的一个slave发生了宕机现象，那么还有两个slave是能够用的，这样的模型老是不会形成某部分数据不能访问的问题，除非整个 Group里的机器所有宕掉，可是考虑到这样的事情发生的几率很是小（除非是断电了，不然不易发生吧）。

在没有引入集群之前，咱们的一次查询的过程大体以下：请求数据层，并传递必要的分库区分字段（一般状况下是user_id）?数据层根据区分字段Route到具体的DB?在这个肯定的DB内进行数据操做。 这是没有引入集群的状况，当时引入集群会是什么样子的呢？看图一便可得知，咱们的路由器上规则和策略其实只能路由到具体的Group，也就是只能路由到一个虚拟的Group，这个Group并非某个特定的物理服务器。接下来须要作的工做就是找到具体的物理的DB服务器，以进行具体的数据操做。基于这个环节的需求，咱们引入了负载均衡器的概念（LB）。负载均衡器的职责就是定位到一台具体的DB服务器。具体的规则以下：负载均衡器会分析当前sql的读写特性，若是是写操做或者是要求实时性很强的操做的话，直接将查询负载分到Master，若是是读操做则经过负载均衡策略分配一个Slave。咱们的负载均衡器的主要研究放向也就是负载分发策略，一般状况下负载均衡包括随机负载均衡和加权负载均衡 。 随机负载均衡很好理解，就是从N个Slave中随机选取一个Slave。这样的随机负载均衡是不考虑机器性能的，它默认为每台机器的性能是同样的。假如真实的状况是这样的，这样作也是无可厚非的。假如实际状况并不是如此呢？每一个Slave的机器物理性能和配置不同的状况，再使用随机的不考虑性能的负载均衡，是很是不科学的，这样一来会给机器性能差的机器带来没必要要的高负载，甚至带来宕机的危险， 同时高性能的数据库服务器也不能充分发挥其物理性能。基于此考虑从，咱们引入了加权负载均衡，也就是在咱们的系统内部经过必定的接口，能够给每台DB服务器分配一个权值，而后再运行时LB根据权值在集群中的比重，分配必定比例的负载给该DB服务器。固然这样的概念的引入，无疑增大了系统的复杂性和可维护性。有得必有失，咱们也没有办法逃过的。

有了分库，有了集群，有了负载均衡器，是否是就万事大吉了呢？ 事情远没有咱们想象的那么简单。虽然有了这些东西，基本上能保证咱们的数据层能够承受很大的压力 ，可是这样的设计并不能彻底规避数据库宕机的危害。假如Group1中的slave2 宕机了，那么系统的LB并不能得知，这样的话实际上是很危险的，由于LB不知道，它还会觉得slave2为可用状态，因此仍是会给slave2分配负载。这样一来，问题就出来了，客户端很天然的就会发生数据操做失败的错误或者异常。这样是很是不友好的！怎样解决这样的问题呢？ 咱们引入集群节点的可用性探测机制 ，或者是可用性的数据推送机制 。这两种机制有什么不一样呢？首先说探测机制吧，顾名思义，探测即便，就是个人数据层客户端，不定时对集群中各个数据库进行可用性的尝试，实现原理就是尝试性连接，或者数据库端口的尝试性访问，均可以作到，固然也能够用JDBC尝试性连接，利用Java的Exception机制进行可用性的判断，具体的会在后面的文字中提到。那数据推送机制又是什么呢？其实这个就要放在现实的应用场景中来讨论这个问题了，通常状况下应用的DB 数据库宕机的话我相信DBA确定是知道的，这个时候DBA手动的将数据库的当前状态经过程序的方式推送到客户端，也就是分布式数据层的应用端，这个时候在更新一个本地的DB状态的列表。并告知LB，这个数据库节点不能使用，请不要给它分配负载。一个是主动的监听机制，一个是被动的被告知的机制。二者各有所长。可是均可以达到一样的效果。这样一来刚才假设的问题就不会发生了，即便就是发生了，那么发生的几率也会降到最低。

上面的文字中提到的Master和Slave ，咱们并无作太多深刻的讲解。如图一所示，一个Group由1个Master和N个Slave组成。为何这么作呢？其中Master负责写操做的负载，也就是说一切写的操做都在Master上进行，而读的操做则分摊到Slave上进行。这样一来的能够大大提升读取的效率。在通常的互联网应用中，通过一些数据调查得出结论，读/写的比例大概在 10：1左右 ，也就是说大量的数据操做是集中在读的操做，这也就是为何咱们会有多个Slave的缘由。可是为何要分离读和写呢？熟悉DB的研发人员都知道，写操做涉及到锁的问题，无论是行锁仍是表锁仍是块锁，都是比较下降系统执行效率的事情。咱们这样的分离是把写操做集中在一个节点上，而读操做其其余的N个节点上进行，从另外一个方面有效的提升了读的效率，保证了系统的高可用性。读写分离也会引入新的问题，好比个人Master上的数据怎样和集群中其余的Slave机器保持数据的同步和一致呢?这个是咱们不须要过多的关注的问题，MySql的Proxy机制能够帮助咱们作到这点，因为Proxy机制与本课题相关性不是太强，

在这里不作详细介绍。

综上所述，本课题中所研究的分布式数据层的大致功能就是如此。以上是对基本原理的一些讨论和阐述。接下来就系统设计层面，进行深刻的剖析和研究。

第4章 系统设计

4.1系统实现层面的选择

在引言部分中提到，该系统的实现层面有两种选择，一种是基于JDBC层面上的选择，一种是基于现有数据持久层框架层面上的选择，好比Hibernate，ibatis。两种层面各有长处，也各有不足之处。基于JDBC层面上的系统实现，系统开发难度和后期的使用难度都将大大提升。大大增长了系统的开发费用和维护费用。本课题的定位是在成型的ibatis持久层框架的基础上进行上层的封装，而不是对ibatis源码的直接修改，这样一来使本系统不会对现有框架有太多的侵入性，从而也增长了使用的灵活性。之因此选择ibatis，缘由以下：

（1）ibatis的学习成本很是低，熟练的Java Programmer可在很是的短期内熟练使用ibatis；

（2）ibatis是轻量级的ORM，只是简单的完成了RO，OR的映射，其查询语句也是经过配置文件sql-map.xml文件在原生sql的层面进行简单的配置，也就是说咱们没有引入诸如Hibernate那样的HQL的概念，从而加强了 sql的可控性，优秀的DBA能够很好的从sql的层面对sql进行优化，使数据层的应用有很强的可控性。Hibernate虽然很强大，可是因为 Hibernate是OR的一个重型封装，且引入HQL的概念，不便于DBA团队对sql语句的控制和性能的调优。

基于以上两点理由，本课题在ORM的产品的选择上选择了易学易用且轻量级的持久层框架ibatis。下面的讨论也都是特定于ibatis的基础上的讨论。

4.2其余开源框架的选择

在一些大型的Java应用中，咱们一般会采用Spring这样的开源框架，尤为是 IoC（DI）这部分，有效的帮助开发人员管理对象的依赖关系和层次，下降系统各层次之间的实体耦合。Spring的优势和用处我相信这是开发人员众所周知的，在此再也不赘述。本课题的数据层也将采用Spring作为IoC（DI）的框架。

4.3系统开发技术和工具介绍

开发语言：Java JDK1.5

集成开发环境：Eclipse 3.3.4

Web环境下测试服务器：JBoss 4.2

构建工具：淘宝自行研发的构建工具Antx（相似于Maven），固然也能够用Maven

依赖的开源Jar：Spring2.0，ibaits，commons-configuration(读取配置文件)，log4j，junit等