在上一章中，我們主要介紹了規則引擎中最重要的乙個部分，自動擴容，在今天的章節，我們主要還是介紹一下我們在**tddl中的工程實踐吧。
首先從原理開始吧。
規則引擎是什麼呢？
對應在上述例子裡面，其實就是dbnum = pk % 3 這個規則。
他的變化可能很多，比如對於一致性hash則變為乙個if - else 的表示式（見前面）
也可能有其他的變化。
所以，我們要回歸本源，問乙個問題，什麼是規則引擎？
抽象來看，規則引擎在做的事情是，根據一組輸入條件（例如主鍵id,或者使用者id+時間,或者乙個rowkey），進行了一種計算，然後返回在某個機器某個表上執行的結果。這種計算要保證，在規則本身不發生變動的情況下，同一組輸入條件，返回的永遠是相同的結果。
想想這種描述像什麼？:-) 我個人認為很像函式的定義，那麼讓我們換一下表述方式吧:
假設輸入資料為x(主鍵id,使用者id時間，或者rowkey) ，經過運算f,返回了該資料在某台機器上這個結果y.那麼表示式就是
y = f(x)
這是第一層抽象，為了方便表述，我們後面都以這種方式進行表述。
這種規則引擎，在幾乎所有「有狀態」的資料儲存中都會用到，在我們的工程實踐中，我們發現這套引擎需要非常靈活的表現能力，才能適應不同使用者的不同需求，比如有些場景中，業務方會給出一批經過資料分析以後的大賣家，他們固定的就擁有大量資料，會對其他人造成影響，這時候規則引擎必須能夠對各種不同的場景進行適應。
因為規則能夠決定資料的分布是否均勻，因此規則是整套系統中最重要的核心元件。
有了規則引擎，我們要追尋的下乙個目標就是，如何能夠在盡量少的影響業務的正常使用的前提下，改變規則，以達到均衡訪問或擴容的目標。
要達到這個規則，第乙個需要做的事情就是要能夠分辨，哪些資料應該被移動，以及從哪個源頭移動到哪個目標去。
要解決這個問題，在當時能夠想到的方法有兩個，乙個是定死的規則，比如一致性hash,一致性hash，因為規則本身的入參是定死的，輸出也是定死的，所以可以知道從**移動到**。但這也會帶來問題，因為有些業務根本不是使用一致性hash來完成的，他們可能有自定義的函式（如：如果賣家id=2000，那麼走特殊的機器） 。
一旦有這樣的自定義函式，那麼就很難通過分析規則來獲取需要遷移的資料是哪些以及應該從**移動到**這些屬性了。
於是，就必須有另外的方法。
我們採取的方案，是完全放開f，採取多版本的方式來獲得「哪些資料應該被移動，以及從哪個源頭移動到哪個目標去」，這兩個資訊。
原理如下:
我們假設有老規則 f0 ,以及新規則f1.
對於相同的輸入x,我們能得到兩個y，也即
y0 = f0(x) 以及y1 = f1(x)
對兩個y進行比較(compare) ，能夠獲取兩種結果: 結果1 ： y0 == y1. 結果2 ： y0 != y1.
思考這兩種結果的含義，不難明白其中的含義：
如果y0 == y1,那麼意味著，對於相同的資料x，在老規則和新規則中，資料都在同乙個庫的同一張表上(y相同)，這條資料在老規則換為新規則的時候是不需要移動的。
而，如果y0 != y1，那麼意味著，這條資料，如果將規則從f0換為f1,則資料需要被移動，移動的方向應該是從y0到y1.
這樣，我們就很輕鬆的使用多版本的方式，獲得了「哪些資料應該被移動，以及從哪個源頭移動到哪個目標去」，這兩個資訊。
最後，在知道了上面的兩個關鍵的資訊後，還需要一套東西來幫使用者把資料盡可能平滑的從乙個源機器中移動到目標機器中。
這就是我們在平衡遷移中進行的思考，如果有想**的歡迎一起參與。
下面，我們進入工程實踐，來看一下我們的規則引擎在做的事情吧。
本文**於"阿里中介軟體團隊播客",原文發表時間"
2012-02-05"
海量儲存系列之六
上次我們講到，單機事務個我們面臨的問題，下面我們來說一些我所知的解決的方法。在我開始做 資料層的時候，被問得最多的無非也就是 如何做事務，如何做join.至今仍然如此，我一般都會簡單而明確的跟對方說 沒有高效的實現方法。雖然沒有高效的實現，但實現還是有的。作為引子，我們先來介紹一下這種實現的方式。我...
海量儲存系列之五
在上一章節，我們一起瀏覽了如何進行單機事務操作。下面我們來看一下分布式場景中我們碰到的問題吧。需要說明的一點是，這裡涉及到的權衡點非常的多。就我短短的工作經驗裡面，也只是能夠簡單的涉獵一部分，因為在事務這個領域，目前大家都在嘗試提出各種各樣的不同的方法，而在taobao，我們目前也沒有完美的解決這個...
海量儲存系列之十二
目前，團隊blog和sina輕部落格的發布進度已經完全相同，後續會全部 時間隔了比較久了，因為最近在過年臨近，所以都在準備這方面的事情。這裡提前祝大家新年快樂。然後還是回到我們的正題兒吧 本章，我們主要來討論資料的管理和擴容中最重要的乙個部分，資料遷移。資料遷移是資料運維中最為重要的乙個部分，在前面...