739
如何選擇合適的數據庫，讓遊戲更高效可用
3月8日，2017遊戲行業全球同服和安全攻防技術沙龍在上海舉行，阿裏雲資深技術專家丁奇帶來題為“ApsaraDB介紹—MySQL”的演講。本文分五部分為大家介紹，首先從RDS基本架構開始聊起，進而說到了如何保障平台數據庫的數據安全和高可用，接著談及了多種數據庫引擎快速適配遊戲邏輯服務，包括RDS新特性:克隆實例、恢複到任意時間點、連接保持等，最後著重分享了RDS可診斷性設計並對雲數據庫目標做了總結。
以下是精彩內容整理：
RDS基本架構
RDS上買一個實例基本可以看到一主一備的雙節點場景，但雙節點理論上不能保證不丟數據，
即使是異步複製也容易丟數據，如果作為內部業務分級，日誌類丟一點沒關係，但實際上我們不知道用戶業務是什麼類型的，默認認為都不能丟，可能用戶會感覺新實例沒有老實例跑得快，用戶可以自主在控製台手動設置模式。
雙節點還是有很多的不完備，假設網絡抖動時主庫掛掉，日誌就會傳不過去，B超過一秒沒有返回就會退化，如果不退化B係統不可維護，可用性降低，如果剛好在退化期間A掛掉，還是會丟數據，因此我們采用三節點方案。
三節點方案不用退化，A寫入時，B或C至少有一個人響應收到日誌，如果A掛掉，在B和C選擇日誌收的多的切過去當作主庫，從而提高可用性。
可靠性&可用性
切換策略
我們的切換策略即是主庫掛了就切，需要保證三點：
首先要正確，不要不該切時切；其次要及時，該切時候一定要切；最後是最小化，可切可不切時候不要切，切了如果沒有用也不要切。
我們內部演化出了三步：開始我們進行select探測，如果成功有返回就沒事，沒有返回即掛了，後麵我們發現不對，當主庫可以讀不可以寫的時候，比如磁盤滿了，select都成功，但業務都寫不下去了；接著我們考慮更新探測，自己找係統表update，如果更新成功，說明業務可寫，更新超時或失敗就切換，但當業務壓力變大時，操作係統並不是直接罷工，還是盡力的提供服務，當磁盤IOPS達到100%時，不是突然變成零，也是有在服務的，可能會出現update語句過了但業務沒過；現在我們的策略是自動報告，MySQL自己知道自己的狀況，如果某一個IO響應超過多少秒就說明這個庫不行了，MySQL會告訴切換係統切掉主庫，MySQL自己會記錄讀寫時間，這是一個全局信息，不會誤報也不會漏報。
你會發現切換係統不再負責決策切換，它隻負責查詢，讓數據庫本身來決定誰是主庫誰是備庫。
連接保持
遊戲也比較關心閃斷問題，除了網絡抖動外，日常情況下會有非常多需要主動切換連接的操作，比如機器下線、磁盤遷移和軟件升級等，都需要主動切換，但此過程連接會斷開，對用戶造成影響，這樣的動作很多，而雲用戶有上萬個，我們不知道誰有做重連誰沒做重連。
現在我們的做法是主動切換優化，用戶誤感知，中間的Proxy可以做很多事情，切換時先將B升級，連接從A切到B，但用戶連接的是Proxy，所以不會感知，項目需要在用戶離峰期切換。
恢複到任意時間點
恢複到任意時間點，指定一個時間點，起一個臨時實例，把數據恢複到指定那一秒之前的數據狀態，具體邏輯如下：
第一步，取上一個全量備份，恢複到臨時實例；
第二步，取上一個備份之後的binlog，應用；
第三步，接上主庫，追日誌到指定時刻。
雪崩場景
如果失敗要斷開重連，但有時可能不是失敗而是變慢了，比如預計一秒返回，但一秒沒返回你可能就會斷開，如果數據庫斷開會有很多重試邏輯，瞬間超時導致重試，業務會重試，然後客戶會重試，但數據庫裏的連接還在跑，接下來又會發起一波連接，可能原來50個連接在跑，突然發生大的操作將數據庫拖慢後，就會變成100個連接在跑，都超時就會都重連，越來越多進而掛掉，這時候業務kill都來不及，隻能重啟。在RDS中，我們提供select max_statement_time=1000的源碼方案，表示語句最多執行1000ms，到了1000ms就會內部自殺，時間與業務端超時設成相同即可。
性能&成本
日誌業務
業務發展起來後，日誌占的成本比業務數據還要大，那麼，日誌的特性包括：數據量很大、寫入量大和查詢少。TokuDB十倍壓縮和寫數據速度不衰減可滿足日誌的特性。
在TokuDB上加Petadata效果更好，Petadata是RDS自己開發的中間件，可以支持分庫分表和分布式事務，連接透明，客戶端隻需要連接Petadata即可，要擴容時隻需把機器加進去，後台自己會做靜默遷移，應用沒有感知。
功能&形態
- 有些用戶隻需要一個節點隨便算數據，丟了也沒關係，可以用從伸展庫拉數據過來，我們會選擇在ECS上自建單節點版本；
- 克隆實例就是給新開服使用的；
- 恢複到時間點可以實現快速回檔；
- Petadata具備分庫分表功能，同時還有分析功能，目前主推HybridDB，當數據量大時想做複雜查詢，我們會根據需求選擇產品。如果隻是需要一個庫跟主庫一模一樣，想在上麵跑複雜查詢，又不想影響主庫業務，這種一般應用RDS隻讀實例即可；如果需要拷下來放到本地的hadoop上跑才行，或者做業務時分成五六個庫，而分析時要合到一起，就可以將數據導到HbridDB中，分析非常快。
可診斷性
審計日誌
可診斷性可以衡量一個雲服務的成熟度。審計隻是其中一部分，我們做全鏈路監控，包括磁盤、內存、數據庫、網卡以及各種鏈路等，當即不是上遊也不是下遊，而是MySQL內部出問題時就需要DBA出場了，審計日誌是做可診斷性最重要的工具，記錄所有的用戶數據操作才有審計效果，看上去很像general_log，開啟後性能下降90%，而RDS審計日誌性能隻下降2%，記錄了源ip、用戶名、線程id、掃描行數、latency、執行時間(us)、返回行數、更新行數、錯誤號和消耗內存，並不是所有的不是慢SQL語句都沒有問題，如果記得所有數據，一個普通語句返回兩行，掃描5000行，說明索引沒有建好，即使語句短時間返回，也應該被處理。
診斷報告
我們推出診斷報告，在測試後我們會出某個時間段的數據庫狀態，有哪些潛在問題，潛在的死鎖原因需要解決，告訴你哪些事務時不必要的，哪些事務已經回滾了。
小結
雲數據庫的目標是讓MySQL像Orcale一樣，允許DBA去逃避簡單的工作，讓他們有精力變成數據架構師。
丁奇：阿裏雲關係數據庫服務內核開發和運維團隊負責人，活躍的MySQL社區貢獻者。開源分支AliSQL和《數據庫內核月報》負責人。在雲數據庫係統開發、運維、架構優化上有豐富的經驗。現致力於推動通過自動化專家係統的建設和推廣，以提升雲數據庫用戶的業務穩定性。
最後更新：2017-04-19 10:00:39