概述
对分布式和微服务系统来说，一种业务就可能有很多的数据，比如电商场景中的交易记录，单数据库也很有可能无法支撑，需要多个数据库节点进行支持，这种需要将数据库拆分为多节点进行存储的技术，即分布式数据库技术，这里只把分表、分库和分区概念梳理一遍。
分表
分表是指在一个或者多个数据库实例内，将一张表拆分为多张表存储。
分表是因为该表需要存储很庞大的记录数，如果将其堆积到一起，就会导致数据量过于庞大引发性能瓶颈。（一般MySQL的表是5000万条记录左右,性能会下降）
一般分表会按照某种规则进行拆分，比如上面提到的交易记录，若按年份拆分
上图可以看到，将同一个数据库中的交易记录表按年份进行拆分，可以使交易记录不再只保存在一个表中，从而避免单表数据记录过多的问题。但是这样的分法也会导致一些问题，就是一张表不再存在全部完整的数据，进行总体查询的时候，需要分表查找，在做统计和分析时，需要跨表查询，这时需要引入路由算法和合并算法等才能得到所需的数据
分库
分库是指将一套数据库的设计结构，部署到多个数据库实例的节点中去，在应用的时候，按照一定的方法通过多个数据库实例节点访问数据。数据库实例的节点可以是同一台机器多个数据库实例，也可以是一台机器一个数据库实例，最后通过路由算法来查询使用数据。
因为将数据库分为多个节点，所以需要一个路由算法来确定数据具体存放在哪个库中，于是路由算法就成了我们关注的核心内容之一。
最简单的路由算法是求余算法
例如，现在划分了3个数据库dataSource0,dataSource1,dataSource2。在分布式ID生成服务中，我们获取交易记录ID（orderId，假设是一个Long型数据）后，采用orderId对3求余（orderId%3），得到余数（可能为0或1或2），然后再根据余数存放到对应的库中。
当然，这里只是举个例子来更形象地解释分库的概念，实际生产环境中，算法规则比这个复杂许多。而且上边简单求余算法方案存在弊端，伸缩性不够，如果数据持续增长，需要增加数据库的话，对于规则又要改变了，对旧数据必须迁移。后面我们还会对此介绍一致性哈希算法。
分区
分区是指一张表的数据分成n个区块，在逻辑上看，最终只是一张表，但底层是由n个物理区块组成的
分区技术与分表技术很类似，只是分区技术属于数据库内部的技术，对于开发者来说，它逻辑上仍旧是一张表，开发时不需要改变SQL表名。它只是对数据库进行设置，把存储的数据划分为多个区存储。
因为分区不属于分布式技术范畴，所以不深入讨论。
总结
在分布式或微服务系统环境下，因为分表会导致表名变化，产生逻辑不一致，继而加大后续开发的工作量和统计上的困难，所以分表技术已经渐渐淡出了人们的选择。
当前采用更多的是分库技术，分库技术的伸缩性更好，可以增加节点，也可以减少节点，比较灵活。但是由于分布在多个节点中，因此需要其他的技术将它们整合成为一个整体。
拓展
一致性哈希算法
一致性哈希算法，也称为一致性哈希算法，它是1997年麻省理工学院提出的一种算法。它首先假设一个圆由232个点构成
假设我们现在有4个库，依次编号为Node A、Node B、Node C和NodeD，它们都是我们数据库的节点，根据编号求出哈希值，就可以放到哈希环的节点中了，如下图
这里提出两点假设:
- 假设Node A、Node B、Node C和NodeD这4个节点的哈希值为Hash A、Hash B、Hash C和Hash D，根据上图就可以得到以下5个区间：[0, HashA]、[Hash A, Hash B]、[Hash B, Hash C]、[Hash C, Hash D]和[Hash D,2^32 −1)
- 假设对orderId也求哈希值，记为n，而n必然落入Node A、Node B、NodeC和NodeD这4个节点所产生的5个区间之中
在一致性哈希算法中，对于n，采用顺时针方向找到下一个数据库节点，用来存放该数据,如下:
场景1：Hash A< n < Hash B
那么根据数据库节点在哈希环中的分布图，按顺时针方向找到的下一个数据库节点就是Node B节点
场景2：0<= n < Hash A
那么根据数据库节点在哈希环中的分布图，按顺时针方向找到的下一个数据库节点就是Node A节点
场景3：Hash D < n <= 2^32
那么根据数据库节点在哈希环中的分布图，按顺时针方向找到的下一个数据库节点就是Node A节点
一致性哈希算法，对于伸缩性大有好处：当我们减少一个节点的时候，只需要将减少的那个节点的数据插入到顺时针的下一个节点即可；当我们新增一个节点的时候，只需要通过哈希值计算将下一个节点的部分数据分配给新增节点即可。从上述可以知道，通过一致性哈希算法，新增或者减少节点，只需要移动附近节点的数据即可，无须全局迁徙，所以一致性哈希算法非常合适那些需要经常增加和删除存储节点的应用
问题:区间[0, 232 −1]很大，实践中可能并不需要那么大的区间，是否可以缩小区间，以简化我们的开发？
在实际环境中可以考虑缩小区间，但在缩小区间之前，需要先进行合理的评估，例如，如果觉得预留1000个数据库就足够未来用了，那么就可以采用区间[0, 1023]作为哈希环。
这里提供 数据源的一致性哈希算法,创建DataSourceHashHandler.java类
package org.zhangsan.beans;
import java.util.SortedMap;
import java.util.TreeMap;
/**
* @ClassName DataSourceHashHandler
* @Description //DataSourceHashHandler 数据源的一致性哈希算法
* @Author singleZhang
* @Email 405780096@qq.com
* @Date 2020/12/9 0009 下午 5:19
**/
public class DataSourceHashHandler {
private static SortedMap<Integer,String> sortedMap = new TreeMap<>();
/**
* 添加数据源
* */
public static void addDbKey(String dbKey){
int hash = getHash(dbKey);
System.out.println(dbKey+"----->"+hash);
sortedMap.put(hash,dbKey);
}
/**
* 根据hash值获取数据源
* */
private static String getDataSource(String node){
//计算字符串的hash值
int hash = getHash(node);
//如果hash大于sortedMap里的所有值
SortedMap<Integer,String> subMap = sortedMap.tailMap(hash);
Integer firstKey = null;
//如果没有大于该节点hash值的数据，就取哈希值最小的数据源
if(subMap == null || subMap.isEmpty()){
firstKey = sortedMap.firstKey();
}else{
firstKey = subMap.firstKey();
}
return sortedMap.get(firstKey);
}
/**
* 使用FNV1 32位hash算法计算字符串的hash值
* 比较简单的demo:传入字符串，按字符串里的字符顺序 把它打乱 取值
* @param str : 需要计算hash值的字符串
* */
private static int getHash(String str){
final int p = 16777619;
int hash = (int)2166136261L;
for(int i =0;i<str.length();i++){
hash = (hash ^ str.charAt(i))*p;
}
hash += hash << 13;
hash ^= hash << 7;
hash += hash << 3;
hash ^= hash << 17;
hash += hash << 5;
if(hash < 0){
hash = Math.abs(hash);
}
return hash;
}
}
总结和延伸
当然，在实际开发过程中，我们不会自己再去早轮子，因为业界已经有一些成熟的分库分表中间件解决方案，如ShardingSphere、MyCat等。
这里介绍一下ShardingSphere，它是Apache基金会下的一个孵化项目，它是由一套开源的分布式数据库中间件解决方案组成的生态圈，主要关注数据分片、分布式事务和数据库协调。它的前身是Sharding JDBC，Sharding JDBC是当当网发布的一款分布式数据库中间件，该中间件在发布后，获得了广泛的使用，在业界很流行。因为ShardingJDBC很成功，所以ShardingSphere就将其纳入进来成为其孵化项目之一。
ShardingSphere主要由以下3个产品构成:
- Sharding-JDBC
- Sharding-Proxy
- Sharding-Sidecar
我们只需要关心Sharding-JDBC，因为Sharding-Proxy是DBA关心的内容，Sharding-Sidecar还没有发布版本。
