随着互联网应用的广泛普及。海量数据的存储和訪问成为了系统设计的瓶颈问题。
对于一个大型的互联网应用。每天百万级甚至上亿的PV无疑对数据库造成了相当高的负载。
对于系统的稳定性和扩展性造成了极大的问题。
一、负载均衡技术
负载均衡集群是由一组相互独立的计算机系统构成，通过常规网络或专用网络进行连接。由路由器衔接在一起。各节点相互协作、共同负载、均衡压力，对client来说，整个群集能够视为一台具有超高性能的独立server。
1、实现原理
实现数据库的负载均衡技术，首先要有一个能够控制连接数据库的控制端。在这里。它截断了数据库和程序的直接连接。由全部的程序来訪问这个中间层，然后再由中间层来訪问数据库。
这样。我们就能够详细控制訪问某个数据库了。然后还能够依据数据库的当前负载採取有效的均衡策略，来调整每次连接到哪个数据库。
2、实现多据库数据同步
对于负载均衡，最重要的就是全部server的数据都是实时同步的。这是一个集群所必需的。由于。假设数不据实时、不同步。那么用户从一台server读出的数据，就有别于从还有一台server读出的数据，这是不能同意的。所以必须实现数据库的数据同步。这样。在查询的时候就能够有多个资源，实现均衡。比較经常使用的方法是Moebius for SQL Server集群，Moebius for SQL Server集群採用将核心程序驻留在每一个机器的数据库中的办法，这个核心程序称为Moebius for SQL Server 中间件，主要作用是监測数据库内数据的变化并将变化的数据同步到其它数据库中。数据同步完毕后client才会得到响应。同步过程是并发完毕的，所以同步到多个数据库和同步到一个数据库的时间基本相等；另外同步的过程是在事务的环境下完毕的，保证了多份数据在不论什么时刻数据的一致性。
正由于Moebius 中间件宿主在数据库中的创新，让中间件不但能知道数据的变化，并且知道引起数据变化的SQL语句，依据SQL语句的类型智能的採取不同的数据同步的策略以保证数据同步成本的最小化。
数据条数非常少，数据内容也不大，则直接同步数据
数据条数非常少。可是里面包括大数据类型，比方文本，二进制数据等。则先对数据进行压缩然后再同步。从而降低网络带宽的占用和传输所用的时间。
数据条数非常多。此时中间件会拿到造成数据变化的SQL语句， 然后对SQL语句进行解析。分析其运行计划和运行成本，并选择是同步数据还是同步SQL语句到其它的数据库中。此种情况应用在对表结构进行调整或者批量更改数据的时候非常实用。
3、优缺点
(1) 扩展性强：当系统要更高数据库处理速度时，仅仅要简单地添加数据库server就 能够得到扩展。
(2) 可维护性：当某节点发生问题时，系统会自己主动检測故障并转移故障节点的应用。保证数据库的持续工作。
(3) 安全性：由于数据会同步的多台server上，能够实现数据集的冗余。通过多份数据来保证安全性。
另外它成功地将数据库放到了内网之中，更好地保护了数据库的安全性。
(4) 易用性：相应用来说全然透明。集群暴露出来的就是一个IP
(1) 不可以依照Webserver的处理能力分配负载。
(2) 负载均衡器(控制端)故障。会导致整个数据库系统瘫痪。
二、数据库的读写分离
1。实现原理：读写分离简单的说是把对数据库读和写的操作分开相应不同的数据库server，这样能有效地减轻数据库压力，也能减轻io压力。主数据库提供写操作，从数据库提供读操作，事实上在非常多系统中，主要是读的操作。当主数据库进行写操作时，数据要同步到从的数据库。这样才干有效保证数据库完整性。
(ebay的读写比率是260:1,ebay的读写分离)
(微软数据库分发)
2，实现方法：在MS Sql server中能够使用公布定义的方式实现数据库复制。实现读写分离。复制是将一组数据从一个数据源复制到多个数据源的技术。是将一份数据公布到多个存储网站上的有效方式。使用复制技术。用户能够将一份数据公布到多台server上。复制技术能够确保分布在不同地点的数据自己主动同步更新。从而保证数据的一致性。
SQL SERVER复制技术类型有三种，各自是：快照复制、事务复制、合并复制。
SQL SERVER 主要採用出版物、订阅的方式来处理复制。
源数据所在的server是出版server，负责发表数据。出版server把要发表的数据的全部改变情况的拷贝复制到分发server，分发server包括有一个分发数据库。可接收数据的全部改变，并保存这些改变，再把这些改变分发给订阅server。
3，优缺点
(1)数据的实时性差:数据不是实时同步到自读server上的。当数据写入主server后，要在下次同步后才干查询到。
(2)数据量大时同步效率差：单表数据量过大时插入和更新因索引,磁盘IO等问题，性能会变的非常差。
(3)同一时候连接多个（至少两个）数据库：至少要连接到两个数据数据库。实际的读写操作是在程序代码中完毕的，easy引起混乱
(4)读具有高性能高可靠性和可伸缩:仅仅读server，由于没有写操作，会大大减轻磁盘IO等性能问题。大大提高效率；仅仅读server能够採用负载均衡。主数据库公布到多个仅仅读server上实现读操作的可伸缩性。
三、数据库拆分(分布式)
通过某种特定的条件，将存放在同一个数据库中的数据分散存放到多个数据库上，实现分布存储，通过路由规则路由訪问特定的数据库，这样一来每次訪问面对的就不是单台server了，而是N台server。这样就能够减少单台机器的负载压力。
垂直(纵向)拆分：是指按功能模块拆分，比方分为订单库、商品库、用户库…这样的方式多个数据库之间的表结构不同。
水平(横向)拆分：将同一个表的数据进行分块保存到不同的数据库中，这些数据库中的表结构全然同样。
（纵向拆分）
（横向拆分）
1，实现原理：使用垂直拆分，主要要看应用类型是否合适这样的拆分方式，如系统能够分为。订单系统，商品管理系统，用户管理系统业务系统比較明的，垂直拆分能非常好的起到分散数据库压力的作用。
业务模块不明晰，耦合（表关联）度比較高的系统不适合使用这样的拆分方式。可是垂直拆分方式并不能彻底解决全部压力问题。比如 有一个5000w的订单表，操作起来订单库的压力仍然非常大，如我们须要在这个表中添加（insert）一条新的数据，insert完成后，数据库会针对这张表又一次建立索引，5000w行数据建立索引的系统开销还是不容忽视的，反过来，假如我们将这个表分成100个table呢，从table_001一直到table_100。5000w行数据平均下来。每一个子表里边就仅仅有50万行数据，这时候我们向一张仅仅有50w行数据的table中insert数据后建立索引的时间就会呈数量级的下降，极大了提高了DB的执行时效率，提高了DB的并发量，这样的拆分就是横向拆分
2，实现方法：垂直拆分，拆分方式实现起来比較简单，依据表名訪问不同的数据库就能够了。横向拆分的规则非常多，这里总结前人的几点，
(1)顺序拆分：如能够按订单的日前按年份才分。2003年的放在db1中，2004年的db2,以此类推。
当然也能够按主键标准拆分。
长处：可部分迁移
缺点：数据分布不均。可能2003年的订单有100W。2008年的有500W。
(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信息。然后才干进行我们须要的查询操作。
长处：灵活性强，一对一关系
缺点：每次查询之前都要多一次查询。会造成一定的性能损失。