mycat实战之理论

一、了解背景知识（摘自mycat官网）

（1）OLTP 和 OLAP

在互联网时代，海量数据的存储与访问成为系统设计与使用的瓶颈问题，对于海量数据处理，按照使用场
景，主要分为两种类型：联机事务处理（OLTP）和联机分析处理（OLAP）。
联机事务处理（OLTP）也称为面向交易的处理系统，其基本特征是原始数据可以立即传送到计算中心进行处
理，并在很短的时间内给出处理结果。
联机分析处理（OLAP）是指通过多维的方式对数据进行分析、查询和报表，可以同数据挖掘工具、统计分析
工具配合使用，增强决策分析功能。对于两者的主要区别可以用下表来说明：

（2）、关系型数据库和 NoSQL 数据库

针对上面两类系统有多种技术实现方案，存储部分的数据库主要分为两大类：关系型数据库与 NoSQL 数据
库。
关系型数据库，是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的
数据。主流的 oracle、DB2、MS SQL Server 和 mysql 都属于这类传统数据库。
15
NoSQL 数据库，全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的
时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要分为临时性键值存储
（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、
CouchDB）、面向列的数据库（Cassandra、HBase），每种 NoSQL 都有其特有的使用场景及优点。
Oracle，mysql 等传统的关系数据库非常成熟并且已大规模商用，为什么还要用 NoSQL 数据库呢？主要是
由于随着互联网发展，数据量越来越大，对性能要求越来越高，传统数据库存在着先天性的缺陷，即单机（单
库）性能瓶颈，并且扩展困难。这样既有单机单库瓶颈，却又扩展困难，自然无法满足日益增长的海量数据存储
及其性能要求，所以才会出现了各种不同的 NoSQL 产品，NoSQL 根本性的优势在于在云计算时代，简单、易于
大规模分布式扩展，并且读写性能非常高。

优缺点：

（3）、垂直切分
相对于垂直拆分，水平拆分不是将表做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中
包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中的某些行切分
到一个数据库，而另外的某些行又切分到其他的数据库中，如图：

系统被切分成了，用户，订单交易，支付几个模块。
一个架构设计较好的应用系统，其总体功能肯定是由很多个功能模块所组成的，而每一个功能模块所需要的
数据对应到数据库中就是一个或者多个表。而在架构设计中，各个功能模块相互之间的交互点越统一越少，系统
的耦合度就越低，系统各个模块的维护性以及扩展性也就越好。这样的系统，实现数据的垂直切分也就越容易。
但是往往系统之有些表难以做到完全的独立，存在这扩库 join 的情况，对于这类的表，就需要去做平
衡，是数据库让步业务，共用一个数据源，还是分成多个库，业务之间通过接口来做调用。在系统初期，数据量
比较少，或者资源有限的情况下，会选择共用数据源，但是当数据发展到了一定的规模，负载很大的情况，就需
要必须去做分割。
一般来讲业务存在着复杂 join 的场景是难以切分的，往往业务独立的易于切分。如何切分，切分到何种
程度是考验技术架构的一个难题。
下面来分析下垂直切分的优缺点：

优点：

拆分后业务清晰，拆分规则明确；
系统之间整合或扩展容易；
数据维护简单

缺点：

部分业务表无法 join，只能通过接口方式解决，提高了系统复杂度；
受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高；
事务处理复杂。

由于垂直切分是按照业务的分类将表分散到不同的库，所以有些业务表会过于庞大，存在单库读写与存储瓶
颈，所以就需要水平拆分来做解决

（3）、水平切分

相对于垂直拆分，水平拆分不是将表做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中
包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中的某些行切分
到一个数据库，而另外的某些行又切分到其他的数据库中，如图

拆分数据就需要定义分片规则。关系型数据库是行列的二维模型，拆分的第一原则是找到拆分维度。比如：
从会员的角度来分析，商户订单交易类系统中查询会员某天某月某个订单，那么就需要按照会员结合日期来拆
分，不同的数据按照会员 ID 做分组，这样所有的数据查询 join 都会在单库内解决；如果从商户的角度来讲，要查
询某个商家某天所有的订单数，就需要按照商户 ID 做拆分；但是如果系统既想按会员拆分，又想按商家数据，则
会有一定的困难。如何找到合适的分片规则需要综合考虑衡量。
几种典型的分片规则包括：

按照用户 ID 求模，将数据分散到不同的数据库，具有相同数据用户的数据都被分散到一个库中；
按照日期，将不同月甚至日的数据分散到不同的库中；
按照某个特定的字段求摸，或者根据特定范围段分散到不同的库中。

如图，切分原则都是根据业务找到适合的切分规则分散到不同的库，下面用用户 ID 求模举例

既然数据做了拆分有优点也就优缺点

优点：

拆分规则抽象好，join 操作基本可以数据库做；
不存在单库大数据，高并发的性能瓶颈；
应用端改造较少；
提高了系统的稳定性跟负载能力。

缺点：

拆分规则难以抽象；
分片事务一致性难以解决；
数据多次扩展难度跟维护量极大；
跨库 join 性能较差。

前面讲了垂直切分跟水平切分的不同跟优缺点，会发现每种切分方式都有缺点，但共同的特点缺点有：

引入分布式事务的问题；
跨节点 Join 的问题；
跨节点合并排序分页问题；
多数据源管理问题。

针对数据源管理，目前主要有两种思路：
A. 客户端模式，在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据
库，在模块内完成数据的整合；
B. 通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；
可能 90%以上的人在面对上面这两种解决思路的时候都会倾向于选择第二种，尤其是系统不断变得庞大复杂
的时候。确实，这是一个非常正确的选择，虽然短期内需要付出的成本可能会相对更大一些，但是对整个系统的
扩展性来说，是非常有帮助的。
Mycat 通过数据切分解决传统数据库的缺陷，又有了 NoSQL 易于扩展的优点。通过中间代理层规避了多数
据源的处理问题，对应用完全透明，同时对数据切分后存在的问题，也做了解决方案。下面章节就分析，mycat
的由来及如何进行数据切分问题。
由于数据切分后数据 Join 的难度在此也分享一下数据切分的经验：
第一原则：能不切分尽量不要切分。
第二原则：如果要切分一定要选择合适的切分规则，提前规划好。
第三原则：数据切分尽量通过数据冗余或表分组（Table Group）来降低跨库 Join 的可能。
第四原则：由于数据库中间件对数据 Join 实现的优劣难以把握，而且实现高性能难度极大，业务读取尽量
少使用多表 Join。

二、了解mycat分片规则（摘自mycat官网）

1 、分片枚举
通过在配置文件中配置可能的枚举 id，自己配置分片，本规则适用于特定的场景，比如有些业务需要按照省
份或区县来做保存，而全国省份区县固定的，这类业务使用本条规则，配置如下：

<tableRule name="sharding-by-intfile">
<rule>
<columns>user_id</columns>
<algorithm>hash-int</algorithm>
</rule>
</tableRule>
<function name="hash-int" class="io.mycat.route.function.PartitionByFileMap">
<property name="mapFile">partition-hash-int.txt</property>
<property name="type">0</property>
<property name="defaultNode">0</property>
</function>

partition-hash-int.txt 配置：

10000=0
10010=1
DEFAULT_NODE=1

上面 columns 标识将要分片的表字段，algorithm 分片函数，
其中分片函数配置中，mapFile 标识配置文件名称，type 默认值为 0，0 表示 Integer，非零表示 String，
所有的节点配置都是从 0 开始，及 0 代表节点 1
/**
* defaultNode 默认节点:小于 0 表示不设置默认节点，大于等于 0 表示设置默认节点
* 默认节点的作用：枚举分片时，如果碰到不识别的枚举值，就让它路由到默认节点
* 如果不配置默认节点（defaultNode 值小于 0 表示不配置默认节点），碰到
* 不识别的枚举值就会报错，
* like this：can’t find datanode for sharding column:column_name val:ffffffff */

2 固定分片 hash 算法
本条规则类似于十进制的求模运算，区别在于是二进制的操作,是取 id 的二进制低 10 位，即 id 二进制
&1111111111。
此算法的优点在于如果按照 10 进制取模运算，在连续插入 1-10 时候 1-10 会被分到 1-10 个分片，增
大了插入的事务控制难度，而此算法根据二进制则可能会分到连续的分片，减少插入事务事务控制难度。

<tableRule name="rule1">
<rule>
<columns>user_id</columns>
<algorithm>func1</algorithm>
</rule>
</tableRule>
<function name="func1" class="io.mycat.route.function.PartitionByLong">
<property name="partitionCount">2,1</property>
<property name="partitionLength">256,512</property>
</function>

配置说明：
上面 columns 标识将要分片的表字段，algorithm 分片函数，
partitionCount 分片个数列表，partitionLength 分片范围列表
分区长度:默认为最大 2^n=1024 ,即最大支持 1024 分区
约束 :
count,length 两个数组的长度必须是一致的。
1024 = sum((count[i]*length[i])). count 和 length 两个向量的点积恒等于 1024
用法例子：
本例的分区策略：希望将数据水平分成 3 份，前两份各占 25%，第三份占 50%。（故本例非均匀分区）
// |<———————1024———————————>|
122
// |<—-256—>|<—-256—>|<———-512————->|
// | partition0 | partition1 | partition2 |
// | 共 2 份,故 count[0]=2 | 共 1 份，故 count[1]=1 |
int[] count = new int[] { 2, 1 };
int[] length = new int[] { 256, 512 };
PartitionUtil pu = new PartitionUtil(count, length);

// 下面代码演示分别以 offerId 字段或 memberId 字段根据上述分区策略拆分的分配结果
int DEFAULT_STR_HEAD_LEN = 8; // cobar 默认会配置为此值
long offerId = 12345;
String memberId = "qiushuo";
// 若根据 offerId 分配，partNo1 将等于 0，即按照上述分区策略，offerId 为 12345 时将会被分配
到 partition0 中
int partNo1 = pu.partition(offerId);
// 若根据 memberId 分配，partNo2 将等于 2，即按照上述分区策略，memberId 为 qiushuo 时将会被
分到 partition2 中
int partNo2 = pu.partition(memberId, 0, DEFAULT_STR_HEAD_LEN);

如果需要平均分配设置：平均分为 4 分片，partitionCount*partitionLength=1024

<function name="func1" class="io.mycat.route.function.PartitionByLong">
<property name="partitionCount">4</property>
<property name="partitionLength">256</property>
</function>

3 范围约定
此分片适用于，提前规划好分片字段某个范围属于哪个分片，
start <= range <= end.

range start-end ,data node index
K=1000,M=10000.

<tableRule name="auto-sharding-long">
<rule>
<columns>user_id</columns>
<algorithm>rang-long</algorithm>
</rule>
</tableRule>
<function name="rang-long" class="io.mycat.route.function.AutoPartitionByLong">
<property name="mapFile">autopartition-long.txt</property>
<property name="defaultNode">0</property>
</function>

配置说明：
上面 columns 标识将要分片的表字段，algorithm 分片函数，
rang-long 函数中 mapFile 代表配置文件路径
defaultNode 超过范围后的默认节点。
所有的节点配置都是从 0 开始，及 0 代表节点 1，此配置非常简单，即预先制定可能的 id 范围到某个分片
0-500M=0
500M-1000M=1
1000M-1500M=2
或
0-10000000=0
10000001-20000000=1
4 取模
此规则为对分片字段求摸运算。

<tableRule name="mod-long">
<rule>
<columns>user_id</columns>
<algorithm>mod-long</algorithm>
</rule>
</tableRule>
<function name="mod-long" class="io.mycat.route.function.PartitionByMod">
<!-- how many data nodes -->
<property name="count">3</property>
</function>

配置说明：
上面 columns 标识将要分片的表字段，algorithm 分片函数，
此种配置非常明确即根据 id 进行十进制求模预算，相比固定分片 hash，此种在批量插入时可能存在批量插入单
事务插入多数据分片，增大事务一致性难度。
5 按日期（天）分片
此规则为按天分片。

<tableRule name="sharding-by-date">
<rule>
<columns>create_time</columns>
<algorithm>sharding-by-date</algorithm>
</rule>
</tableRule>
<function name="sharding-by-date" class="io.mycat.route.function.PartitionByDate">
<property name="dateFormat">yyyy-MM-dd</property>
<property name="sBeginDate">2014-01-01</property>
<property name="sEndDate">2014-01-02</property>
<property name="sPartionDay">10</property>
</function>

配置说明：
columns ：标识将要分片的表字段
algorithm ：分片函数
dateFormat ：日期格式
sBeginDate ：开始日期
sEndDate：结束日期
sPartionDay ：分区天数，即默认从开始日期算起，分隔 10 天一个分区
如果配置了 sEndDate 则代表数据达到了这个日期的分片后后循环从开始分片插入。
Assert.assertEquals(true, 0 == partition.calculate(“2014-01-01”));
Assert.assertEquals(true, 0 == partition.calculate(“2014-01-10”));
Assert.assertEquals(true, 1 == partition.calculate(“2014-01-11”));
Assert.assertEquals(true, 12 == partition.calculate(“2014-05-01”));
6 取模范围约束
此种规则是取模运算与范围约束的结合，主要为了后续数据迁移做准备，即可以自主决定取模后数据的节点
分布。

<tableRule name="sharding-by-pattern">
<rule>
<columns>user_id</columns>
<algorithm>sharding-by-pattern</algorithm>
</rule>
</tableRule>
<function name="sharding-by-pattern"
class="io.mycat.route.function.PartitionByPattern">
<property name="patternValue">256</property>
<property name="defaultNode">2</property>
<property name="mapFile">partition-pattern.txt</property>
</function>

partition-pattern.txt

# id partition range start-end ,data node index
###### first host configuration
1-32=0
33-64=1
65-96=2
125
97-128=3
######## second host configuration
129-160=4
161-192=5
193-224=6
225-256=7
0-0=7

配置说明：
上面 columns 标识将要分片的表字段，algorithm 分片函数，patternValue 即求模基数，defaoultNode
默认节点，如果配置了默认，则不会按照求模运算
mapFile 配置文件路径
配置文件中，1-32 即代表 id%256 后分布的范围，如果在 1-32 则在分区 1，其他类推，如果 id 非数据，则
会分配在 defaoultNode 默认节点
String idVal = “0”;
Assert.assertEquals(true, 7 == autoPartition.calculate(idVal));
idVal = “45a”;
Assert.assertEquals(true, 2 == autoPartition.calculate(idVal));
7 截取数字做 hash 求模范围约束
此种规则类似于取模范围约束，此规则支持数据符号字母取模。

<tableRule name="sharding-by-prefixpattern">
<rule>
<columns>user_id</columns>
<algorithm>sharding-by-prefixpattern</algorithm>
</rule>
</tableRule>
<function name="sharding-by-pattern"
class="io.mycat.route.function.PartitionByPrefixPattern">
<property name="patternValue">256</property>
<property name="prefixLength">5</property>
<property name="mapFile">partition-pattern.txt</property>
</function>

partition-pattern.txt

# range start-end ,data node index
# ASCII
# 8-57=0-9 阿拉伯数字
# 64、65-90=@、A-Z
126
# 97-122=a-z
###### first host configuration
1-4=0
5-8=1
9-12=2
13-16=3
###### second host configuration
17-20=4
21-24=5
25-28=6
29-32=7
0-0=7

配置说明：
上面 columns 标识将要分片的表字段，algorithm 分片函数，patternValue 即求模基数，prefixLength
ASCII 截取的位数
mapFile 配置文件路径
配置文件中，1-32 即代表 id%256 后分布的范围，如果在 1-32 则在分区 1，其他类推
此种方式类似方式 6 只不过采取的是将列种获取前 prefixLength 位列所有 ASCII 码的和进行求模
sum%patternValue ,获取的值，在范围内的分片数，
String idVal=“gf89f9a”;
Assert.assertEquals(true, 0==autoPartition.calculate(idVal));
idVal=“8df99a”;
Assert.assertEquals(true, 4==autoPartition.calculate(idVal));
idVal=“8dhdf99a”;
Assert.assertEquals(true, 3==autoPartition.calculate(idVal));

8 应用指定
此规则是在运行阶段有应用自主决定路由到那个分片。

<tableRule name="sharding-by-substring">
<rule>
<columns>user_id</columns>
<algorithm>sharding-by-substring</algorithm>
</rule>
</tableRule>
<function name="sharding-by-substring"
class="io.mycat.route.function.PartitionDirectBySubString">
<property name="startIndex">0</property><!-- zero-based -->
<property name="size">2</property>
<property name="partitionCount">8</property>
<property name="defaultPartition">0</property>
</function>

配置说明：
上面 columns 标识将要分片的表字段，algorithm 分片函数
此方法为直接根据字符子串（必须是数字）计算分区号（由应用传递参数，显式指定分区号）。
例如 id=05-100000002
在此配置中代表根据 id 中从 startIndex=0，开始，截取 siz=2 位数字即 05，05 就是获取的分区，如果没传
默认分配到 defaultPartition
9 截取数字 hash 解析
此规则是截取字符串中的 int 数值 hash 分片。

<tableRule name="sharding-by-stringhash">
<rule>
<columns>user_id</columns>
<algorithm>sharding-by-stringhash</algorithm>
</rule>
</tableRule>
<function name="sharding-by-stringhash"
class="io.mycat.route.function.PartitionByString">
<property name="partitionLength">512</property><!-- zero-based -->
<property name="partitionCount">2</property>
<property name="hashSlice">0:2</property>
</function>

配置说明：
上面 columns 标识将要分片的表字段，algorithm 分片函数
函数中 partitionLength 代表字符串 hash 求模基数，
partitionCount 分区数，
hashSlice hash 预算位，即根据子字符串中 int 值 hash 运算
hashSlice ： 0 means str.length(), -1 means str.length()-1
/**
* “2” -> (0,2) * “1:2” -> (1,2) * “1:” -> (1,0) * “-1:” -> (-1,0)
128
* “:-1” -> (0,-1) * “:” -> (0,0) */
例子：

String idVal=null;
rule.setPartitionLength("512");
rule.setPartitionCount("2");
rule.init();
rule.setHashSlice("0:2");
// idVal = "0";
// Assert.assertEquals(true, 0 == rule.calculate(idVal));
// idVal = "45a";
// Assert.assertEquals(true, 1 == rule.calculate(idVal));
//last 4
rule = new PartitionByString();
rule.setPartitionLength("512");
rule.setPartitionCount("2");
rule.init();
//last 4 characters
rule.setHashSlice("-4:0");
idVal = "aaaabbb0000";
Assert.assertEquals(true, 0 == rule.calculate(idVal));
idVal = "aaaabbb2359";
Assert.assertEquals(true, 0 == rule.calculate(idVal));

10 一致性 hash （重点）

一致性 hash 预算有效解决了分布式数据的扩容问题。

<tableRule name="sharding-by-murmur">
<rule>
<columns>user_id</columns>
<algorithm>murmur</algorithm>
</rule>
</tableRule>
<function name="murmur" class="io.mycat.route.function.PartitionByMurmurHash">
<property name="seed">0</property><!-- 默认是 0-->
<property name="count">2</property><!-- 要分片的数据库节点数量，必须指定，否则没法分片-->
<property name="virtualBucketTimes">160</property><!-- 一个实际的数据库节点被映射为这么多虚拟
节点，默认是 160 倍，也就是虚拟节点数是物理节点数的 160 倍-->
<!--
<property name="weightMapFile">weightMapFile</property>
节点的权重，没有指定权重的节点默认是 1。以 properties 文件的格式填写，以从 0 开始到 count-1 的整数值也就
是节点索引为 key，以节点权重值为值。所有权重值必须是正整数，否则以 1 代替 -->
<!--
<property name="bucketMapPath">/etc/mycat/bucketMapPath</property>
用于测试时观察各物理节点与虚拟节点的分布情况，如果指定了这个属性，会把虚拟节点的 murmur hash 值与物理节
点的映射按行输出到这个文件，没有默认值，如果不指定，就不会输出任何东西 -->
</function>

11 按单月小时拆分
此规则是单月内按照小时拆分，最小粒度是小时，可以一天最多 24 个分片，最少 1 个分片，一个月完后下月
从头开始循环。
每个月月尾，需要手工清理数据。

<tableRule name="sharding-by-hour">
<rule>
<columns>create_time</columns>
<algorithm>sharding-by-hour</algorithm>
</rule>
</tableRule>
<function name="sharding-by-hour" class="io.mycat.route.function.LatestMonthPartion">
<property name="splitOneDay">24</property>
</function>

配置说明：
columns：拆分字段，字符串类型（yyyymmddHH）
splitOneDay ：一天切分的分片数

LatestMonthPartion partion = new LatestMonthPartion();
partion.setSplitOneDay(24);
Integer val = partion.calculate("2015020100");
assertTrue(val == 0);
val = partion.calculate("2015020216");
assertTrue(val == 40);
val = partion.calculate("2015022823");
assertTrue(val == 27 * 24 + 23);
Integer[] span = partion.calculateRange("2015020100", "2015022823");
assertTrue(span.length == 27 * 24 + 23 + 1);
assertTrue(span[0] == 0 && span[span.length - 1] == 27 * 24 + 23);
span = partion.calculateRange("2015020100", "2015020123");
assertTrue(span.length == 24);
assertTrue(span[0] == 0 && span[span.length - 1] == 23);

12 范围求模分片
先进行范围分片计算出分片组，组内再求模
优点可以避免扩容时的数据迁移，又可以一定程度上避免范围分片的热点问题
综合了范围分片和求模分片的优点，分片组内使用求模可以保证组内数据比较均匀，分片组之间是范围分片可以
兼顾范围查询。
最好事先规划好分片的数量，数据扩容时按分片组扩容，则原有分片组的数据不需要迁移。由于分片组内数据比
较均匀，所以分片组内可以避免热点数据问题。

<tableRule name="auto-sharding-rang-mod">
<rule>
<columns>id</columns>
<algorithm>rang-mod</algorithm>
</rule>
</tableRule>
<function name="rang-mod"
class="io.mycat.route.function.PartitionByRangeMod">
<property name="mapFile">partition-range-mod.txt</property>
<property name="defaultNode">21</property>
</function>

配置说明：
上面 columns 标识将要分片的表字段，algorithm 分片函数，
rang-mod 函数中 mapFile 代表配置文件路径
defaultNode 超过范围后的默认节点顺序号，节点从 0 开始。
partition-range-mod.txt
range start-end ,data node group size
以下配置一个范围代表一个分片组，=号后面的数字代表该分片组所拥有的分片的数量。
0-200M=5 //代表有 5 个分片节点
200M1-400M=1
400M1-600M=4
600M1-800M=4
800M1-1000M=6

13 日期范围 hash 分片
思想与范围求模一致，当由于日期在取模会有数据集中问题，所以改成 hash 方法。
先根据日期分组，再根据时间 hash 使得短期内数据分布的更均匀
优点可以避免扩容时的数据迁移，又可以一定程度上避免范围分片的热点问题
要求日期格式尽量精确些，不然达不到局部均匀的目的

<tableRule name="rangeDateHash">
<rule>
<columns>col_date</columns>
<algorithm>range-date-hash</algorithm>
</rule>
</tableRule>
<function name="range-date-hash"
class="io.mycat.route.function.PartitionByRangeDateHash">
<property name="sBeginDate">2014-01-01 00:00:00</property>
<property name="sPartionDay">3</property>
<property name="dateFormat">yyyy-MM-dd HH:mm:ss</property>
<property name="groupPartionSize">6</property>
</function>

sPartionDay 代表多少天分一个分片
groupPartionSize 代表分片组的大小

14 冷热数据分片
根据日期查询日志数据冷热数据分布，最近 n 个月的到实时交易库查询，超过 n 个月的按照 m 天分片。

<tableRule name="sharding-by-date">
<rule>
<columns>create_time</columns>
<algorithm>sharding-by-hotdate</algorithm>
</rule>
</tableRule>
<function name="sharding-by-hotdate" class="io.mycat.route.function.PartitionByHotDate">
<property name="dateFormat">yyyy-MM-dd</property>
<property name="sLastDay">10</property>
<property name="sPartionDay">30</property>
</function>

15 自然月分片
按月份列分区，每个自然月一个分片，格式 between 操作解析的范例。

<tableRule name="sharding-by-month">
<rule>
<columns>create_time</columns>
<algorithm>sharding-by-month</algorithm>
</rule>
</tableRule>
<function name="sharding-by-month" class="io.mycat.route.function.PartitionByMonth">
<property name="dateFormat">yyyy-MM-dd</property>
<property name="sBeginDate">2014-01-01</property>
</function>

配置说明：
columns：分片字段，字符串类型
dateFormat ：日期字符串格式,默认为 yyyy-MM-dd
sBeginDate ：开始日期，无默认值
sEndDate：结束日期，无默认值
节点从 0 开始分片
使用场景：
场景 1：
默认设置；节点数量必须是 12 个，从 1 月~12 月

"2014-01-01" = 节点 0
"2013-01-01" = 节点 0
"2018-05-01" = 节点 4
"2019-12-01" = 节点 11

场景 2：
sBeginDate = "2017-01-01" 该配置表示"2017-01 月"是第 0 个节点，从该时间按月递增，无最大节点
133

"2014-01-01" = 未找到节点
"2017-01-01" = 节点 0
"2017-12-01" = 节点 11
"2018-01-01" = 节点 12
"2018-12-01" = 节点 23

场景 3：
sBeginDate = "2015-01-01"sEndDate = "2015-12-01" 该配置可看成与场景 1 一致；场景 1 的配置效率更高

"2014-01-01" = 节点 0
"2014-02-01" = 节点 1
"2015-02-01" = 节点 1
"2017-01-01" = 节点 0
"2017-12-01" = 节点 11
"2018-12-01" = 节点 11

该配置可看成是与场景 1 一致
场景 4：
sBeginDate = "2015-01-01"sEndDate = "2015-03-01" 该配置标识只有 3 个节点；很难与月份对应上；平均分散到 3 个节点上
自然月分片算法功能测试用例：

PartitionByMonth partition = new PartitionByMonth();
partition.setDateFormat("yyyy-MM-dd");
partition.setsBeginDate("2014-01-01");
partition.init();
Assert.assertEquals(true, 0 == partition.calculate("2014-01-01"));
Assert.assertEquals(true, 0 == partition.calculate("2014-01-10"));
Assert.assertEquals(true, 0 == partition.calculate("2014-01-31"));
Assert.assertEquals(true, 1 == partition.calculate("2014-02-01"));
Assert.assertEquals(true, 1 == partition.calculate("2014-02-28"));
Assert.assertEquals(true, 2 == partition.calculate("2014-03-1"));
Assert.assertEquals(true, 11 == partition.calculate("2014-12-31"));
Assert.assertEquals(true, 12 == partition.calculate("2015-01-31"));
Assert.assertEquals(true, 23 == partition.calculate("2015-12-31"));

16 有状态分片算法
有状态分片算法与之前的分片算法不同,它是为（在线）数据自动迁移而设计的. 数据自动迁移分片算法需要满足一致性哈希的要求，尤其是单调性。
直至 2018 年 7 月 24 日为止,现支持有状态算法的分片策略只有 crc32slot 欢迎大家提供更多有状态分片算法. 一个有状态分片算法在使用过程中暂时存在两个操作
一种是初始化,使用 mycat 创建配置带有有状态分片算法的 table 时(推介)或者第一次配置有状态分片算法的
table 并启动 mycat 时,有状态分片算法会根据表的 dataNode 的数量划分分片范围并生成 ruledata 下的文件, 这个分片范围规则就是’状态’,一个表对应一个状态,对应一个有状态分片算法实例,以及对应一个满足以下命
名规则的文件:
算法名字_schema 名字_table 名字.properties
文件里内容一般具有以下特征
8=91016-102399
7=79639-91015
6=68262-79638
5=56885-68261
4=45508-56884
3=34131-45507
2=22754-34130
1=11377-22753
0=0-11376
行数就是 table 的分片节点数量,每行的’数字-数字’就是分片算法生成的范围,这个范围与具体算法实现有关,一
个分片节点可能存在多个范围,这些范围以逗号,分隔.一般来说,不要手动更改这个文件,应该使用算法生成范围,而
且需要注意的是,物理库上的数据的分片字段的值一定要落在对应范围里. 一种是添加操作,即数据扩容。
添加节点,有状态分片算法根据节点的变化,重新分配范围规则,之后执行数据自动迁移任务.

17 crc32slot 分片算法（重点）
crc32solt 是有状态分片算法的实现之一，是一致性哈希,具体参考第六章数据自动迁移方案设计
crc32(key)%102400=slot
slot 按照范围均匀分布在 dataNode 上,针对每张表进行实例化，通过一个文件记录 slot 和节点
映射关系，迁移过程中通过 zk 协调
其中需要在分片表中增加 slot 字段，用以避免迁移时重新计算，只需要迁移对应 slot 数据即可
分片最大个数为 102400 个，短期内应该够用，每分片一千万，总共可以支持一万亿数据
值得注意的是 crc32 算法对字段计算的结果与字符集有关
crc32 会根据用户指定的分片字段，即图中的 id，算出 slot 的值

<tableRule name="crc32slot">
<rule>
<columns>id</columns>
<algorithm>crc32slot</algorithm>
</rule>
</tableRule>

然后根据 slot 找到对应的节点

public Integer calculate(String columnValue) {
if (ruleName == null)
throw new RuntimeException();
PureJavaCrc32 crc32 = new PureJavaCrc32();
byte[] bytes = columnValue.getBytes(DEFAULT_CHARSET);
crc32.update(bytes, 0, bytes.length);
long x = crc32.getValue();
int slot = (int) (x % DEFAULT_SLOTS_NUM);
this.slot = slot;
return rangeMap2[slot];
}

因为算法中的_slot 字段字段被算法占用,所以使用 crc32slot 的 tableRule 中的 rule 的 columns 分片字段
不能为_slot.。_slot 是为了数据自动迁移过程中不需要重复根据分片字段计算_slot 而在数据库存储层面做的数
据冗余。考虑数据冗余带来的数据存储空间与传输层面的开销与重复计算_slot 的时间开销，冗余 crc32 计算
结果是值得的。如果有特殊原因可以提供一个选项给用户选择是否创建_slot 字段.此为后续 mycat 开发的一个
任务。
配置说明:

<table name="travelrecord" dataNode="dn1,dn2" rule="crc32slot" />

使用 mycat 配置完表后使用 mycat 创建表。
需要注意的是，在 rule.xml 中 crc32slot 的信息请保持如下配置,不需要配置 count

<function name="crc32slot"
class="io.mycat.route.function.PartitionByCRC32PreSlot">
</function>

USE TESTDB;
CREATE TABLE `travelrecord` (
id xxxx
xxxxxxx
) ENGINE=INNODB DEFAULT CHARSET=utf8;

一、了解背景知识（摘自mycat官网）

猜你喜欢