分布式数据库技术简介

Posted 2021-03-31 戏说码农职场

背景

大规模高并发的访问, 使得单机数据库捉襟见肘了

基础知识

分表: 是指在一个或多个数据库实例内,将一张表拆分为多个表存储. 也就是说分表是因为该表需要存储很庞大的记录数，如果将其堆积到一起，就会导致数据量过于庞大（一般mysql的表是5000万条记录左右）引发性能瓶颈。一般分表会按照某种算法进行拆分，如交易记录，可能按年份拆分.

分表意味着跨表查询, 所以设计好路由算法就十分重要.

分库: 是指将一套数据库结构,部署到多个应用实例. 很明显这种情况也需要合适的路由算法, 找到相应的库, 比如取模求余.

分区: 指一个表的数据分为n个区块, 逻辑看是一个表, 底层是n个不同的物理块组成.

处理方式

数据库的切分类型包括水平和垂直切分, 每一个都有对应的优点和缺点. 罗列下:

1. 水平切分

就是将数据库数据按照完整的字段进行库内分表和分库分表. 其中库内分表 总体上还是在这个数据库实例访问, 没有降低数据库的压力, 尽量使用分库分表.

2. 垂直切分

把字段进行切割, 将访问频次较高的放在一起, 不经常访问的列为一起.   可以参考计算机科学中著名的局部性原理, 可以提高并发能力.

3. 切分规则

(1). 为每一个分表预定义数据范围

如按照时间区间或ID区间来切分。例如：按日期将不同月甚至是日的数据分散到不同的库中；将userId为1~9999的记录分到第一个库，10000~20000的分到第二个库，以此类推。某种意义上，某些系统中使用的"冷热数据分离"，将一些使用较少的历史数据迁移到其他库中，业务功能上只提供热点数据的查询，也是类似的实践。缺点是热点数据成为性能瓶颈。连续分片可能存在数据热点，例如按时间字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查询

(2) 数值取模

根据数据取模, 获取对应数据库名称, 比如userDB00,......userDB09. 我们可以对userid mod 10 获取字库名称, 然后再查询对应分表数据.

优点:

数据均为分布, 不容易产生热点

缺点:

后期分片集群扩容时，需要迁移旧的数据（使用一致性hash算法能较好的避免这个问题）

容易面临跨分片查询的复杂问题。比如上例中，如果频繁用到的查询条件中不带cusno时，将会导致无法定位数据库，从而需要同时向4个库发起查询，再在内存中合并数据，取最小集返回给应用，分库反而成为拖累

带来的问题

1. 分布式事务一致性问题

分布式事务实现方案从类型上去分刚性事务、柔型事务。

刚性事务：通常无业务改造，强一致性，原生支持回滚/隔离性，低并发，适合短事务,包括XA 协议（2PC、JTA、JTS）、3PC

柔性事务：有业务改造，最终一致性，实现补偿接口，实现资源锁定接口，高并发，适合长事务。包括TCC/FMT、Saga（状态机模式、Aop模式）、本地事务消息、消息事务（半消息）、最多努力通知型事务

2. 跨节点join  解决方式

(1) 全局表, 类似spark全局变量, broadcast常用的表, 每一个节点都创建table, 避免跨节点join

(2) 冗余字段, 把需要join获取的字段添加到该表, 就不需要join了, 可以考虑非忙时, 跑一个定时job, 处理这个数据.

3. 跨节点分页、排序、函数问题

跨节点多库进行查询时，会出现limit分页、order by排序等问题。分页需要按照指定字段进行排序，当排序字段就是分片字段时，通过分片规则就比较容易定位到指定的分片；当排序字段非分片字段时，就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序，最终返回给用户, 其实类似es查询原理。如图所示：

3. 全局主键问题

参见我的上篇文章

分库分表工具

1. sharding-sphere

ShardingSphere是Apache基金会下的一个孵化项目，它是由一套开源的分布式数据库中间件解决方案组成的生态圈，主要关注数据分片、分布式事务和数据库协调。它的前身是Sharding JDBC，Sharding JDBC是当当网发布的一款分布式数据库中间件，该中间件在发布后，获得了广泛的使用，在业界很流行。因为Sharding JDBC很成功，所以ShardingSphere就将其纳入进来成为其孵化项目之一。

2. TDDL

3. MyCat

具体可以参考:分库分表中间件工具

参考: <Spring Cloud微服务和分布式系统实战>

老刘：拜托，面试别再问我数据库的分库分表！