《一個迅速發(fā)展創(chuàng)業(yè)公司的 RDS 重塑之路》要點：
本文介紹了一個迅速發(fā)展創(chuàng)業(yè)公司的 RDS 重塑之路，希望對您有用。如果有疑問，可以聯(lián)系我們。

RDS 是關(guān)系型數(shù)據(jù)庫服務(wù).有贊為什么重新打造 RDS 東西?這要從四個角度去分析：背景、問題、發(fā)展、實現(xiàn).

有贊四個發(fā)展階段的問題

首先,背景來說的話有贊是一家創(chuàng)業(yè)公司,它從 0 到 50 人團隊的時候,業(yè)務(wù)相對而言還是比較單一的.這個時候的業(yè)務(wù)發(fā)展沒有那么快.而到了 50-200 人階段的時候,業(yè)務(wù)線非常的多,比如說微小店、微商城,再比如說分銷的業(yè)務(wù),這些業(yè)務(wù)線起來之后,流量是慢慢的緩增到 200-300 人階段的時候,大量工程師在快速的涌入公司,并且設(shè)計量這個時候也在增長.到 300 人的時候不僅僅是流量的緩增,而且這個時候流量也滿滿地增長,這個是比較重要的.

這樣四個階段的背景下面產(chǎn)生什么樣的問題呢?

在 0-50 人的時候,人員相對比較能 Hold 住 MySQL.

50-200 人階段對數(shù)據(jù)庫壓力是比較大的,所以產(chǎn)生了讀寫分離的需求,因為單機 MySQL 壓力是蠻高的.

而到 200-300 人不僅僅是流量的增加,而且是數(shù)據(jù)量的增加.對單一的垂直業(yè)務(wù)線而言本身數(shù)據(jù)量在 MySQL 是 Hold 不住的.

等到 300 人 + 的時候全部業(yè)務(wù)線全面開花,包括業(yè)務(wù)人員,開發(fā)人員很多 DDL 產(chǎn)生,流程會變得很重,這都是很典型的創(chuàng)業(yè)公司的問題.

技術(shù)棧的發(fā)展

針對這些問題我們跟互聯(lián)網(wǎng)公司差不多是一樣的,首先它的發(fā)展而言對 MySQL 而言是單接使用率,然后到很典型使用應(yīng)用程序,主動的去讀或者是寫 Master.

到第三階段讀寫分離,這里有一個背景是說我們的業(yè)務(wù)是基于 PSP 原始線.所以當流量上來的時候,在 MySQL 中間一層加像 360 的一個開源組件 Altas.后面一個階段,引入阿里巴巴的一個開源的帶 Sharding 功能的方案 Cobar.

介紹一下這兩個組件的區(qū)別和方案的對比.

360 開源組件 Altas 滿足了讀寫分離的需求,但是在電商領(lǐng)域或者更嚴格要求 ACID 的金融領(lǐng)域來說的話事務(wù)性要求很高的,這點是短板；不過它做了更好的運維上面的上線、下線 MySQL 的控制.而阿里巴巴的開源組件 Cobar 是簡單的對 MySQL 做一些 Sharding.這兩個架構(gòu)本身而言對有贊來說的話是經(jīng)歷了比較長的一個時間,直到我后來加入之后,我把這些問題梳理了一下,這些問題主要會產(chǎn)生線上的故障非常多,即便是引入了 360 或者阿里巴巴的架構(gòu)實現(xiàn)來說的話還是有很多的問題.所以我們進行了改造,變成了 RDS-Proxy.

重塑,剖析 RDS-Proxy

本身 RDS 不是一開始就有的.這個是 Proxy 的一個雛形,為了去掉 RDS 和 kober,我們在 kober 上進行了改造,所以 Proxy 是一個中間基層,所以上下協(xié)議都是通過 MySQL 協(xié)議來訪問的.

在 Proxy 上我們增加了很多的功能,比如讀寫分離,還增加了 MySQL 的權(quán)重,原先是沒有的.而 ConnPool 也做了大量改造,主要是增強了它的連接數(shù)的復(fù)用性.原來 Kober 和那個的連接池用的是 IP+Pool 再加 MySQL 數(shù)據(jù)庫的 Sgam.而我們改造后是共同承載非常多的 Sharding.這個 BIO 和 NIO 是比較大的改造,本身這個是非常重要的一點,無論是哪個方案,對于 MySQL 而言,它的 IO 是同步的協(xié)議在 IO 上很消耗性能.所以我們加前端的連接和后端的連接改成 NIO.這樣的話就可以釋放出 Proxy 上大量的內(nèi)存.這個改造后我們就大量的提升了線上的性能,包括 Plos 的性能.

除了性能的改造之外我們還做了一些類似 FastFailed 的機制,對于 RDS-Proxy 改造后我們形成了這樣的功能,就是前面所說的幾點,ShardingFuction 增強,很重要的一點是 BIO 改造成了 NIO,無論是前置的連接和后置的連接都進行了改造,而 FastFailed 是增加了壟斷的機制.通過這些改造后大家會不會有疑問,說增加了這么多功能它的性能會下降,其實不然.實際上我們通過改造代碼量增加了,但是性能是提高了非常多的.首先我們在這樣的測試場景下面,我們的背景使在 E5-2630 24CPU 上,千兆網(wǎng)卡打滿了,Proxy 本身會氣動 8×24 線程.而實際測的數(shù)據(jù)如屏幕上顯示的,較以前的性能來說有 30% 的提高,140K QPS.

做了這么多性能對于穩(wěn)定性有什么樣的效果呢?我們由原來一個季度里會有 1-3 次的故障,而且是全站故障,改造后變成了 0 個.我們現(xiàn)在目前改造之后是沒有全站故障的,因為 MySQL 的訪問,Proxy 的訪問所導(dǎo)致的.

說了這么多,我們做了哪些功能?我舉個簡單的例子講一下如何實現(xiàn)的,下面可能會比較燒腦,因為有一些代碼,不太適合在開場或者熱身的階段,所以舉個比較簡單的事情.讀寫分離,原來是沒有讀寫分析的,所以對靜態(tài)類,這塊是新加的功能,我先講一下總體的功能.MySQL Data Note 里會使用到 Channl,每個 Channl 是去執(zhí)行 SQL 語句的.本身 MySQL 會使用到 Sleef,每個請求用一個連接,或者多個請求復(fù)用一個連接.原來沒有 Sleef 要求,我進行了改造,并且進行了檢測是否可用.對于前置的連接來說的話進行判斷是否進行讀寫分離.而對于讀寫分離我們是不愿意讓業(yè)務(wù)上層去做太多改造所以用了 MySQL Fent,然后再做路由,去拿到后端的路由之后,然后決定是選擇 Master 還是最底下的哪個 Sleef.最終這樣的改造之后夠可以滿足到讀寫分離功能.

即便是做了這么多性能跟穩(wěn)定性改造之后,其實還是有很多的問題.尤其是在 300 人的團隊以上,這個時候團隊里的技能是參差不齊的,尤其是有多的業(yè)務(wù)線,有很多的研發(fā),有很多的流量,而這些引發(fā)出每一天做 DDL 的變更會很多.而在 DDL 的變更,像在一個集群數(shù)量大的時候,每個分片都要做對接,引發(fā)的故障也會多一些.并且研發(fā)人員多跟 DBA 交流和交互時間效率也會變得很低.并且業(yè)務(wù)開發(fā)人員他的 SQL 技能是跟不上,比如說覆蓋索引,組合索引,MySQL 緊密索引,都沒有什么概念,在技能沒有跟上的情況下面,對于生產(chǎn)系統(tǒng)是一個非常大的挑戰(zhàn).并且 MySQL 本身也會有 Feel,Master 要掛掉,在這個時候會頻繁發(fā)生 MySQL HA.而對 MySQLHA 是災(zāi)難性事情,數(shù)據(jù)是很難保持一致.所以在退化數(shù)據(jù)的時候,在退化的過程中數(shù)據(jù)的一致性是非常難以保證.所以在這樣的問題下面,我們單純的 RDS 功能增加有如下的,對 Proxy 的改造,增加了 DDL 支持工作流,讓每個研發(fā)人員能夠在同一個平臺提交 DDL,并且?guī)椭?DBA 節(jié)省他熬夜的工作時間,能夠提升他自己的工作效率,這個是比較重要的.第三,對 MySQLHA 的一些改造.

 

講 RDS 結(jié)構(gòu)之前先一下 RDS 模塊.它的模塊如圖.

Console 是作為總管理端和操作入口.Proxy 是從一開始就有,這是用戶訪問的代理層.而 HA Master 是作為 HA 檢測和切換操作.Canal Manager 是作為數(shù)據(jù)驅(qū)動的事件通知系統(tǒng),Tablet 是部署我在每個 MySQL 主機上面的代理,是一個 Local Agent,Tablet 現(xiàn)在能夠承載于啟動 MySQL 指令,能夠?qū)?MySQL 進行白名單的過濾,而 MySQL 本身是我們互聯(lián)網(wǎng)重度依賴的一個開源的軟件數(shù)據(jù)庫的.在每個單機上會部署多個數(shù)據(jù)組.M 就是 Master1 的使令,Tablet 是跟 RDS 交互,當然 MySQL HA 要做的時候,檢測中 MySQL Master 掛了,要啟動其中的一個 F1 或者 0,是通過 Master 檢測和控制的.本身 HA-Master 跟 Console 可以放同一個進程里,但是迭代是比較快,所以為了穩(wěn)定性拆開,后續(xù)會考慮合并.然后把 MySQL 上面的 Realy 盡量搜集到且回放給 log.通過這樣鏈路的調(diào)整之后,我們現(xiàn)在夠去掉了原先 VIP 那個 RDS 的方案.右下角這端相對而言是互聯(lián)網(wǎng)里比較常用的事件驅(qū)動源的架構(gòu)對孵化的進程中,這個可以忽略.

效果展示

這個是當時梳理的系統(tǒng)架構(gòu),系統(tǒng)里的概念,主要針對運維的需求和線上開發(fā)人員,還有 DBA 的一些需求和 MySQL 自己本身的一些概念所做的一些梳理.所以對 RDS 做了這些 Proxy 改造和 DDL 的工作流之后,我們對 RDS 有一個相對比較大的提升.整個控制臺可以看到所有的都在這個控制臺,可以看到單純的流量是多少等等.這里截了兩張圖,沒有太多的演示,因為這個產(chǎn)品界面本身也在不斷的改,主要是這兩個功能是比較重要的.

寫在最后

最重要的一點,我覺得在 300-1000 人或者在未來更多人的團隊里,工作流是非常重要的,而且在使用 MySQL 過程中,它的本身就很復(fù)雜,無論它的合理實現(xiàn)或者不合理實現(xiàn)都會引發(fā)概念上或者實現(xiàn)上的一些區(qū)別,所以我們對 DDL 進行工作流的支持,這樣的話就可以提高整個業(yè)務(wù)線上面開發(fā)效率,能夠縮短業(yè)務(wù)上線時間.我認為這個是比較重要的工作效率的提高.雖然說很多的所謂想做高并發(fā)軟件設(shè)計不適合做這個,但是這個是很重要的事.關(guān)于 RDS 前面講了我們所做的,可能沒那么多高大上的事情,但是實際上是我們已經(jīng)做的事,和關(guān)于 RDS 未來我們還會繼續(xù)往以下的系統(tǒng)模塊再繼續(xù)加深.RDS-Console,做更好的測試,RDS Proxy 做更好的性能和流量的劃分.HA Master 會引入 Roft 協(xié)議做診斷,而不是像前面所看到的圖里面,它是中間是居前判斷.而 CanalManager 會并入,不是通過 Canal 量,而是通過整套系統(tǒng)輸出的.而 Tablet 會做更多的試用和運維的動作,而 MySQL 沒有太多的改造,只會做更新迭代.

?提問：請問 DDL 具體怎么提高工作效率的?

林足雄：我不知道多少人經(jīng)歷過 0-300 人團隊或者 300 人團隊.DDL 本身開發(fā)給 DBA 提交 DDL 的時候,它是通過口對口,或者文本文件或者是后來稍微改進一點的,比如工作流,在這里提交一個工單,然后 DBA 每天去過那些工單.過完工單之后,DBA 把具體的 DDL 在 MySQL 上通過命令函 CL 顯示執(zhí)行 DDL.而 DDL 本身當時來說是沒有問題的.

我前面提到了,業(yè)務(wù)線非常多的時候,在七八個語句的時候效率蠻高的,當又有分片的時候來說,每條具體的語句就要形成 1014 個執(zhí)行任務(wù),DDL 的時間就會很大量的占用 DBA 的時間.還包括 DDL 對于每一個 Sharding 上是否成功 DBA 也關(guān)心.而是否成功這個動作本身還是需要同步等待的.比如說一百句數(shù)據(jù)庫的話它就得等,或者過一段時間再檢查.而改造變成把這些工作流全放在管理系統(tǒng)里.管理系統(tǒng)里通過開發(fā)人員在管理系統(tǒng)里提交工單,然后給具體的執(zhí)行 MySQL,把執(zhí)行的后果和進度提交到 Console 系統(tǒng)上,上報到 Console 系統(tǒng)可以通過界面展示,并且連動手機的報警和短信,或者我們有贊內(nèi)部的 APP 系統(tǒng)搜集就可以.這樣會減少 DBA 凌晨執(zhí)行任務(wù)的時間.因為大量的 DBL 是在凌晨跑的.比如說十句以下的 DDL 下去,DBA 在凌晨不需要值班,以前是需要的.所以 DBA 的生命還是蠻寶貴的.

作者介紹

林足雄,有贊架構(gòu)師,2010-2013 金山軟件,開發(fā)經(jīng)理 + 架構(gòu)師；2013-2015 蘑菇街,架構(gòu)師；2015- 至今 有贊,中間件 TL+ 架構(gòu)師.

文章來自微信公眾號：高效開發(fā)運維

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4116.html