數據庫路由中間件MyCat - 使用篇（2）

此文已由做者張鎬薪受權網易雲社區發佈。

歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗。

基本概念

3. 分片

3.1 分片節點（dataNode）

表被水平切分後，每一個分片表所在的數據庫就是一個分片節點。一個分片節點對應一個數據庫（mysql數據庫）。一個分片節點只能保存每一個分片表的一個分片，由於db中不容許出現同名的表。 例如：

<dataNode name="test1" dataHost="test" database="db1" />

這就表示，名字爲test1這個分片節點，對應test節點主機（MySQL實例）主機上的db1數據庫

3.2 節點主機（dataHost）

分片節點究竟被放在那個主機上。對應mysql裏的mysql實例：一臺主機能夠部署多個mysql實例，一個mysql實例能夠有多個數據庫。爲了規避單節點主機併發數限制，儘可能將讀寫壓力高的分片節點（dataNode）均衡的放在不一樣的節點主機（dataHost）. 例如：

<dataHost name="test" maxCon="1000" minCon="10" balance="0"
              writeType="0" dbType="mysql" dbDriver="native" switchType="-1"  slaveThreshold="100">
        <heartbeat>select 1 from dual</heartbeat>
        <writeHost host="master" url="10.202.4.181:3306" user="root"
                   password="sf123456">
            <readHost host="slave" url="10.202.4.181:3307"  user="root" password="sf123456"/>
        </writeHost></dataHost>

這個會在以後的配置文件說明中細講。

分片規則

就決定分片表的記錄如何分佈在不一樣的分片節點上。分片規則有不少種，咱們根據業務須要，並考慮到開發，維護以及擴容的難度，來決定用哪一種分片方案。 分片規則通常還涉及到全局id生成，這個以後會講。 MyCat支持咱們本身開發本身的分片規則，如何開發，咱們後面會講到（如下規則最好不要照搬，參考以後並按照本身的須要開發本身的分片方案）：

1. 哈希取模：

這是最多見的一種分片方案，根據分片字段（通常是主鍵，由於按主鍵查找的場景偏多）的哈希值，對分片個數取模運算，根據結果決定記錄到哪一個分片上。 通常分片個數最好爲2的n次方，這樣計算起來能夠用取與運算（x%(2^n)=x&(2^n - 1)）. 好處：記錄平均分佈（除非id生成器故意生成取模正好只爲同一個數的id），壓力平均分佈，數據沒有傾斜 壞處：擴容（增長分片）是個大問題，分片個數改變，基本很難遷移數據 配置舉例： rule.xml:

<tableRule name="mod-long-rule1">
    <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>

能夠看出，用java反射機制加載org.opencloudb.route.function.PartitionByMod這個類，在這個org.opencloudb.route.function的全部類都爲分片算法，如何實現，將會在以後的rule.xml配置說明中提到。這個算法接收一個參數，其實就是分片個數。以後在tableRule標籤中,規定是哪一列（字段）爲分片字段，對應哪一算法。 在這裏，就是用user_id對3取模以後的值做爲該記錄分佈在哪個分片節點上。

2. 路由約定：

rule.xml:

<tableRule name="file-map-rule1">
    <rule>
        <columns>address</columns>
        <algorithm>file-map</algorithm>
    </rule></tableRule><function name="file-map" class="org.opencloudb.route.function.PartitionByFileMap">
    <property name="mapFile">partition-file-map.txt</property>
    <property name="type">1</property>
    <property name="defaultNode">0</property></function>

type爲零則字段類型爲整型，爲1則爲字符串類型。維護一個對應表配置文件partition-file-map.txt，以下所示： partition-file-map.txt：

北京=0 上海=1 深圳=2 廣州=2 default=3

意思就是分片字段爲北京的到分片0上，上海的到分片1上，深圳和廣州的到分片2上，其餘的到分片3上。 若是某天發現北京的分片須要擴容，能夠將北京的數據總體遷移到一個更大的分片上，以後重載配置。MyCat支持在線重載配置 好處：擴容比較靈活 壞處：數據容易有傾斜，擴容不是很靈活，並且，分片字段很難是經常使用查詢字段（若是查詢字段不是分片字段，就是全分片檢索）

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>
    <property name="defaultNode">0</property></function>

autopartition-long.txt

0~1000k=01000k~2000k=1default=2

就是指分片字段在0~1000k範圍內的到分片0上。。。。。。 好處：保證每一個分片數據穩定，擴容也比較方便 壞處：須要配合id生成器，不然按順序自增會有壓力集中在一個分片的問題。同時，擴容時同時要改變MyCat配置以及id生成器配置。及時作數據清理，id最好能複用，這個規則才能很好的應用。

4.哈希範圍約定：

將哈希取模與範圍路由結合。

<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">64</property>
    <property name="defaultNode">2</property>
    <property name="mapFile">partition-pattern.txt</property></function>

0~15=0
16~31=1
32~47=2
48~63=3

哈希取模後範圍在0~15的流向分片1.。。。 這樣能夠某種程度上減輕擴容的壓力。

5.部分字段：

有時候，咱們並不想一個字段的全部內容都做爲分片咱們能夠取某個字段的一部分做爲分片依據。配合id生成器使用。

6.綜合約定（原創，非內置）：

其實，咱們能夠結合id生成器，作一種既好擴容，又維護不復雜，又能平均分攤壓力的方法。 參考百X的某些項目，他們是項目開始就建64個庫，每一個庫64張表。假設每張表1000w數據，那麼一共能承受409.6億的數據。。。從如今來看估計這個項目作到死也許都用不完。 不過這給咱們一個思路，咱們根據項目須要估計將來n年的量，在項目一開始就分配這麼多庫。這些庫可能在項目初期位於同一個實例上。在不夠用時，咱們把其中某幾個庫遷移到其餘實例上。 咱們可讓id生成器去作平均分佈的事情。 好比下面這個id： 01-01-XXXASD1239091234 咱們用第一個-以前的數字直接做爲分片id，咱們爲了考慮到之後的業務增加，一開始就分配了64個庫。id生成器先開始只會隨機平均生成00~03開頭的，以後業務增加到某個程度時，再按照需求多少在某個範圍生成。

7.多重規則-可擴容哈希路由（原創，非內置）

是從分片字段中抽取一段作分片路由，再取另外一段作自動哈希分片。同時再規定某個範圍內是某個分片規則，另外一範圍是另外一個分片規則。 id示例： 北京-A0000001 配置文件：

北京（A0000000~A9999999）=0，1，2,3,4
北京（B0000000）=5,6,7,8,9
上海（00000000~10000000）=10,11
上海=10,11，12,13,14,15

意思就是，開頭爲北京的範圍在A0000000~A9999999的根據後面的哈希值對5取模平均分佈在0，1，2,3,4分片節點上。開頭爲北京的範圍在B0000000以上的根據後面的哈希值對5取模平均分佈在5,6,7,8,9分片節點上。開頭爲上海的範圍在00000000~10000000的根據後面的哈希值對2取模平均分佈在10,11分片節點上，剩下的開頭爲上海的，對6取模平均分佈在10,11，12,13,14,15上。 這樣，在發現某個開頭的分片不夠用時，能夠隨時改變分片規則，同時不影響之前數據的訪問。

免費體驗雲安全(易盾)內容安全、驗證碼等服務

更多網易技術、產品、運營經驗分享請點擊。

相關文章：
【推薦】 Spring Boot + Mybatis 多數據源配置實現讀寫分離
【推薦】 一個小需求引起的思考