分库分表

背景：

互联网的发展和普及，海量数据访问成为系统瓶颈，对数据库也造成了高负载，随之而来，系统的稳定性和可靠性也有了问题。数据切分和横向扩展数据层的方案便应运而生。
具体策略：
1. 水平或垂直拆分数据库 ：减少对单台数据库压力，
2. 减少宕机的损失； 数据库集群：解决宕机时数据不能访问的问题；
3. 负载均衡：减少对单台及其的访问压力，降低宕机发生的几率；
4. 读写分离：master负载write，slave负载read，提高系统的访问效率

数据切分

Why：
当单台机器物理性能达到上限，为了满足业务的需求，需要添置更多的机器，共同负载。以及随考虑着业务的增长，能否实现机器线性增长满足业务需要。Sharding可以轻松的将计算 存储 IO流分散到各个机器上，降低单点的压力，提供系统的可用性
How：
如何做到数据切分：
（1）通过切分规则将数据分散在不同的机器，根据路由找到特定的数据库，减少单点负载
（2）在数据库内部通过数据切分规则将数据分散在数据库的不同表中，比如一张订单表order，有2000w条数据，并且是有索引的，如果存在一张表中，那么在对order表进行insert操作，将大大降低表操作效率，但是如果将这2000w条数据分布在100张表中，那么每张表大约是20w条数据，进行insert操作的时候效率就会大大提高,分库降低了单点机器的负载；分表，提高了数据操作的效率
规则：
A. 号段分区
id为1～1000的对应DB1，1001～2000的对应DB2，以此类推；
优点：可部分迁移
缺点：数据分布不均

B.hash取模分区
比如应用中需要将一个数据库切分成4个数据库的话，我们就用4这个数字对id的hash值进行取模运算，也就是id%4,这样的话，每次运算就有四种可能：结果为1的时候对应DB1；结果为2的时候对应DB2；结果为3的时候对应DB3；结果为0的时候对应DB4。这样一来就非常均匀的将数据分配到4个DB中。
优点：数据分布均匀
缺点：数据迁移的时候麻烦，不能按照机器性能分摊数据

C.在认证库中保存数据库配置
建立一个DB，这个DB单独保存字段和DB的映射关系，每次访问数据库的时候都要先查询一次这个数据库，以得到具体的DB信息，然后才能进行我们需要的查询操作。
优点：灵活配置，关系一对一
缺点：每次都会多一次查询，性能大大降低
以上就是常用三种方式，有些复杂的项目中可能会混合使用这三种方式。当然还会有更好更完善的分库方式，有待探究

分布式数据方案

（1）分库规则和路由规则（RouteRule简称RR）；
（2）集群，保证数据的高可用性；
（3）引入负载均衡策略（LoadBalancePolicy简称LB）；
（4）引入集群节点可用性探测机制，对单点机器的可用性进行定时的侦测，以保证LB策略的正确实施，以确保系统的高度稳定性；
（5）引入读/写分离，提高数据的查询速度；
分库分表的数据层设计是不够完善了的，当采取了数据切分方案，N台机器组成一个完整的DB，一台机器挂掉了，也将导致的是N分之一的数据不可访问，但是假设就因为一台机器宕机了，引发的经济损失也是非常严重的，所以现在的方案还是存在问题，容错性能经不起考验，于是引入了集群这一概念：每一个分库的节点引入多台机器，每台机器保存的数据是完全一致的，多台机器分摊负载，这样一台机器出现宕机的时候，其他机器顶上，解决容错性问题

整个数据层有Group1，Group2，Group3三个集群组成，这三个集群就是数据水平切分的结果，三个集群也就组成了一个包含完整数据的DB。每一个Group包括1个Master和 N个Slave，每个分库的数据是一致的。 比如Group1中的一个slave发生了宕机现象，那么还有两个slave是可以用的，这样的模型总是不会造成某部分数据不能访问的问题，除非整个 Group里的机器全部宕掉，但是考虑到这样的事情发生的概率非常小（除非是断电了）。

我们的路由器上规则和策略其实只能路由到具体的Group，也就是只能路由到一个虚拟的Group，这个Group并不是某个特定的物理服务器。接下来需要做的工作就是找到具体的物理的DB服务器，以进行具体的数据操作。

基于这个环节的需求，我们引入了负载均衡器的概念 （LB），负载均衡器的职责就是定位到一台具体的DB服务器。具体的规则如下：负载均衡器会分析当前sql的读写特性，如果是写操作或者是要求实时性很强的操作的话，直接将查询负载分到Master，如果是读操作则通过负载均衡策略分配一个Slave。

负载均衡的策略

负载分发策略，通常情况下负载均衡包括随机负载均衡和加权负载均衡。随机负载均衡就是从N个Slave中随机选取一个Slave。这样的随机负载均衡是不考虑机器性能的，它默认为每台机器的性能是一样的。假如真实的情况是这样的，这样做也是无可厚非的。假如实际情况并非如此呢？每个Slave的机器物理性能和配置不一样的情况，再使用随机的不考虑性能的负载均衡，是非常不科学的，这样一来会给机器性能差的机器带来不必要的高负载，甚至带来宕机的危险，同时高性能的数据库服务器也不能充分发挥其物理性能。基于此考虑，我们引入了加权负载均衡，也就是在我们的系统内部通过一定的接口，可以给每台DB服务器分配一个权值，然后再运行时LB根据权值在集群中的比重，分配一定比例的负载给该DB服务器。当然这样的概念的引入，无疑增大了系统的复杂性和可维护性。

可用性探测机制
数据库的客户端，定时的对数据库的各个节点进行检查，查看是否可用在，实现的原理是尝试性连接或数据库端口访问
数据推送机制
DBA手动的将数据库的当前状态通过程序的方式推送到客户端，也就是分布式数据层的应用端，然后更新一个本地的DB状态的列表。并告知LB，这个数据库节点不能使用，请不要给它分配负载
一个是主动的监听机制，一个是被动的被告知的机制，都可以达到同样的效果
master和slave
Master负责写操作的负载，也就是说一切写的操作都在Master上进行，而读的操作则分摊到Slave上进行。这样一来的可以大大提高读取的效率。读/写的比例大概在 10：1左右
但是为什么要分离读和写呢？写操作涉及到锁的问题，不管是行锁还是表锁还是块锁，都是比较降低系统执行效率的事情。我们这样的分离是把写操作集中在一个节点上，而读操作其其他 的N个节点上进行，从另一个方面有效的提高了读的效率，保证了系统的高可用性。

原文：
https://www.cnblogs.com/zhongxinWang/p/4262650.html