在单体应用时代，我们存储数据常用的关系型数据库有oracle和mysql，数据不断增长的时候，也需要扩容，一般而言就是加硬盘，但是对服务器而言支持硬盘的数量也有上线的，即便服务器cpu、内存再强。在分布式系统中，随着服务的拆分，数据也随之拆分，通过对数据库的合理设计，数据库的水平扩展就可以解决这个问题了。这就是“众人拾柴火焰高”、“人多力量大”。
那么在分布式存储中，我们怎么进行合理的设计，去缓解数据库压力，提高数据操作效率呢？我主要从分表分库、主从复制、数据扩容三方面去梳理一下知识点。

分表分库

分表

我之前做过一个项目，涉及到和银行通信，每一笔钱的存和支在业务系统中都要进行记录，这个表经过几年的积累后，数据量也到了千万条级别。已经到了不得不拆分的地步了。我们根据业务实际需求，我们按照时间维度进行了拆分。拆分示意如下：
trade_log这张表我们从2010年开始用新表，之前的数据还都存储在trade_log中不动，新的数据按照年份进入不同的数据表。trade_log_20**表，是我们提前建好的，这个办法虽然有点普通，但是已经有点那么意思了。
那么在分布式存储中常用的分表方式有两种：垂直分表和水平分表。

垂直分表

垂直分表就是将一个表中的字段分到不同表中。这种情况我之前做过一个项目，有一张合同表，合同表的内容是一个Clob字段，这个字段和其他合同信息要素寸一张表明显不合适，我们就单独分一张表去存储Clob字段，这其实就是一个垂直分表的示例。
合同表拆分后，变成俩表，这两个表中主键保持一致，通过主键关联。

水平分表

水平分表指的是按照某一关键字进行Hash计算以后，以得到的值作为分表依据。这种算法跟负载均衡的Ip-hash策略的算法是一致的，只不过Ip-hash使用的是ip地址。示意如下：
上图所示有5条记录，拆分成3个表，拆分基于id字段的hash值对3取模得余，然后将记录分别存储到相应的表中。上图只是一个示意图，实际中不管基于哪个字段做hash，主流数据库的中间件都已经实现了相关映射，这样存入或者查询的时候才知道数据和表的关联。
其实一开始我举得例子，也算是水平拆分的一种，基于时间或者行政区域维度进行拆分。

分库

数据库的连接数是有上线的，当一个数据库承担不了访问压力的时候，就需要分库了。
常用分库场景有如下几种：

• 根据业务分库，如房源数据库、签约数据库、信用数据库等
• 根据数据访问频率分库，如近一个月以内的网签数据为高频数据，2-6个月的网签数据为中频数据，大于6个月的网签数据为低频数据
• 根据数据访问地域分库，如以国家的行政区划为单位分割数据
• 根据数据时间范围分库
• 根据数据所属租户分库
  分库的数据库架构一般如下图所示：
  分库后，应用访问数据库需要经过负载均衡器，区分读还是写操作，不同的操作访问不同的数据库。另外数据库需要有监控机制，检测数据库的健康状况，在每个集群里面主库负责写，从库负责读，从库出错需要启动熔断机制停止访问，主库出错需要通过选举机制选出新的主库。

分表（库）查询

主从复制

在分库的数据库架构中，我们了解了主库和从库的知识，主库负责写操作，从库负责读操作。通过读写分离和数据库集群，我们解决了数据库的高可用问题，但数据如何同步的问题也随之而来。
常用的主从库数据保持一致的方式有：同步数据复制和异步数据复制。

同步数据复制

这种方式保持了主从库的数据强一致性，但是可用性、效率都差了。

异步数据复制

这种方式采用了主从数据库弱一致性（最终一致性），但是提高了可用性和效率。

Mysql主从复制

现实中Mysql应用还是比较广泛的，我了解了下Mysql的主从复制原理，如下图所示：
简单来说就是从库读取主库的二进制日志文件，每次记录文件名称和文件日志位置，以做增量同步。Mysql提供了两种主从复制方式：

• 根据行记录（Row Level）方式复制
  主库的二进制日志文件记录每条数据的修改方式，从库可以根据主库记录的数据修改方式来进行修改数据。优点是只需要记录哪条数据被修改过，修改结果是什么；缺点是记录量大。
• 根据语句（Statement Level）方式复制
  此方式是根据对数据修改的sql语句，在从库重新执行一遍就可以。优点是记录量小节省空间；缺点是需要注意数据库版本问题，必须保证从库执行的所有语句都能正确执行且执行结果一致。

数据扩容

数据扩容主要是借助负载均衡代理来实现的，可以参考我之前的一篇文章《【分布式架构】单体优化遇瓶颈，负载均衡显神通》，主要是分布式一致性算法。

参考《分布式架构原理与实践》 崔皓