关系型数据存储渐进式方案

在互联网时代，数据的膨胀速度飞快，项目初期的单数据库实例往往很快就会成为系统瓶颈。在数据规模达到一定阶段后，往往就需要对系统数据存储方式进行优化，来支撑未来更高的数据读写压力。

首先我们要有明确的目前，数据优化要保证 高可用、一致性、可扩展 三个原则

基于这既定的原则，我们就来介绍下业内比较常见的一些针对关系型数据存储方案以及演进过程

 

---

一、单实例架构  

很多公司在项目初期，在基本不考虑可用性的情况下，有些会采用单数据库实例来节省运维成本。所有的数据读写都针对单库完成。这种架构方式在节省成本的情况下同样存在着极大的运维风险，一旦数据库实例异常宕机或网络不可用时，整个系统都将瘫痪，无法进行数据流转。

孤独的实例

 

二、多实例架构

  1、主备模式

主备集群架构

主备模式主要是指，给之前的单实例数据库增加备用机。备用机平时只保持与主库中数据一致，单并不承载任何的数据操作功能。当主库出现异常无法正常读写后，备机站出来充当新的主库。

对于这种主备切换，我们当然希望能够无需人为介入，在主库发生问题时，可以直接将流量打到备用库上。这里我们引入了keeplived组件，基于虚拟IP漂移来完成主备切换。具体原理可以参考 https://blog.csdn.net/liuyujiao60/article/details/89711527

这种方案解决了单实例可用性低的问题，但是在性能上并没有增加，备库永远是处于闲置状态，这是一种相对比较奢侈的方案

  2、双主模式

双主集群架构

双主模式是对主备模式的改进，备库也被作为主库向外提供数据读写能力，这样数据操作的性能就变成了主备模式的两倍。但随之而来的问题是，两个数据库之间数据一致性问题。因为数据在多实例之间同步有一定的延时，如果服务写入时，数据操作落在了主库A上，而读时落在了主库B上，就可能发生数据不一致。刚写入成功的数据，不见了。另外对于乐观锁、唯一索引、自增主键，双主简直就是灾难型的数据库架构。

  3、读写分离模式

读写分离

基于对双主模式的分析，显然不太适合具有复杂写操作的系统。因此我们还是需要将写操作收归到一个实例上。毕竟读操作与写操作的不一致，是暂时的，最终是一致的；多实例的数据冲突，则是不可自动恢复的。那么，我们就没有什么办法能够提高数据库性能了吗？

当然不是，虽然写性能有着必然的局限性，但读操作还是有很大扩展空间的。我们可以通过横向增加多台备用库，并让备用库向外提供数据读的能力。当然这种情况依然存在数据一致性的问题，分布式系统的CAP里，一致性和高可用本身就是冲突的。我们只能够保证最终一致性。

  4、分库分表

上面的三种模式都没有很好的解决写性能的问题，并且当单库单表数据体量增长到一定程度后，由于主库与备库、写库与读库的数据体量都相同，因此所有数据库的读写性能都会急剧下降。这时，我们就要考虑分治了。

无论双主还是读写分离，都没有能够很好的解决数据一致性的问题，如果我们有方案能够对同一条数据的写和读能够落到同一个实例的同一个表内，那么数据一定是一致的。

基于分治思想，我们可以将数据存储分为多个单元，让每个存储单元内的数据，都控制在一定体量内。然后我们通过一种固定规则，将同一维度的数据都导向相同的数据存储单元。这样我们就既保证了读写的性能，又保证了数据的一致性。

---

待续。。。