亚洲视频二区_亚洲欧洲日本天天堂在线观看_日韩一区二区在线观看_中文字幕不卡一区

作者： 吳炳錫

作者介紹： 知數堂聯合創始人及MySQL高級講師，3306π社區聯合創始人，騰訊TVP成員。

本文大概5500字，閱讀大概需要15分鐘，建議電腦前閱讀。大綱如下：

• 概述
• 使用Radon attache功能的好處
• 基本環境描述
• 把wordPress/ target=_blank class=infotextkey>WordPress庫加入到Radon中
• 利用wordpress體驗Radon的透明分庫分表
• 總結

可以關注知數堂騰訊課堂上我分享的RadonDB相關視頻。

最近發現RadonDB在特性中引入一個新特性：Single table 到分區表快速轉換，另外還引進了一個優秀的特性，把現有的MySQL庫直接attach到Radon下面。看到這兩個特性真是太贊了?？梢苑浅７奖阌脩魧崿F原來的單表，快速變成拆分表，一條命令搞定。具體的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:

Radon配置如下

1. {
2. "proxy" : {
3. "endpoint" : ":3316" ,
4. "meta-dir" : "bin/radon-meta" ,
5. "peer-address" : ":8080"
6.  
7. "audit" : {
8. "audit-dir" : "bin/radon-audit"
9. },
10. "log" : {
11. "level" : "INFO"
12. },
13. "monitor" : {
14. "monitor-address" : "0.0.0.0:13380"
15. }
16. }

添加MySQL到Radon中，在Radon進程所在的機器上執行：

1. 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

參數說明：

1. {
2. "name" ： 后端節點命名，要求唯一，
3. "address" : 后端 MySQL 連接串，
4. "user" : MySQL 連接用戶名，
5. " password ": 數據庫連接密碼，
6. " max - connections ": 最大支持多少個連接連后后端DB中, 加入Radon后也可以啟到一個連接池的作用。
7. }

整個環境節架構如下：

環境確認：博客鏈接3306端口，確認wordpress工作正常。

把wordpress庫加入到Radon中

1. mysql - h 192.168 . 0.2 - P3316 - uwubx - pwubxwubx
2. mysql > radon attach ( '192.168.0.2:3306' , 'wubx' , 'wubxwubx' );

觀察日志輸出：

1.  
2. ...
3.  
4.  
5.  
6.  

從日志中可以看出來， Radon把原庫直接掛載到Radon下面，把原始3306庫下的wubx庫下表注刪到radon下面，同時把配置寫到：bin/radon-meta/backend.json & bin/radon-meta/wubx/ 這個目錄。同時也在3307兩個原始節點上建出來: wubx庫（日志:frm.write.database[db:wubx]），但沒有表。這里看一下backend.json內容：

1. {
2. "backends" : [
3. {
4. "name" : "backend1" ,
5. "address" : "192.168.0.2:3307" ,
6. "user" : "wubx" ,
7. "password" : "wubxwubx" ,
8. "database" : "" ,
9. "charset" : "utf8" ,
10. "max-connections" : 1024 ,
11. "role" : 0
12.  
13. {
14. "name" : "192.168.0.2:3306" ,
15. "address" : "192.168.0.2:3306" ,
16. "user" : "wubx" ,
17. "password" : "wubxwubx" ,
18. "database" : "" ,
19. "charset" : "utf8" ,
20. "max-connections" : 1024 ,
21. "role" : 1
22. }
23. ]
24. }

從上面配置上可以看到：192.168.0.2:3306也直接掛載了Radon下面。從上面的配置中，可以看到: 192.168.0.2:3306 在Radon中成為一個IP:PORT的后端存儲節點,另外Role:1 表示是一個attach上來的節點。

通過radon-meta對應庫下的表分布對應關系查看：

1. cat bin / radon - meta / wubx / wp_users . json
2. {
3. "name" : "wp_users" ,
4. "slots-readonly" : 0 ,
5. "blocks-readonly" : 0 ,
6. "shardtype" : "SINGLE" ,
7. "shardkey" : "" ,
8. "partitions" : [
9. {
10. "table" : "wp_users" ,
11. "segment" : "" ,
12. "backend" : "192.168.0.2:3306" ,
13. "listvalue" : ""
14. }
15. ]
16. }

這里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表到拆分表的轉換：

1. MySQL > RADON RESHARD wp_posts to new_wp_posts ;
2. MySQL > alter table wp_posts rename wp_post_bak ;
3. MySQL > alter table new_wp_posts rename to wp_posts ;

首先利用Radon reshard 把原來一個非拆分表，變成一個新的拆分表， 這里有一個不錯的設計， 該操作完，也不會把wp_posts表刪除，這是一個不錯的設計。后面利用改表名后，再來看看業務運行情況?，F在的架構如下 ：

做完以上動作Wordpress白頁了，內容頁顯示不出來，從Radon的報錯日志(radon.log)中發現Radon還沒支持 SQLCALCFOUNDROWS 這個函數。所以可以通過，查詢源碼中：

主要處理和wpdb->posts這個查詢有關found_rows就可以，處理辦法：

1. if ( ! $q [ 'no_found_rows' ] && ! empty ( $limits ) )
2. $found_rows = 'SQL_CALC_FOUND_ROWS' ;
3. $found_rows = '' ;

再來確認：Blog又可以工作了。因為wordpress的分頁用到了SQLCALCFOUNDROWS這個功能，所以唯一不爽的地方，沒分頁了。

再來看一下wpposts表在后端節點的分布情況：

cat bin/radon-meta/wubx/wp_posts.json

1. {
2. "name" : "wp_posts" ,
3. "slots-readonly" : 4096 ,
4. "blocks-readonly" : 64 ,
5. "shardtype" : "HASH" ,
6. "shardkey" : "ID" ,
7. "partitions" : [
8. {
9. "table" : "wp_posts_0000" ,
10. "segment" : "0-64" ,
11. "backend" : "backend1" ,
12. "listvalue" : ""
13.  
14. ...
15. {
16. "table" : "wp_posts_0031" ,
17. "segment" : "1984-2048" ,
18. "backend" : "backend1" ,
19. "listvalue" : ""
20. },
21. {
22. "table" : "wp_posts_0032" ,
23. "segment" : "2048-2112" ,
24. "backend" : "backend1" ,
25. "listvalue" : ""
26. },
27. ...
28. {
29. "table" : "wp_posts_0063" ,
30.  
31. "backend" : "backend1" ,
32. "listvalue" : ""
33. }
34. ],
35. "auto-increment" : {
36. "column" : "ID"
37. }
38. }

從以上定義來看 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作用。

特別注意事項點如果把現有的業務數據庫直接加入到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中間件：）。