最近發現RadonDB在特性中引入一個新特性：Single table 到分區錶快速轉換，另外還引進了一個優秀的特性，把現有的MySQL庫直接attach到Radon下面。看到這兩個特性真是太讚了。可以非常方便用戶實現原來的單表，快速變成拆分表，一條命令搞定。具體的issue參考：https://github.com/radondb/radon/issues/436 而且這個特性會在1.0.8這個版本發佈。下面我們一塊來體驗一下吧。該文檔可以用於先看看整體思想上有一個認識後再行動。
利用Radon attach獲得的好處
連接池外置。如果你的應用程序沒有連接池，或是MySQL上掛了上千個以上的連接時又不想讓MySQL上因爲掛連接而影響性能，那就可以考慮利用Radon做外置的連接池。例如：在原來老的MySQL上掛一個Radon，所有的表都是Single表模式，現的Radon只是對SQL解析獲取到表名，直接傳遞給後端，後面基本就是TCP中轉操作：從後端獲取結果返回給前端。修改："max-connections": 1024 即可。
利用Radon實現原來的老的項目和日誌數據或是海量數據混跑。利用attach功能掛載原來的MySQL，把大表遷移到Radon中。爲了求穩，你還可以通過老庫訪問原來除了大表外的其它表，對於超級大表可以通過Radon訪問，當然Radon也可以訪問掛載上的MySQL.
可利用到Radon提供的審計， 透明自動拆分功能。
基本環境及架構描述
這裏爲了更清楚整個過程，採用全部自建環境：單機多實例環境 安裝：LAMP環境，可以用運行wordpress確認，在單庫環境下是正常的。wordpress使用數據庫端號：3306端口。爲了看來了來效果，我在增加一個實例：3307 端口的數據庫。 
這裏只是一個功能測試，所以不在給MySQL做高可用，如果需要高可用可以搭建xenon環境。Radon安裝，可以看到前面章節,啓動一個空的radon:
./bin/radon -c ./radon.json >radon.log 2>&1 &
Radon配置如下
{ "proxy": { "endpoint": ":3316", "meta-dir": "bin/radon-meta", "peer-address": ":8080"
}, "audit": { "audit-dir": "bin/radon-audit"
}, "log": { "level": "INFO"
}, "monitor": { "monitor-address": "0.0.0.0:13380"
}
}添加MySQL到Radon中，在Radon進程所在的機器上執行：
curl -i -H 'Content-Type: application/json' -X POST -d '{"name": "backend1", "address": "192.168.0.2:3307", "user":"wubx", "password": "wubxwubx", "max-connections":1024}' http://127.0.0.1:8080/v1/radon/backend參數說明：
{
"name"： 後端節點命名，要求唯一，
"address" : 後端MySQL連接串，
"user": MySQL連接用戶名，
"password": 數據庫連接密碼，
"max-connections": 最大支持多少個連接連後後端DB中, 加入Radon後也可以啓到一個連接池的作用。
}整個環境節架構如下： 
環境確認：博客鏈接3306端口，確認wordpress工作正常。
把wordpress庫加入到Radon中
mysql -h 192.168.0.2 -P3316 -uwubx -pwubxwubx
mysql>radon attach('192.168.0.2:3306','wubx','wubxwubx');觀察日誌輸出：
2019/11/29 10:33:13.131527 frm.go:107: [INFO] frm.write.database[db:wubx]...2019/11/29 10:33:14.151430 frm.go:43: [INFO] frm.write.data[db:wubx, table:wp_users, shardType:SINGLE]2019/11/29 10:33:14.188426 frm.go:43: [INFO] frm.write.data[db:wubx, table:wp_wp_rp_tags, shardType:SINGLE]2019/11/29 10:33:14.583204 scatter.go:128: [WARNING] scatter.flush.to.file[bin/radon-meta/backend.json].backends.conf:[0xc00012ef50 0xc0001a69a0 0xc00041d1f0]2019/11/29 10:33:14.593135 admin_attach.go:80: [WARNING] attach[{192.168.0.2:3306 192.168.0.2:3306 wubx wubxwubx 1024}]從日誌中可以看出來， Radon把原庫直接掛載到Radon下面，把原始3306庫下的wubx庫下表注刪到radon下面，同時把配置寫到：bin/radon-meta/backend.json & bin/radon-meta/wubx/ 這個目錄。同時也在3307兩個原始節點上建出來: wubx庫（日誌:frm.write.database[db:wubx]），但沒有表。這裏看一下backend.json內容：
{ "backends": [
{ "name": "backend1", "address": "192.168.0.2:3307", "user": "wubx", "password": "wubxwubx", "database": "", "charset": "utf8", "max-connections": 1024, "role": 0
},
{ "name": "192.168.0.2:3306", "address": "192.168.0.2:3306", "user": "wubx", "password": "wubxwubx", "database": "", "charset": "utf8", "max-connections": 1024, "role": 1
}
]
}從上面配置上可以看到：192.168.0.2:3306也直接掛載了Radon下面。從上面的配置中，可以看到: 192.168.0.2:3306 在Radon中成爲一個IP:PORT的後端存儲節點,另外Role:1 表示是一個attach上來的節點。
通過radon-meta對應庫下的表分佈對應關係查看：
cat bin/radon-meta/wubx/wp_users.json
{ "name": "wp_users", "slots-readonly": 0, "blocks-readonly": 0, "shardtype": "SINGLE", "shardkey": "", "partitions": [
{ "table": "wp_users", "segment": "", "backend": "192.168.0.2:3306", "listvalue": ""
}
]
}這裏Single表即是沒進行分庫分表。所有的庫都位於192.168.0.2:3306這個端口下wubx庫下。架構如下： 
現在把wordpress中配wp_config.php的配置從原來的3306連接指3316(radon)端口，可以發現，也可以正常對外提供服務了。Radon中遇到Single表的情況下是把SQL透明下發到後達。所在這裏Radon更相當於一個TCP的代理層，主要可以啓到“連接池”，審計等相關功能。接下來，我們可以看看Radon帶來的福利了，例如：審計， 透明自動拆分， 並行執行， 分佈式事務 等功能了。
利用wordpress體驗Radon的透明分庫分表
我們知道wordpress最大表是wpposts這個內容表，當我們Blog積累的內容足夠多的情況下， 該表也許會成爲一個瓶頸。這裏我們對wpposts表做一次從single表到拆分表的轉換：
MySQL>RADON RESHARD wp_posts to new_wp_posts; MySQL>alter table wp_posts rename wp_post_bak; MySQL>alter table new_wp_posts rename to wp_posts;
首先利用Radon reshard 把原來一個非拆分表，變成一個新的拆分表， 這裏有一個不錯的設計， 該操作完，也不會把wp_posts表刪除，這是一個不錯的設計。後面利用改表名後，再來看看業務運行情況。現在的架構如下 ： 
做完以上動作Wordpress白頁了，內容頁顯示不出來，從Radon的報錯日誌(radon.log)中發現Radon還沒支持 SQLCALCFOUNDROWS 這個函數。所以可以通過，查詢源碼中： 
主要處理和wpdb->posts這個查詢有關found_rows就可以，處理辦法：
if ( !$q['no_found_rows'] && !empty($limits) ) $found_rows = 'SQL_CALC_FOUND_ROWS'; $found_rows = '';
再來確認：Blog又可以工作了。因爲wordpress的分頁用到了SQLCALCFOUNDROWS這個功能，所以唯一不爽的地方，沒分頁了。 
再來看一下wpposts表在後端節點的分佈情況：
cat bin/radon-meta/wubx/wp_posts.json
{ "name": "wp_posts", "slots-readonly": 4096, "blocks-readonly": 64, "shardtype": "HASH", "shardkey": "ID", "partitions": [
{ "table": "wp_posts_0000", "segment": "0-64", "backend": "backend1", "listvalue": ""
},
...
{ "table": "wp_posts_0031", "segment": "1984-2048", "backend": "backend1", "listvalue": ""
},
{ "table": "wp_posts_0032", "segment": "2048-2112", "backend": "backend1", "listvalue": ""
},
...
{ "table": "wp_posts_0063", "segment": "4032-4096", "backend": "backend1", "listvalue": ""
}
], "auto-increment": { "column": "ID"
}
}從以上定義來看 wp_posts以ID用HASH的方式給給拆分成64個物理表，實質上拆分成了4096個slot, 每個物理子表接受一個區間的slot服務， 並完美的遷移到Radon集羣下面節點上，如果有多個Backend，該動作會把拆分後的表均勻的分到其它節點上，在joins查詢各方面完美。限於篇幅問題，這裏不再展開。如果對於拆分表後SQL是怎麼運行的有興趣，可以連接入Radon中，運行: explain 具體的SQL看一下 Radon SQL改寫。
這裏其實可以有一個大膽的嘗試，利用attach功能，把小表跑在attach節點上，大表跑在Radon拆分的節點，然後加多個attach節點，這樣下面整體的可管理性更強。這個方案需要進一步測試和官方確定是不是可以用。單個attach上去的節點也有點Radon中單獨建的Single table作用。鄭州市不孕不育專科醫院：http://www.zzchbb.com/
特別注意事項點如果把現有的業務數據庫直接加入到Radon中，原來的DB不要在做爲Backend加入了。操作上就象上面操作，直接attach上去，就可以使用了，就行。
總結
通過本案例可以看出來，Radon對於現有項目遷移到分佈式環境有着不錯的支持方案，對於SQL豐富度支持，也不錯，對於wordpress的SQL基本可以原生不動的遷移過來，可以說Radon對SQL的支持複雜度也上了一個新臺階。另一方面， 對於MySQL一些內置函數，支持不友好。從Radon代碼上看，Radon對於支持的指令都是嚴格處理，拿一個show table status; 這個指令的處理，一般的中間件，就是直接傳到後端第一個節點上，獲取數據返回就ok了，但Radon的處理是把這個請求會發到後端所有的節點，然後把結果進行合併後，返回，這點上感覺Radon做事上是力求正確。不是單純的兼容。所以最後，看到Radon在github開源項目上新的feature也都比較讓人激動，聽說這些功能也是一些互聯網公司在免費使用Radon後給官方提需求，青雲的小夥伴認真的把這些需求也加到了issue中，排期進行。據瞭解，他們也非常歡迎大家提的需求。個人的另一個感受，Radon代碼風格很爽，可以研究一下Radon的代碼，學習一下利用golang開發MySQL中間件：）。鄭州市不孕不育醫院：http://www.03913882333.com/