从单一数据库到分库

前言

互联网发展迅猛，短短几年就改变传统行业的结构，最具典型的就是产业互联网，产业互联网作为种传统行业的进化，必然带来的行业模式的改变，数据作为平台最基本的载体，必然也会发生变革，从有限量级的数据，到千万级别数据，再到亿万级别数据，再到兆级，数据的量级一直在改变，

 

单体服务时代

早期的平台应用例如OA系统，大多目的是为了优化流程，本身并不会承载大量的数据，所以基本上是单一部署，可能为了安全性，会将数据库和应用服务器区别开部署，早期的内网型部署，更多是的政府等机构的部署方式，在于他们决的有必要将应用与数据库分离

从单一型到内网型改进的优点：

1、降低应用业务和数据的耦合度

2、有利于版本升级，应用业务代码改变，对数据本身影响相对是低的

3、有利于数据的热备份（可以备份数据库日志，也可以整个系统进行备份）

从单一型到内网型改进的缺点：

1、数据库的可用性不是绝对的，如果数据库发生假死的情况，应用本身是不可用的

2、不利于数据分析，在不停止应用服务前，是不利于对内部的数据进行分析

3、坏SQL慢查询假死导致应用不可用

 

主从数据库时代

由于单体应用已经无法满足当前业务的所有需求，研发人员根据单体应用设计了数据库主从模式的服务模型，主从模型不但是在原有的架构基础上变形，同时也改变部分业务形态

主从改进的优点：

1、数据服务可靠性提升（能一定程度避免服务不可用）

2、应用服务和数据分析可以同步进行（主库提供服务，从库进行数据分析）

主从改进的缺点：

1、数据源切换的方式需要自行把控

2、数据同步时效性无法完整把控

数据同步方式：

1、全表同步（不推荐，严重影响数据库性能）

2、增量数据同步双写（数据库主库数据变更的同时，通知从库进行数据变更，少量影响数据库性能但是影响业务性能）

3、增量数据定时同步（有数据延迟性，可能存在主从数据不一致的情况，对性能影响可控）

4、日志同步（通过主库的日志记录进行同步，轻量无感知）

 

 

分库分表时代

模式初期

随着平台越做越大，平台自身产生了巨大的数据量，例如淘宝初期可能日GMV可能才几百万，随着淘宝业务的深入其平台的体量达到了惊人的日千亿级别的GMV，这样必然产生巨大的数据量，如果这样的数据全部集中在一个数据中，当当做一个简单的查询所需要的时长就有可能能会是原先的几万倍甚至几百万倍，可以设想一下，你点击一个查询按钮，结果坐在电脑等一天这样的效率是无法忍受的

随后大家产生了几种方案

1、引入高性能的数据库例如Hbase

2、加强平台运算能力，引入流式计算框架（storm,spark等等）

3、分库分表

对于使用流式计算和Hbase并不适合特定的场景，例如资金安全或者支付等对数据一致性要求苛刻的场景其实是并不适用的，必然会使用到分库分表

 

日志时期

在这个时期，大量使用关系型数据库进行分库分表，必然要保证数据的安全型和一致性，这个时期由于分库带来的事务阻断性导致无法从代码层面保证数据一致性，这时期的开发将大量使用日志的方式去记录每次次数据操作，如果出现数据不一致的情况，通过日志排查，通过人工的方式去保证数据的一致性

日志输出优点：

1、能有限的保证数据一致性

日志输出缺点：

1、日志记录不规范，不同开发人员的日志记录风格迥异

2、排查时候开发需要很深入的理解业务流程

3、并不能根源上避免数据不一致的情况，开发排查线上问题需要耗费大量精力

 

数据异常

数据库事务本质上是指单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行，其必须满足ACID（原子性、一致性、隔离性和持久性）的属性性。

1、异地机房，同一个事务底下，AB两个操作无感知，后操作动作无法感知前一个操作的状态（原子性）

2、异地机房，同一个事务底下，AB操作的数据很难保证绝对的隔离性（隔离性）

3、由于上面两种情况，平台数据很难满足一致性的情况，尤其是对于，像财务数据，这种数据一致性强烈要求的业务，无疑是致命的

 

 

由于业务对数据一致性的强烈依赖，迫使开发想出新的策略去解决这类问题，开发都设想，如果能把分开的数据库变成一个整体的数据库，并且让其支持事务那该多好，于是大家都发表了自己的看法，就诞生了两种理论分表是CAP定理和BASE理论

 

CAP定理

首先关系型数据库ACID的模型分别是：

Atomicity原子性：一个事务中所有操作都必须全部完成，要么全部不完成

Consistency一致性： 在事务开始或结束时，数据库应该在一致状态

Isolation隔离性： 事务将假定只有它自己在操作数据库，彼此不知晓

Durability持久性： 一旦事务完成，就不能返回

但是在这种模型下面，支持ACID模型的数据库是拥有很高的数据一致性和可用性的，但是这种模式下的数据库也是很难进行分库的，举个例子：在分库的环境下，两个数据库 A 和 B ，在原始的情况下是无法支持原子性的，有可能操作A库成功但是操作B的时候由于网络原有导致失败

于是大家总结出一个CAP理论：

Consistency 一致性（C）：在分布式系统种的所有数据以及其备份的数据，在同一时刻都是同步变动的，要不全部成功，要不全部失败

Availability    可用性（A）：平台系统具有可靠的响应能力，不会出现系统无响应或者请求失败的情况

Partition tolerance 分区容错性 （P）：在分库的情况下，任意分区出现瘫痪或者故障，系统整体仍然要对外提供满足一致性和可用性的服务（例如HDFS 的 三片分区的容错性）

最终总结：任何分布式系统，只能同时满足以上三点种的两点，无法同时满足

例如莫系统对数据进行三片备份，当系统满足【一致性】和【容错性】的时候，插入数据的时候为了保证数据的一致性会使平台有300ms的时间不能对外提供服务，避免发生对当前数据发生修改，那么这300ms对于系统来说就算不可用的

由于CAP理论是强制性的理论观点，但是现实环境是运行中间状态产生的，例如当系统数据不一致的时候仍然能对外提服务，只要后续通过异步的方式将数据一致同步过来就行了，例如主从库的时候，主库数据发生变更的时候，并不是立马要求从库数据也要同时发送变更，往往是，主库发送变更后，一段时间之后从库才把数据同步过来，按照这样的方式，大家又总结出了一套理论——【base理论】

BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。相当于曲线救国的方式

接下来看一下BASE中的三要素：

1、基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性----注意，这绝不等价于系统不可用。比如：

（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒

（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

2、软状态

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

3、最终一致性

最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

例如如图：