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

ace.qi發表於2018-06-27

  我們的業務，有一個實時新聞源庫，初始大概有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


相關文章