1. 枚舉法：
通過在配置文件中配置可能的枚舉id，自己配置分片，使用規則：
<tableRule name="sharding-by-intfile">
<rule>
<columns>user_id</columns>
<algorithm>hash-int</algorithm>
</rule>
</tableRule>
<function name="hash-int" class="org.opencloudb.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算法
<tableRule name="rule1">
<rule>
<columns>user_id</columns>
<algorithm>func1</algorithm>
</rule>
</tableRule>
<function name="func1" class="org.opencloudb.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------------------------>|
// |<----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="org.opencloudb.route.function.PartitionByLong">
<property name="partitionCount">4</property>
<property name="partitionLength">256</property>
</function>
3.范圍約定
<tableRule name="auto-sharding-long">
<rule>
<columns>user_id</columns>
<algorithm>rang-long</algorithm>
</rule>
</tableRule>
<function name="rang-long" class="org.opencloudb.route.function.AutoPartitionByLong">
<property name="mapFile">autopartition-long.txt</property>
</function>
# range start-end ,data node index
# K=1000,M=10000.
0-500M=0
500M-1000M=1
1000M-1500M=2
或
0-10000000=0
10000001-20000000=1
配置說明：
上面columns 標識將要分片的表字段，algorithm 分片函數，
rang-long 函數中mapFile代表配置文件路徑
所有的節點配置都是從0開始，及0代表節點1，此配置非常簡單，即預先制定可能的id范圍到某個分片
4.求模法
<tableRule name="mod-long">
<rule>
<columns>user_id</columns>
<algorithm>mod-long</algorithm>
</rule>
</tableRule>
<function name="mod-long" class="org.opencloudb.route.function.PartitionByMod">
<!-- how many data nodes -->
<property name="count">3</property>
</function>
配置說明：
上面columns 標識將要分片的表字段，algorithm 分片函數，
此種配置非常明確即根據id進行十進制求模預算，相比方式1，此種在批量插入時需要切換數據源，id不連續
5.日期列分區法
<tableRule name="sharding-by-date">
<rule>
<columns>create_time</columns>
<algorithm>sharding-by-date</algorithm>
</rule>
</tableRule>
<function name="sharding-by-date" class="org.opencloudb.route.function.PartitionByDate">
<property name="dateFormat">yyyy-MM-dd</property>
<property name="sBeginDate">2014-01-01</property>
<property name="sPartionDay">10</property>
</function>
配置說明：
上面columns 標識將要分片的表字段，algorithm 分片函數，
配置中配置了開始日期，分區天數，即默認從開始日期算起，分隔10天一個分區
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="org.opencloudb.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
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. ASCII碼求模通配
<tableRule name="sharding-by-prefixpattern">
<rule>
<columns>user_id</columns>
<algorithm>sharding-by-prefixpattern</algorithm>
</rule>
</tableRule>
<function name="sharding-by-pattern" class="org.opencloudb.route.function.PartitionByPattern">
<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
# 48-57=0-9
# 64、65-90=@、A-Z
# 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 ,獲取的值，在通配范圍內的
即 分片數，
/**
* ASCII編碼：
* 48-57=0-9阿拉伯數字
* 64、65-90=@、A-Z
* 97-122=a-z
*
*/
如
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="org.opencloudb.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解析
<tableRule name="sharding-by-stringhash">
<rule>
<columns>user_id</columns>
<algorithm>sharding-by-stringhash</algorithm>
</rule>
</tableRule>
<function name="sharding-by-substring" class="org.opencloudb.route.function.PartitionDirectBySubString">
<property name=length>512</property> <!-- zero-based -->
<property name="count">2</property>
<property name="hashSlice">0:2</property>
</function>
配置說明：
上面columns 標識將要分片的表字段，algorithm 分片函數
函數中length代表字符串hash求模基數，count分區數，hashSlice hash預算位
即根據子字符串 hash運算
hashSlice ： 0 means str.length(), -1 means str.length()-1
/**
* "2" -> (0,2)<br/>
* "1:2" -> (1,2)<br/>
* "1:" -> (1,0)<br/>
* "-1:" -> (-1,0)<br/>
* ":-1" -> (0,-1)<br/>
* ":" -> (0,0)<br/>
*/
例子：
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
<tableRule name="sharding-by-murmur">
<rule>
<columns>user_id</columns>
<algorithm>murmur</algorithm>
</rule>
</tableRule>
<function name="murmur" class="org.opencloudb.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>
一致性hash預算有效解決了分布式數據的擴容問題，前1-9中id規則都多少存在數據擴容難題，而10規則解決了數據擴容難點
關於一致性hash詳細：
一致性哈希算法在1997年由麻省理工學院提出的一種分布式哈希（DHT）實現算法，設計目標是為了解決因特網中的熱點(Hot spot)問題，初衷和CARP十分類似。一致性哈希修正了CARP使用的簡 單哈希算法帶來的問題，使得分布式哈希（DHT）可以在P2P環境中真正得到應用。
一致性hash算法提出了在動態變化的Cache環境中，判定哈希算法好壞的四個定義：
1、平衡性(Balance)：平衡性是指哈希的結果能夠盡可能分布到所有的緩沖中去，這樣可以使得所有的緩沖空間都得到利用。很多哈希算法都能夠滿足這一條件。
2、單調性(Monotonicity)：單調性是指如果已經有一些內容通過哈希分派到了相應的緩沖中，又有新的緩沖加入到系統中。哈希的結果應能夠保證原有已分配的內容可以被映射到原有的或者新的緩沖中去，而不會被映射到舊的緩沖集合中的其他緩沖區。
3、分散性(Spread)：在分布式環境中，終端有可能看不到所有的緩沖，而是只能看到其中的一部分。當終端希望通過哈希過程將內容映射到緩沖上時，由於不同終端所見的緩沖范圍有可能不同，從而導致哈希的結果不一致，最終的結果是相同的內容被不同的終端映射到不同的緩沖區中。這種情況顯然是應該避免的，因為它導致相同內容被存儲到不同緩沖中去，降低了系統存儲的效率。分散性的定義就是上述情況發生的嚴重程度。好的哈希算法應能夠盡量避免不一致的情況發生，也就是盡量降低分散性。
4、負載(Load)：負載問題實際上是從另一個角度看待分散性問題。既然不同的終端可能將相同的內容映射到不同的緩沖區中，那么對於一個特定的緩沖區而言，也可能被不同的用戶映射為不同 的內容。與分散性一樣，這種情況也是應當避免的，因此好的哈希算法應能夠盡量降低緩沖的負荷。
在分布式集群中，對機器的添加刪除，或者機器故障后自動脫離集群這些操作是分布式集群管理最基本的功能。如果采用常用的hash(object)%N算法，那么在有機器添加或者刪除后，很多原有的數據就無法找到了，這樣嚴重的違反了單調性原則。接下來主要講解一下一致性哈希算法是如何設計的：
環形Hash空間
按照常用的hash算法來將對應的key哈希到一個具有2^32次方個桶的空間中，即0~(2^32)-1的數字空間中。現在我們可以將這些數字頭尾相連，想象成一個閉合的環形。如下圖
把數據通過一定的hash算法處理后映射到環上
現在我們將object1、object2、object3、object4四個對象通過特定的Hash函數計算出對應的key值，然后散列到Hash環上。如下圖：
Hash(object1) = key1；
Hash(object2) = key2；
Hash(object3) = key3；
Hash(object4) = key4；
將機器通過hash算法映射到環上
在采用一致性哈希算法的分布式集群中將新的機器加入，其原理是通過使用與對象存儲一樣的Hash算法將機器也映射到環中（一般情況下對機器的hash計算是采用機器的IP或者機器唯一的別名作為輸入值），然后以順時針的方向計算，將所有對象存儲到離自己最近的機器中。
假設現在有NODE1，NODE2，NODE3三台機器，通過Hash算法得到對應的KEY值，映射到環中，其示意圖如下：
Hash(NODE1) = KEY1;
Hash(NODE2) = KEY2;
Hash(NODE3) = KEY3;
通過上圖可以看出對象與機器處於同一哈希空間中，這樣按順時針轉動object1存儲到了NODE1中，object3存儲到了NODE2中，object2、object4存儲到了NODE3中。在這樣的部署環境中，hash環是不會變更的，因此，通過算出對象的hash值就能快速的定位到對應的機器中，這樣就能找到對象真正的存儲位置了。
機器的刪除與添加
普通hash求余算法最為不妥的地方就是在有機器的添加或者刪除之后會照成大量的對象存儲位置失效，這樣就大大的不滿足單調性了。下面來分析一下一致性哈希算法是如何處理的。
1. 節點（機器）的刪除
以上面的分布為例，如果NODE2出現故障被刪除了，那么按照順時針遷移的方法，object3將會被遷移到NODE3中，這樣僅僅是object3的映射位置發生了變化，其它的對象沒有任何的改動。如下圖：
2. 節點（機器）的添加
如果往集群中添加一個新的節點NODE4，通過對應的哈希算法得到KEY4，並映射到環中，如下圖：
通過按順時針遷移的規則，那么object2被遷移到了NODE4中，其它對象還保持這原有的存儲位置。通過對節點的添加和刪除的分析，一致性哈希算法在保持了單調性的同時，還是數據的遷移達到了最小，這樣的算法對分布式集群來說是非常合適的，避免了大量數據遷移，減小了服務器的的壓力。
平衡性
根據上面的圖解分析，一致性哈希算法滿足了單調性和負載均衡的特性以及一般hash算法的分散性，但這還並不能當做其被廣泛應用的原由，因為還缺少了平衡性。下面將分析一致性哈希算法是如何滿足平衡性的。hash算法是不保證平衡的，如上面只部署了NODE1和NODE3的情況（NODE2被刪除的圖），object1存儲到了NODE1中，而object2、object3、object4都存儲到了NODE3中，這樣就照成了非常不平衡的狀態。在一致性哈希算法中，為了盡可能的滿足平衡性，其引入了虛擬節點。
——“虛擬節點”（ virtual node ）是實際節點（機器）在 hash 空間的復制品（ replica ），一實際個節點（機器）對應了若干個“虛擬節點”，這個對應個數也成為“復制個數”，“虛擬節點”在 hash 空間中以hash值排列。
以上面只部署了NODE1和NODE3的情況（NODE2被刪除的圖）為例，之前的對象在機器上的分布很不均衡，現在我們以2個副本（復制個數）為例，這樣整個hash環中就存在了4個虛擬節點，最后對象映射的關系圖如下：
根據上圖可知對象的映射關系：object1->NODE1-1，object2->NODE1-2，object3->NODE3-2，object4->NODE3-1。通過虛擬節點的引入，對象的分布就比較均衡了。那么在實際操作中，正真的對象查詢是如何工作的呢？對象從hash到虛擬節點到實際節點的轉換如下圖：
“虛擬節點”的hash計算可以采用對應節點的IP地址加數字后綴的方式。例如假設NODE1的IP地址為192.168.1.100。引入“虛擬節點”前，計算 cache A 的 hash 值：
Hash(“192.168.1.100”);
引入“虛擬節點”后，計算“虛擬節”點NODE1-1和NODE1-2的hash值：
Hash(“192.168.1.100#1”); // NODE1-1
Hash(“192.168.1.100#2”); // NODE1-2
以上所有規則每種都有特定使用場景，可以選擇性使用。