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和《數據庫內核月報》負責人。在云數據庫系統開發、運維、架構優化上有豐富的經驗。現致力于推動通過自動化專家系統的建設和推廣，以提升云數據庫用戶的業務穩定性。

總結

以上是生活随笔為你收集整理的如何选择合适的数据库，让游戏更高效可用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。