掌握之分布式-6.分布式数据库

掌握高并发、高可用架构

第三章 分布式

本章介绍分布式架构的底层技术。主要说明面试过程中可能被问到的技术点。

第六节 分布式数据库MyCat

分库分表 Sharding

1. 分库分表的方法

垂直切分，也就是因为表多而数据多，将关系紧密（比如统一模块）的表切分出来放到一个服务器中

水平切分，表不多，而是表中数据量庞大，也就是把表的数据按照某种规则切分到多个服务器中

现实中多是这两种的混合

2. 分库分表需要解决的问题

• 事务问题

  解决方案一：使用分布式事务；优点是，由数据库管理，简单有效；缺点是，性能代价高

  解决方案二：将分布式事务拆分成单个数据库的小事务，通过程序来总控各个小事务；优点，性能好一些；缺点，代码耦合高

• 跨节点join的问题

  只要是进行切分，跨节点Join问题不可避免。但良好的设计和切分可以减少此类情况的发生

  普遍的解决方案是分两次查询，第一次查询找出关联数据的ID，然后根据这些ID发起第二次的查询

• 跨节点的count、order by、group by以及聚合函数问题

  这是一类问题，因为它们都需要基于全部数据进行计算，而多数的代理都不会自动处理合并工作

  解决方案与跨节点Join一样，分别在各个节点得到结果后在应用程序进行合并，不同的是每个节点的查询可以并行执行

• 数据迁移、容量规划、扩容的问题

• ID问题

  一旦数据库被切分到多个物理节点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的ID无法保证全局唯一性；另一方面，应用程序在插入数据之前要先获取到ID，以便对SQL进行路由

  以下是常见的主键生成策略

  UUID，简单，但是数据过长，占空间，而且建索引和基于索引进行查询都有性能问题

  基于数据库维护一个Sequence表，表的压力会很大，而且有单点问题，一旦发生故障，整个应用程序将无法使用

  Twitter的分布式自增ID算法Snowflake

• 跨节点的排序分页

  一般来说，分页时需要按照指定字段进行排序。当排序字段就是分片字段时，我们根据分片规则可以比较容易定位到指定的分片，当排序字段不是分片字段时，情况就比较复杂了。为了最终结果的准确性，我们需要在不同的分片节点中将数据进行排序并返回，并将不同分片的结果集进行汇总和再次排序，最后再返回给用户

  

  如果只是取第一页的数据，看起来对性能的影响并不大。但是，如果取第10页的数据，情况将复杂的多。

  

  因为各分片节点的数据都是随机的，为了排序的准确性，必须把所有分片节点的前N页数据都排序好后做合并，最后再进行整体的排序。特别的消耗资源，分页页码越大，性能越差。

  解决方案如下：

  在前端做分页，并且限定只能看前n的数据

  如果是后台程序要获取分页数据，可以加大page size，比如获取5000条记录，有效减少分页数

  分库设计时，配套大数据平台汇总所有分库的记录，有些分页查询可以走大数据平台

• 分库数量

  分库数量和弹库能处理的记录数有关，一般来说，MySql单库超过5000万条记录，Oracle单库超过1亿条记录，DB压力就很大。一般建议初次分库数量为4-8个库

3. 分布式事务

• XA规范

  主要定义了（全局）事务管理器（Transaction Manager）和（局部）资源管理器（Resource Manager）之间的接口。XA接口是双向的系统接口，在事务管理器和一个或多个资源管理器之间形成通信桥梁

  事务管理器控制着全局事务，管理事务生命周期，并协调资源

  资源管理器负责控制和管理实际资源

• JTA（Java Transaction API）

  Java平台上的事务规范，它仅定义了接口，具体实现则由具体的提供商来实现

• 两阶段提交

  

  第一阶段，准备阶段：事务协调者（事务管理器）给每个参与者（资源管理器）发送Prepare消息，每个参与者要么直接返回失败，要么在本地执行事务，写本地的redo和undo日志，但不提交

  第二阶段，提交阶段：如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚（Rollback）消息，否则，发送Commit消息；参与者根据协调者的指令执行回滚或提交操作，并释放所有事务处理过程中的锁资源

  优点：效率高

  缺点：当事务的并发量达到一定数量时，会出现大量的事务积压甚至出现死锁，系统性能会严重下降

• 一阶段提交（Best Efforts 1PC模式）

  就是从应用程序向数据库发出请求到数据库完成提交或回滚之后将结果返回给应用程序的过程，非常直白

• 事务补偿机制

  像Best Efforts 1PC模式，前提是应用程序能获取所有的数据源，然后使用同一个事务管理器（指Spring的事务管理器）管理事务，最典型的应用场景是数据库sharding

  对于那些基于WebService、RPC、JMS等高度自治的分布式系统接口，Best Efforts 1PC无能为力，可以通过事务补偿机制来实现最终一致性