mysql sharding 方案 分库分表(sharding)系列

(一) 拆分实施策略和示例演示

(四) 多数据源的事务处理

(五) 一种支持自由规划无须数据迁移和修改路由代码的Sharding扩容方案

(一) 拆分实施策略和示例演示

第一部分：实施策略

图1.分库分表(sharding)实施策略图解

1.准备阶段

对进行分库分表(Sharding化)前，需要开发人员充分了解系统业务逻辑和schema.一个好的建议是绘制一张ER图或领域模型图，以这类图为基础划分shard,直观易行，可以确保开发人员始终保持清醒思路。对于是选择ER图还是领域模型图要根据项目自身情况进行选择。如果项目使用数据驱动的开发方式，团队以ER图作为业务交流的基础，则自然会选择ER图，如果项目使用的是领域驱动的开发方式，并通过OR-Mapping构建了一个良好的领域模型，那么领域模型图无疑是最好的选择。就我个人来说，更加倾向使用领域模型图，因为进行切分时更多的是以业务为依据进行分析判断，领域模型无疑更加清晰和直观。

2.分析阶段

1. 垂直切分

垂直切分的依据原则是：将业务紧密，表间关联密切的表划分在一起，例如同一模块的表。结合已经准备好的ER图或领域模型图，仿照活动图中的泳道概念，一个泳道代表一个shard，把所有表划分到不同的泳道中。下面的分析示例会展示这种做法。当然，你也可以在打印出的ER图或模型图上直接用铅笔圈，一切取决于你自己的喜好。

2. 水平切分

垂直切分后，需要对shard内表的数据量和增速进一步分析，以确定是否需要进行水平切分。

2.1若划分到一起的表数据增长缓慢，在产品上线后可遇见的足够长的时期内均可以由单一承载，则不需要进行水平切分，所有表驻留同一shard,所有表间关联关系会得到最大限度的保留，同时保证了书写SQL的自由度，不易受join、group by、order by等子句限制。

2.2 若划分到一起的表数据量巨大，增速迅猛，需要进一步进行水平分割。mysql sharding 方案进一步的水平分割就这样进行：

2.2.1.结合业务逻辑和表间关系，将当前shard划分成多个更小的shard,通常情况下，这些更小的shard每一个都只包含一个主表（将以该表ID进行散列的表）和多个与其关联或间接关联的次表。这种一个shard一张主表多张次表的状况是水平切分的必然结果。这样切分下来，shard数量就会迅速增多。如果每一个shard代表一个独立的，那么管理和维护将会非常麻烦，而且这些小shard往往只有两三张表，为此而建立一个新库，利用率并不高，因此，在水平切分完成后可再进行一次“反向的Merge”,即：将业务上相近，并且具有相近数据增长速率（主表数据量在同一数量级上）的两个或多个shard放到同一个上，在逻辑上它们依然是独立的shard，有各自的主表，并依据各自主表的ID进行散列，不同的只是它们的散列取模（即节点数量）必需是一致的。这样，每个结点上的表数量就相对平均了。

2.2.2. 所有表均划分到合适的shard之后，所有跨越shard的表间关联都必须打断，在书写sql时，跨shard的join、group by、order by都将被禁止，需要在应用程序层面协调解决这些问题。

特别想提一点：经水平切分后，shard的粒度往往要比只做垂直切割的粒度要小，原单一垂直shard会被细分为一到多个以一个主表为中心关联或间接关联多个次表的shard，此时的shard粒度与领域驱动设计中的“聚合”概念不谋而合，甚至可以说是完全一致，每个shard的主表正是一个聚合中的聚合根！

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-54351-1.html