學習RadonDB源碼（六）

1. 停下來

這不意味着我不再學習研究RadonDB了，相反，我是很喜歡這樣一個基於MySQL的分佈式數據庫的。

我的意思是寫了那麼多源碼分析難免會讓自己陷入一個又一個的坑裏，最後變成了“不識廬山真面目，只緣身在此山中”，一葉障目，畢竟難見泰山。

這裏的圖我都是盜來的，來自吳炳錫老師的主頁。

從整體結構上來看，我最近分析的部分囿於最上面的Distributed SQL Nodes，其實就是模仿的mysqld。

其實想做分佈式數據庫，一定要實現Raft協議，這已經是一個共識了。那麼如何去實現Raft呢？其實無非是數據多副本，每個副本分散在一個節點上，當分片集羣中有一個節點掛掉，Raft會自動進行選主操作，保證了服務的可用性，同時也保證了數據不丟失。

咱們分開來說，假定現在只有三臺MySQL去Raft集羣，應該如何？其實我們這個時候可以參考MongoDB的副本集結構。一份數據，三個節點同時持有，就有了三個副本——當然MongoDB有一個不持有數據的仲裁節點——這三個節點組成了一個Raft Group。

現在搞得複雜一點，參考一下MongoDB的Sharding Cluster，此時集羣裏有了大於等於兩個副本集，也就是說數據可以開始分片了。那麼這個時候每個副本集持有的數據就是原來數據/n了。其實此時的Raft還是每個副本集自己玩自己的，只是持有的數據量降低了。

RadonDB是怎麼做的，當我新建一張表，並指定分片算法是hash的時候，RadonDB會把我的表分成4096個slots，然後分片去均分這4096個slots。

看看代碼：

// HashRange tuple.
// [Start, End)
type HashRange struct {
    Start int
    End   int
}

根據這段代碼是可以知道slot的切分規則的，就是按照片鍵增序分開的，左閉右開區間。

4096在代碼中的config.go中有寫明，是一個default值，但是圖中的子表配置成32我還沒發現在哪裏。

看到這裏我們就可以知道了下面幾點：

這個時候也不難理解insert_plan中的range是爲什麼了：

        tuple := xcontext.QueryTuple{
            Query:   buf.String(),
            Backend: v.backend,
            Range:   v.rangi,
        }

我寫的這一系列我相信很不完美，也應該有不少錯誤，不過我想我每隔一段時間停下來回頭看看，站在另外的角度上看看，應該會受益良多。

其實我還是想說那句話，學而不思則罔。