巧用RDS全家桶搭建億級新聞源倉庫

  我們的業務，有一個實時新聞源庫，初始大概有3000萬資料，現在大概有上億條資料了，我們在起初的處理方式比較簡單粗暴，直接購買了3台8核16G的SSD版本的ECS，組成了一主雙從的機組，從庫隻讀。

  業務是單庫，但是具體的内容是分表的，比如：

  article_content_01一直到article_content_200或更多，業務系統會在滿足要求後實時建立新的表，每張表的資料量大概在100萬左右。

  我們在2013/2014年開始遇到各種各樣的問題，也算是一些經驗教訓吧：

  1.使用ECS組建的資料庫叢集，可用性不是特别特别的高，主要受限于IO、網絡同步速率。甚至遇到過從庫意外關機，然後影響業務了。

  2.我們把所有的讀取SQL放到了從庫進行，但是問題來了，我們的開發語言是php，是以它沒有辦法像JAVA那樣做一個連接配接池來處理請求，一開始我們使用一個随機算法來配置設定每次讀請求所使用的從庫，導緻當我們的并發很大的時候，從庫的連接配接配置設定政策會出現不平均的問題，進而導緻某個從庫滿載。雖然最後通Haproxy完成了從庫的負載均衡，但是也帶來了額外的運維負擔。這個談不上是坑，算是一個經驗教訓，想當然的以為随機算法可以替代負載均衡了。

  3.風控的問題 ，有的時候一些不應該發生的低級錯誤就是這麼堂而皇之的出現了，比如，測試庫隻有3000萬資料，而正式庫有3億資料，有些邏輯代碼在測試庫的響應正常并不代表在正式庫也是正常的。如果你不能敏感并及時的去處理慢查詢，那業務基本也就涼了。

  4.監控的問題不提了，直到最後都沒找到一個稱心如意的MYSQL監控解決方案。

  5.審計的問題，我們永遠處于有日志，而沒辦法審計的狀态，有事沒事假裝看看罷了。

  6.備份就讨厭了，需要手動這先不說。備份時機、鎖表、備份後的歸檔處理、定時清理老備份、備份檔案的校驗，這些都是事兒啊，對運維人員來說，都是很低級但是不得不做的工作。

  7.有的時候，你的Web伺服器抗住了流量，但是不幸的是你的資料庫沒能堅持下去，這種突發的流量往往沒辦法預測，或者出現後需要最短時間内修複，我們出現過大概3次，每次大概2小時時間去擴容，會影響一部分我們使用者的體驗，表現為卡頓、頁面報錯等。

  8.硬成本和運維成本問題，3台高配ECS+1個全職運維人員的成本，一年下來少說也要幾十萬。

  問題應該有很多，但是隻能想到這些，先記下來吧。其實有很多問題不是MYSQL的問題，屬于架構層面或者開發層面的問題，但是我們談一個具體技術細節的時候不能隻談它本身，沒有場景和實踐，那是耍流氓啊。

  然後我們從15年開始，實在是不行了，這種方式已經讓所有人都接近崩潰，是以我們考慮切換到RDS上去，當時隻是先切換了幾個不重要的業務庫，試試看效果。然後一發不可收拾，總結一句話，這産品除了價格，簡直完美。

  首先RDS for Mysql解決了我之前提到的幾個問題：

  1.托管式的服務，動态彈性的更新，不需要關心運維的問題。

  2.可以動态的添加隻讀庫，友善。

  3.控制台對慢查詢很敏感（雖然這個是近2年才有的功能），而且可以做報警。

  4.阿裡雲現在這一版的控制台看監控還算是比較舒服，也能看的全。

  5.日志審計這一塊，通過最新版本的阿裡雲DMS已經可以比較簡單的完成了，它還有個收費版，沒用過，沒有發言權，但是現在這個免費的版本也挺不錯的。

  6.備份不提，阿裡雲RDS的備份已經做得很好了。

  以上的問題，除了突發流量暴庫的問題不能通過RDS直接解決，其他都能很好的解決了。而且相對于3個ECS的成本，單獨購買RDS的費用也還在可以接受的範圍内。

  下面說一下，我們如何解決突發流量的問題，阿裡雲有個比較好的産品叫DRDS，但是這個産品屬于好用，但知名度不高的一個狀态，可能是小客戶用到的機率不高吧。

  DRDS扮演了一個類似負載均衡器的角色，當然了，比普通的負載均衡更進階一些。它不僅僅是Haproxy這種基于網絡點的負載均衡，還可以針對SQL進行負載均衡，這一點在處理超大表檢索的時候特别好用。而且它的後端是一個個的RDS，對于低成本突破連接配接數限制有非常大的幫助，同時彈性增減擴容，隻需要購買按量RDS就可以了。

  在高并發的場景下，資料庫遇到的問題主要在于連接配接數限制、IO限制、鎖、并發讀寫等問題，這些問題通過RDS/DRDS幾乎都可以很好地去進行處理，有些進階應用需要做一點點開發上的讓步。

  阿裡雲的RDS執行個體其實也經過變遷的，起初是隻限制記憶體和連接配接數，後來才出現“CPU核數”這個概念，是以也導緻了我這種老使用者一度很難适應，畢竟老版本2400M記憶體的RDS就預設8核了，而現在購買一個8核的RDS價格還是比較高的。我有個骨灰級的執行個體，可以截圖給大家看下，現在買不到啦：

  有一段時間，時不時也會收到短信提示，RDS發生主備切換雲雲，起初是比較緊張的，擔心阿裡雲的技術不硬進而影響我的業務，後來切換過多次之後，發現真的沒出過問題，從此也就安心了，小顧慮罷了。

  最後一部分說一下，我們如何解決全文檢索的問題，因為有分表的原因，是以很難通過程式去完成全文檢索，而且因為量大Like語句基本不可能使用。在這種情況下，我們開始嘗試使用第三方的工具去完成，比如Sphinx 。但是我們很快又遇到了問題：

  1.成本問題，因為Sphinx 不寫磁盤，一切讀取到後都存在記憶體，是以幾億資料對記憶體的要求就高了，買ECS的時候就要買高記憶體的配置。

  2.Sphinx一次性讀取資料到記憶體這個過程，可能對業務産生一定性能影響，但是不嚴重。

  3.Sphinx 的運維問題及配置問題。

  然後我們偶然的發掘了阿裡雲的OpenSearch産品，支援RDS一鍵同步并且可視化的建立表、索引很舒心，還提供了SDK和各種好用的函數。唯一的問題在于，價格感人，特别是資料量大且每天并發檢索高的使用者來說，這個成本很可觀。但是優點也很明顯：

  1.除了一開始的建立，幾乎不需要你運維。

  2.所有資料都打平到一層，檢索速度極快。

  3.支援分表結構，支援多個實體表，支援主外鍵關聯，萬物皆可查詢。

  4.對資料源幾乎沒有任何影響，即便你源庫挂了，檢索服務依舊可用。

  就先寫到這裡了，都是些經驗教訓，談不上太高深的技巧，主要還是要結合場景去做一個适合自己業務的架構。現在我們關系型資料庫用RDS for

Mysql，NoSQL資料庫使用RDS for

MongoDB，一路走來也都挺好的，雖然某個階段它有這樣那樣的問題，但是一個持續疊代的産品必然會有更高的生命力和穩定性。

原文來自：

qipangzi.com