如何构建日均千万PV Web站点 (三) Sharding

　　      其实国内许多大型网站为了应对日益复杂的业务场景，经过使用分而治之的手段将整个网站业务分红不一样的产品线，好比说国内那些大型购物交易网站它们都将本身的网站首页、商铺、订单、买家、卖家等拆分不一样的产品线，分归不一样的业务团队负责；

　　　　集体到技术，也会根据产品线划分，将一个网站拆分红许多不一样的应用，每一个应用用独立部署维护。应用之间能够经过一个超连接创建关系(在首页上的导航连接每一个都指向不一样的应用地址)，也能够经过消息队列进行数据分发，固然最多的仍是经过访问同一个数据库存储系统来构成一个关联的完整系统 此时的架构以下图所示：

　　分布式服务，随着业务拆分愈来愈小，存储系统愈来愈庞大，应用系统的总体复杂度呈指数级增长，部署维护愈来愈困难，因为全部应用要和全部数据库系统链接，在数万台服务器规模的网站中，这些链接的数目是服务器规模的平方，致使数据库链接资源不足，拒绝服务。

　　既然每个应用系统都须要执行许多相同的业务操做，好比用户管理、商品管理等，那么能够将这些共用的业务提取出来，独立部署。由这些可复用的业务链接数据库，提供共用服务，而应用系统只须要管理用户界面，经过分布式服务调用共用业务服务完成具体业务操做

数据库如何sharding？

数据的切分（Sharding）根据其切分规则的类型，能够分为两种切分模式。一种是按照 不一样的表（或者 Schema）来切分到不一样的数据库（主机）之上，这种切能够称之为数据的 垂直（纵向）切分；另一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某 种条件拆分到多台数据库（主机）上面，这种切分称之为数据的水平（横向）切分。 垂直切分的最大特色就是规则简单，实施也更为方便，尤为适合各业务之间的耦合度非 常低，相互影响很小，业务逻辑很是清晰的系统。在这种系统中，能够很容易作到将不一样业 务模块所使用的表分拆到不一样的数据库中。根据不一样的表来进行拆分，对应用程序的影响也 更小，拆分规则也会比较简单清晰。 水平切分于垂直切分相比，相对来讲稍微复杂一些。由于要将同一个表中的不一样数据拆 分到不一样的数据库中，对于应用程序来讲，拆分规则自己就较根据表名来拆分更为复杂， 后期的数据维护也会更为复杂一些。 当咱们某个（或者某些）表的数据量和访问量特别的大，经过垂直切分将其放在独立的 设备上后仍然没法知足性能要求，这时候咱们就必须将垂直切分和水平切分相结合，先垂直 切分，而后再水平切分，才能解决这种超大型表的性能问题。 下面咱们就针对垂直、水平以及组合切分这三种数据切分方式的架构实现及切分后数据 的整合进行相应的分析。 14.2 数据的垂直切分 咱们先来看一下，数据的垂直切分究竟是如何一个切分法的。数据的垂直切分，也能够 称之为纵向切分。将数据库想象成为由不少个一大块一大块的“数据块”（表）组成，咱们 垂直的将这些 “数据块”切开，而后将他们分散到多台数据库主机上面。这样的切分方法就 是一个垂直（纵向）的数据切分。 一个架构设计较好的应用系统，其整体功能确定是由不少个功能模块所组成的，而每一 个功能模块所须要的数据对应到数据库中就是一个或者多个表。而在架构设计中，各个功能 模块相互之间的交互点越统一越少，系统的耦合度就越低，系统各个模块的维护性以及扩展 性也就越好。这样的系统，实现数据的垂直切分也就越容易。 当咱们的功能模块越清晰，耦合度越低，数据垂直切分的规则定义也就越容易。彻底可 以根据功能模块来进行数据的切分，不一样功能模块的数据存放于不一样的数据库主机中，能够 很容易就避免掉跨数据库的 Join 存在，同时系统架构也很是的清晰.

固然，很难有系统可以作到全部功能模块所使用的表彻底独立，彻底不须要访问对方的 表或者须要两个模块的表进行 Join 操做。这种状况下，咱们就必须根据实际的应用场景进 行评估权衡。决定是迁就应用程序将须要 Join 的表的相关某快都存放在同一个数据库中， 仍是让应用程序作更多的事情，也就是程序彻底经过模块接口取得不一样数据库中的数据， 然 后在程序中完成 Join 操做。 通常来讲，若是是一个负载相对不是很大的系统，并且表关联又很是的频繁，那可能数 据库让步，将几个相关模块合并在一块儿减小应用程序的工做的方案能够减小较多的工做量， 是一个可行的方案。 固然，经过数据库的让步，让多个模块集中共用数据源，实际上也是简介的默许了各模 块架构耦合度增大的发展，可能会让之后的架构愈来愈恶化。尤为是当发展到必定阶段以后 ， 发现数据库实在没法承担这些表所带来的压力，不得不面临再次切分的时候，所带来的架构 改形成本可能会远远大于最初的时候。 因此，在数据库进行垂直切分的时候，如何切分，切分到什么样的程度，是一个比较考 验人的难题。只能在实际的应用场景中经过平衡各方面的成本和收益，才能分析出一个真正 适合本身的拆分方案。 好比在本书所使用示例系统的 example 数据库，咱们简单的分析一下，而后再设计一 个简单的切分规则，进行一次垂直垂直拆分。 系统功能能够基本分为四个功能模块：用户，群组消息，相册以及事件，

分别对应为如 下这些表：

1. 用户模块表：user,user_profile,user_group,user_photo_album

2. 群组讨论表：groups,group_message,group_message_content,top_message

3. 相册相关表：photo,photo_album,photo_album_relation,photo_comment

 

4. 事件信息表：event 初略一看，没有哪个模块能够脱离其余模块独立存在，模块与模块之间都存在着关系 ， 莫非没法切分？ 固然不是，咱们再稍微深刻分析一下，能够发现，虽然各个模块所使用的表之间都有关 联，可是关联关系还算比较清晰，也比较简单。 群组讨论模块和用户模块之间主要存在经过用户或者是群组关系来进行关联。通常 关联的时候都会是经过用户的 id 或者 nick_name 以及 group 的 id 来进行关 联，经过模块之间的接口实现不会带来太多麻烦； 相册模块仅仅与用户模块存在经过用户的关联。这两个模块之间的关联基本就有通 过用户 id 关联的内容，简单清晰，接口明确； 事件模块与各个模块可能都有关联，可是都只关注其各个模块中对象的 ID信息 ， 一样能够作到很容易分拆。 因此，咱们第一步能够将数据库按照功能模块相关的表进行一次垂直拆分，每一个模块所 涉及的表单独到一个数据库中，模块与模块之间的表关联都在应用系统端经过藉口来处理。 以下图所示：

经过这样的垂直切分以后，以前只能经过一个数据库来提供的服务，就被分拆成四个数 据库来提供服务，服务能力天然是增长几倍了。

垂直切分的优势

一、数据库的拆分简单明了，拆分规则明确；

二、应用程序模块清晰明确，整合容易；

三、数据维护方便易行，容易定位；

垂直切分的缺点

一、部分表关联没法在数据库级别完成，须要在程序中完成；

二、对于访问极其频繁且数据量超大的表仍然存在性能平静，不必定能知足要求；

三、事务处理相对更为复杂；

四、切分达到必定程度以后，扩展性会遇到限制；

五、过读切分可能会带来系统过渡复杂而难以维护。

　　针对于垂直切分可能遇到数据切分及事务问题，在数据库层面实在是很难找到一个较好 的处理方案。实际应用案例中，数据库的垂直切分大可能是与应用系统的模块相对应，同一个 模块的数据源存放于同一个数据库中，能够解决模块内部的数据关联问题。而模块与模块之间，则经过应用程序以服务接口方式来相互提供所须要的数据。虽然这样作在数据库的整体 操做次数方面确实会有所增长，可是在系统总体扩展性以及架构模块化方面，都是有益的。 可能在某些操做的单次响应时间会稍有增长，可是系统的总体性能极可能反而会有必定的提 升。而扩展瓶颈问题，就只能依靠下一节将要介绍的数据水平切分架构来解决了。

　　　数据的水平切分

　　　上面一节分析介绍了数据的垂直切分，这一节再分析一下数据的水平切分。数据的垂直 切分基本上能够简单的理解为按照表按照模块来切分数据，而水平切分就再也不是按照表或者 是功能模块来切分了。通常来讲，简单的水平切分主要是将某个访问极其平凡的表再按照某 个字段的某种规则来分散到多个表之中，每一个表中包含一部分数据。 简单来讲，咱们能够将数据的水平切分理解为是按照数据行的切分，就是将表中的某些 行切分到一个数据库，而另外的某些行又切分到其余的数据库中。固然，为了可以比较容易的断定各行数据被切分到哪一个数据库中了，切分老是都须要按照某种特定的规则来进行的。 如根据某个数字类型字段基于特定数目取模，某个时间类型字段的范围，或者是某个字符类 型字段的 hash 值。若是整个系统中大部分核心表均可以经过某个字段来进行关联，那这个 字段天然是一个进行水平分区的上上之选了，固然，很是特殊没法使用就只能另选其余了。 通常来讲，像如今互联网很是火爆的 Web2.0 类型的网站，基本上大部分数据都可以通 过会员用户信息关联上，可能不少核心表都很是适合经过会员 ID 来进行数据的水平切分。 而像论坛社区讨论系统，就更容易切分了，很是容易按照论坛编号来进行数据的水平切分。 切分以后基本上不会出现各个库之间的交互。 如咱们的示例系统，全部数据都是和用户关联的，那么咱们就能够根据用户来进行水平 拆分，将不一样用户的数据切分到不一样的数据库中。固然，惟一有点区别的是用户模块中的 groups 表和用户没有直接关系，因此 groups 不能根据用户来进行水平拆分。对于这种特 殊状况下的表，咱们彻底能够独立出来，单独放在一个独立的数据库中。其实这个作法能够 说是利用了前面一节所介绍的 “数据的垂直切分”方法，我将在下一节中更为详细的介绍这 种垂直切分与水平切分同时使用的联合切分方法。 因此，对于咱们的示例数据库来讲，大部分的表均可以根据用户 ID 来进行水平的切分 。 不一样用户相关的数据进行切分以后存放在不一样的数据库中。如将全部用户 ID 经过 2 取模 而后分别存放于两个不一样的数据库中。每一个和用户 ID 关联上的表均可以这样切分。这样， 基本上每一个用户相关的数据，都在同一个数据库中，即便是须要关联，也能够很是简单的关 联上。 咱们能够经过下图来更为直观的展现水平切分相关信息：

水平切分的优势

一、表关联基本可以在数据库端所有完成；

二、不会存在某些超大型数据量和高负载的表遇到瓶颈的问题；

三、应用程序端总体架构改动相对较少； 事务处理相对简单；

四、只要切分规则可以定义好，基本上较难遇到扩展性限制；

水平切分的缺点

一、切分规则相对更为复杂，很难抽象出一个可以知足整个数据库的切分规则；

二、后期数据的维护难度有所增长，人为手工定位数据更困难；

三、应用系统各模块耦合度较高，可能会对后面数据的迁移拆分形成必定的困难。

　　　　垂直与水平联合切分的使用

　　　　上面两节内容中，咱们分别，了解了“垂直”和“水平”这两种切分方式的实现以及切 分以后的架构信息，同时也分析了两种架构各自的优缺点。可是在实际的应用场景中，除了 那些负载并非太大，业务逻辑也相对较简单的系统能够经过上面两种切分方法之一来解决 扩展性问题以外，恐怕其余大部分业务逻辑稍微复杂一点，系统负载大一些的系统，都没法 经过上面任何一种数据的切分方法来实现较好的扩展性，而须要将上述两种切分方法结合使 用，不一样的场景使用不一样的切分方法。 在这一节中，我将结合垂直切分和水平切分各自的优缺点，进一步完善咱们的总体架构 ， 让系统的扩展性进一步提升。 通常来讲，咱们数据库中的全部表很难经过某一个（或少数几个）字段所有关联起来， 因此很难简单的仅仅经过数据的水平切分来解决全部问题。而垂直切分也只能解决部分问 题，对于那些负载很是高的系统，即便仅仅只是单个表都没法经过单台数据库主机来承担其 负载。咱们必须结合“垂直”和“水平”两种切分方式同时使用，充分利用二者的优势，避 开其缺点。 每个应用系统的负载都是一步一步增加上来的，在开始遇到性能瓶颈的时候，大多数 架构师和 DBA 都会选择先进行数据的垂直拆分，由于这样的成本最早，最符合这个时期所追 求的最大投入产出比。然而，随着业务的不断扩张，系统负载的持续增加，在系统稳定一段 时期以后，通过了垂直拆分以后的数据库集群可能又再一次不堪重负，遇到了性能瓶颈。 这时候咱们该如何抉择？是再次进一步细分模块呢，仍是寻求其余的办法来解决？若是 咱们再一次像最开始那样继续细分模块，进行数据的垂直切分，那咱们可能在不久的未来， 又会遇到如今所面对的一样的问题。并且随着模块的不断的细化，应用系统的架构也会越来 越复杂，整个系统极可能会出现失控的局面。 这时候咱们就必需要经过数据的水平切分的优点，来解决这里所遇到的问题。并且， 咱们彻底没必要要在使用数据水平切分的时候，推倒以前进行数据垂直切分的成果，而是在其基 础上利用水平切分的优点来避开垂直切分的弊端，解决系统复杂性不断扩大的问题。而水平 拆分的弊端（规则难以统一）也已经被以前的垂直切分解决掉了，让水平拆分能够进行的驾轻就熟。 对于咱们的示例数据库，假设在最开始，咱们进行了数据的垂直切分，然而随着业务的 不断增加，数据库系统遇到了瓶颈，咱们选择重构数据库集群的架构。如何重构？考虑到之 前已经作好了数据的垂直切分，并且模块结构清晰明确。而业务增加的势头愈来愈猛，即便 如今进一步再次拆分模块，也坚持不了过久。咱们选择了在垂直切分的基础上再进行水平拆分。 在经历过垂直拆分后的各个数据库集群中的每个都只有一个功能模块，而每一个功能模 块中的全部表基本上都会与某个字段进行关联。如用户模块所有均可以经过用户ID进行切分，群组讨论模块则都经过群组ID来切分，相册模块则根据相册ID来进切分，最后的事 件通知信息表考虑到数据的时限性（仅仅只会访问最近某个事件段的信息），则考虑按时间 来切分。 下图展现了切分后的整个架构：

实际上，在不少大型的应用系统中，垂直切分和水平切这两种数据的切分方法基本上都 是并存的，并且常常在不断的交替进行，以不断的增长系统的扩展能力。咱们在应对不一样的 应用场景的时候，也须要充分考虑到这两种切分方法各自的局限，以及各自的优点，在不一样的时期（负载压力）使用不一样的结合方式。

联合切分的优势

一、能够充分利用垂直切分和水平切分各自的优点而避免各自的缺陷；

二、让系统扩展性获得最大化提高；

联合切分的缺点

一、数据库系统架构比较复杂，维护难度更大；

二、应用程序架构也相对更复杂。

关于数据库如何sharding详情请参考<<MySQL性能调优与架构设计>>