数据库的读写分离与负载均衡策略

最近工做室开始了一个项目，因为需求方面的问题，数据库的设计开始往中型电商系统靠近。也趁此机会，学习一下数据库的优化策略，。sql

原文地址：blog.csdn.net/seudongnan/…数据库

数据库的优化策略

随着互联网的普及，电商行业的发展，一个大型的电商平台将对数据库形成极大的负载。为了维持系统的稳定性和拓展性，经过数据切分来提升网站性能，横向扩展数据层已经成为架构人员首选方式。服务器

水平切分数据库：能够下降单台机器的负载，同时最大限度的下降了宕机产生的损失。
负载均衡策略：能够下降单台机器的访问负载，下降宕机的可能性。
集群方案：解决了数据库宕机带来的单点数据库不能访问的问题。
读写分离策略：最大限度提升了应用中读取数据的访问量和并发量

基本原理

数据切分

数据切分（Sharding）是水平扩展（Scale Out，或叫作横向扩展）的解决方案。markdown

Sharding的主要目的

突破单节点数据库服务器的I/O能力限制，解决数据库扩展性的问题。架构

Sharding的实现策略

Sharding的实现是经过一系列的切分策略，将数据水平切分到不一样的Database或者table中。在查询过程当中，经过必定的路由策略，找到须要查询的具体Database或table，进行Query操做。并发

举个例子：负载均衡

咱们要对一张article表进行切分，article中有两个主要字段，article_id和user_id。咱们能够采用这样的切分策略：将user_id在1~10000的数据写入DB1，10001~20000的数据写入DB2，以此类推，这就是数据库的切分。分布式

固然，咱们将切分策略反转，便可从一个给定的user_id来查询到具体的记录，这个过程被称为DB路由。高并发

数据切分的方式

数据切分能够是物理上的，也就是对数据进行一系列的切分策略，分布到不一样的DB服务器上，经过DB路由规则访问相应的数据库。以此下降单台机器的负载压力。oop

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

因而可知：分库下降了单点机器的负载；分表，提升了数据操做的效率。

接下来简单了解一下分库的方式和规则：

依然沿用以前的article表的例子

号段分区

user_id为1~1000在DB1，1001~2000在DB2，以此类推
- 优势：可部分迁移
- 缺点：数据分布不均
hash取模分区

对user_id进行hash，而后用一个数字对应一个具体的DB。好比有4个数据库，就将user_id%4，结果为0的对应DB1，结果为1的对应DB2，以此类推。这样一来就能够将数据均匀分布。
- 优势：数据分布均匀
- 缺点：数据迁移麻烦，不能按照机器性能分摊数据
在认证库中保存数据库配置

就是创建一个DB，这个DB单独保存user_id到DB的映射关系，每次访问数据库的时候都要先查询一次这个数据库，以获得具体的DB信息，而后才能进行咱们须要的查询操做。
- 优势：灵活性强，一对一关系
- 缺点：每次查询以前都要多一次查询，性能大打折扣

分布式数据方案

提供分库规则和路由规则（RouteRule简称RR）
引入集群（Group）的概念，保证数据的高可用性
引入负载均衡策略（LoadBalancePolicy简称LB）
引入集群节点可用性探测机制，对单点机器的可用性进行定时的侦测，以保证LB策略的正确实施，以确保系统的高度稳定性
引入读/写分离，提升数据的查询速度。

集群

仅仅是分库分表的数据层设计也是不够完善的，当咱们采用了数据库切分方案，也就是说有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分配负载。这样一来，问题就出来了，客户端很天然的就会发生数据操做失败的错误或者异常。

怎样解决这样的问题呢？咱们引入集群节点的可用性探测机制，或者是可用性的数据推送机制。这两种机制有什么不一样呢？首先说探测机制吧，顾名思义，探测即便，就是个人数据层客户端，不定时对集群中各个数据库进行可用性的尝试，实现原理就是尝试性连接，或者数据库端口的尝试性访问，均可以作到。

那数据推送机制又是什么呢？其实这个就要放在现实的应用场景中来讨论这个问题了，通常状况下应用的DB 数据库宕机的话我相信DBA确定是知道的，这个时候DBA手动的将数据库的当前状态经过程序的方式推送到客户端，也就是分布式数据层的应用端，这个时候在更新一个本地的DB状态的列表。并告知LB，这个数据库节点不能使用，请不要给它分配负载。一个是主动的监听机制，一个是被动的被告知的机制。二者各有所长。可是均可以达到一样的效果。这样一来刚才假设的问题就不会发生了，即便就是发生了，那么发生的几率也会降到最低。

上面的文字中提到的Master和Slave ，咱们并无作太多深刻的讲解。一个Group由1个Master和N个Slave组成。为何这么作呢？其中Master负责写操做的负载，也就是说一切写的操做都在Master上进行，而读的操做则分摊到Slave上进行。这样一来的能够大大提升读取的效率。在通常的互联网应用中，通过一些数据调查得出结论，读/写的比例大概在 10：1左右，也就是说大量的数据操做是集中在读的操做，这也就是为何咱们会有多个Slave的缘由。

可是为何要分离读和写呢？熟悉DB的研发人员都知道，写操做涉及到锁的问题，无论是行锁仍是表锁仍是块锁，都是比较下降系统执行效率的事情。咱们这样的分离是把写操做集中在一个节点上，而读操做其其余的N个节点上进行，从另外一个方面有效的提升了读的效率，保证了系统的高可用性。