作者：楊建榮 來源：微信公眾號 楊建榮的學習筆記
前段時間收到吳老師的邀請，是參加青云QingCloud分布式數據庫(RadonDB)的一個技術體驗活動，從今天的技術體驗來算，收獲還是很多的，大家相聊甚歡，交流了很多工作中和工作之外的想法，原來那些我們看起來難走的路大家都曾經走過。
總體來說MySQL方向的目前的技術架構是一種看起來相對穩(wěn)定的體系，一般來說傳統(tǒng)的主從復制，半同步，一主多從，到分庫分表，加上中間件，高可用，好像可玩的花樣就差不多這些了，所以基于這些我們只能說MySQL的這種使用方式是基于分布式架構，從CAP的角度來看，一致性(C)，可用性(A)，分區(qū)容忍性(P)方面很難都占全。
說實話，最開始聽到RadonDB這個名字感覺很陌生，打開技術架構圖，猛一看看好像沒有什么特別的新意，所以開始的環(huán)境部署和簡單體驗其實是帶著一種挑剔的眼光來看的，提出一些體驗和兼容性的小問題。
但是隨著下午和設計師雁飛和RadonDB團隊的深入交流，發(fā)現這個架構確實很有意思，能夠在已有的架構模式下玩出新的花樣，而且確實解決了分布式方案的基本需求，很難得。
我來簡單補充下產品里面的亮點。
1.首先整個一套方案都是打算開源的，目前在青云的產品線中已經可以體驗。從部署到使用，整個過程都是基于云平臺來完成，基礎運維的成本很低。
2.從架構設計的角度來說，RadonDB的設計定位充分利用了MySQL的開源紅利，存儲節(jié)點是直接使用MySQL5.7的版本，可以把存儲計算的任務下沉到MySQL層面，所以他是一套完全基于MySQL定制的分布式方案，架構方式看起來比較輕量級。
3.對于關系型數據庫來說，要實現擴容影響面是很大的。RandonDB在這里的實現，上層是基于hash，存儲模式是基于Range,即一個大表也可以根據片鍵值的范圍橫向擴展，比如一個大表是30G,那么如果是分為30個分片，那么沒一片的粒度就是1G,在這種代價下，做online DDL還是數據的遷移都是相對來說可控的粒度，我個人最欣賞的就是它在彈性擴容上的實現方式，能夠基于這種拆分思想，借鑒參考了Redis Cluster里面類似的思想，根據細粒度的slot級別的數據來實現擴容。
4.在高可用上面值得一提的是一個獨立的工具MySQL Plus,這款工具可以基于5.7版本以上的GTID來滿足原來MHA所做的事情，然后基于半同步保證了數據的完整性，目前的整個一套方案都是基于Raft實現的。
當然還有些其他的細節(jié)方面也做了一些蠻不錯的改進：
1:比如審計日志的功能其實對于很多公司來說還是有審計需求的
2:mydumper的定制，是基于go來實現的，能夠充分利用go的一些優(yōu)勢
3:壓測工具也是基于go做的一層定制，從現場的高可用測試來看，體驗會好一些。
當然在體驗的過程中也發(fā)現了一些待改進的地方，有些是顯示信息的補充和改進，有些則是技術實現方案上的建議等。我簡單提兩點：
首先，RandonDB的角色其實就是一個中間件，類似ProxySQL,MyCAT之類的中間件，能夠實現基本的SQL轉發(fā)，這里考慮到給以后的分布式事務設計帶來技術改進，目前的SQL Node是一個節(jié)點寫入，其他節(jié)點是只讀的。
對于OLAP的業(yè)務支持，其實從RadonDB的SQL轉發(fā)，對于復雜，聚合的需求就可以直接下沉到計算節(jié)點，對于計算節(jié)點，目前的初步設計是使用插件的方式來實現，設計團隊的初步設想是引入MariaDB columnstore類似的方案來實現，我有一個建議是也可以采用類似MPP的方式，畢竟MPP也是分布式方案的而一種，在這種架構模式下就會充分用到存儲多副本的優(yōu)勢，比如多個副本，我們可以利用其中的一個或者兩個的副本來滿足AP的需求，這樣對于主庫的寫入侵入性是最小的，而且能夠發(fā)揮當前架構的特點，類似Greenplum中的segment節(jié)點的角色。
和RadonDB的團隊交流中發(fā)現，他們的團隊規(guī)模其實不大，但是支撐起來這樣一個產品，能夠快速迭代出來，著實讓人佩服。
RadonDB會在5月份開源發(fā)布，其實開源的不只是產品，還是一種開放的態(tài)度，希望RadonDB能夠給我們的運維工作中帶來一些新的思路和改進。
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
