分布式数据库

分布式数据库是用来解决单一数据库或单一数据表的存储压力和访问压力的一种手段。

业务分库

顾名思义，就是将单一数据库服务按照业务领域划分，将相同领域的一类表分散到不同的数据库服务中，从而提升整个存储服务的读写性能。举例来说，将原先的包含全表的商城库，拆分成订单库、商品库和用户库，并且将这些库分散到各自独立的数据库服务中。

这种方式是在发现单一数据库读写性能有瓶颈的时候，起手的第一招，具体操作也比较简单，在业务服务已经划分领域的情况下，只要改变不同业务服务的JDBC连接就可以，如果业务服务还是单体的，那么业务服务可以使用轻量级的sharding jdbc工具来处理。当然，这样一拆之后，原先的JOIN操作就会有部分不能用——涉及的表跨库，这样的话，放在业务服务里取处理也是个方法。

水平分库分表

分表的原则是单表数据量多大，并且未来将继续增长，通常大家都把千万级的数据量最为一张表要分表的量级标准，这个数量可以参考，具体还需要看该表的业务场景而论，当然，当一张表的数量已经增长到千万级的时候，并且未来还会继续增长，我们就要对他重点关注了。

如何来分表，是关键的问题。常用的有水平分表和垂直分表，水平分表的含义是将表横着划一刀，将数据分散到各个独立的表中；而垂直分表的含义是将表竖着砍一刀，将数据字段值分散到独立的表中，而各个表中的数据量是全量的。这两种方式各有场景，我们重点描述的是水平分库分表，它的含义是先水平分表，然后将切分后的表均匀的分到每个独立的数据库服务中，每个数据库服务可以存一张切分表，也可以存多张切分表。

Sharding Key和路由算法的选择

明确了水平分表的方式后，就需要确定Sharding Key，具体的就是表中的某个字段（或者某几个字段），用这个字段并且经过路由算法来确认，需要的数据具体在哪个分片中。常用的是表的主键，或者多数业务查询需要使用的字段，不能一概而论，需要确认业务场景，就比如说订单表的切分，如果按照订单主键来切分，那如果使用用户ID来查询，就不灵了，而我们知道通过用户ID来查订单是高频操作，这时候有显得捉襟见肘了。

常用的路由算法

范围查询

如主键是递增的那么就可以按照区间范围来定位分片，而且天然的支持水平扩容，原先的数据无需迁移，但是会造成某个分片上数据的不均衡，使用创建时间也可以。

HASH

通过计算hash(sharding key) % 分片数来定位分片位置，优势在于各个分片上数据均匀，但是扩容的时候，由于分片数增加导致计算的分片位置与原先的不一致，而使得数据需要迁移。可以使用一致性HASH来处理，增加分片数，仅有小部分数据需要迁移。

路由表

通过一张独立的表来存储sharding key与具体分片的位置，优势是配置灵活，扩容后只需修改路由表的对应关系即可，然而需要多做依次查询，有性能消耗，况且该表数据量增大后要则么办呢？对这张表进行分表嘛：），这也台可怕了！

常见的情况下，使用的还是HASH路由算法。