摘要：但是當(dāng)其中某幾組負(fù)荷較大時，其他組并無法協(xié)助分擔(dān)負(fù)荷。未來計劃目前正在評估的使用，未來計劃將后臺分析資料部份，改采用。

株式會社 FUNYOURS JAPAN 自 2014 在日本成立以來，營運(yùn)多款頗受好評的頁游跟手游，如：剣戟のソティラス、九十九姬 等，對于營運(yùn)游戲來說，能夠了解游戲中的玩家在做什么，喜歡的偏好是什么，關(guān)卡的設(shè)計是否平衡，都是相當(dāng)重要的，所以隨著營運(yùn)時間的增長，資料庫數(shù)據(jù)在億筆以上也是尋常的。

所以我們的技術(shù)單位也一直不斷在評估市面上的各種資料庫以及如何改進(jìn)目前現(xiàn)有系統(tǒng)與架構(gòu)，近年來最熱門的資料庫系統(tǒng)可以說是 NoSQL 了，不論 MongoDB，Cassandra，Redis，HBase 等等都占有一片天，具有讀寫快速，容易擴(kuò)展等特性。經(jīng)過初步了解后，采用 NoSQL 方式，需要對于目前的資料儲存架構(gòu)整個重新設(shè)計，并且需要配合采用的該套 NoSQL 資料庫進(jìn)行業(yè)務(wù)改造設(shè)計，那么該采用哪一套 NoSQL 資料庫又是一個需要慎重考慮的課題。先回過頭來看當(dāng)前最需要處理改進(jìn)的項(xiàng)目：1.儲存空間擴(kuò)展不易，2.單臺資料庫效能有限。

在處理儲存空間不足部分，一開始我們先采用了 MySQL innoDB 提供的壓縮表格格式，對于需要時常讀寫更新的部分使用了 8K page size，過往的日志部分采用 4K page size，效果非常令人滿意，釋放了大量的儲存空間，并且對于效能來說沒有造成可察覺的影響。這部分網(wǎng)路上的測試比較多，就不在此多做說明。但是很快的壓縮表格節(jié)省的空間畢竟是有限的，接下來只能增加 volume 容量以及將沒有需要更新的過往日志移動到其他資料庫上，雖然造成維護(hù)工作跟時間的繁復(fù)與負(fù)擔(dān)，但是問題解決了。

基于 MySQL 資料庫架構(gòu)單臺的性能限制上，我們采用了多組的資料庫伺服器，來滿足所需的效能。當(dāng)然不同組之間資料是不共通的，也就是無法直接使用 SQL 來做跨組間的操作，需要額外的程式來作業(yè)。而當(dāng)然為了大量的資料存取上的效能，分表分庫對表格進(jìn)行 partition 這些作業(yè)都少不了。

使用 NoSQL 式資料庫看似可以完美的提供出一個解法，但需要付出的成本也是高昂的。于是我們把眼光落到了 MySQL Cluster 上，這時看到了 Google 發(fā)布 Cloud Spanner beta 的新聞，NewSQL？這是什么? 很快的引起了我們濃厚的興趣，然后經(jīng)過多方調(diào)研，我們發(fā)現(xiàn)了 TiDB：一個開源在 GitHub 上的 NewSQL 資料庫。官方也持續(xù)不斷發(fā)布了很多相關(guān)的文章，隨著對 TiDB 的認(rèn)識，認(rèn)為對于目前現(xiàn)況是很合適的最佳化方案，相容于 MySQL，高可用性，容易水平擴(kuò)展。

在可行性評估與測試的時候，一開始采用了 TiKV 3 臺搭配 PD 3 臺，TiDB 2 臺混搭 PD 的架構(gòu)，使用了文件建議的 ansible 安裝，這時遇到兩個困難，第一個是在 ansible 檢查機(jī)器效能的時候會因?yàn)橛驳x寫效能而無法安裝。由于是使用云端機(jī)器，所以對硬體方面沒有太大的彈性，只好自己手動去修改腳本才能順利安裝。第二個也是在 ansible 里面會檢查 ntp 同步服務(wù)是否啟動，但是 centos7 預(yù)設(shè)的時間同步服務(wù)是 chrony，所以也是修改了腳本（后來的版本有提供 flag 能切換，也有自動安裝 ntp 的選項(xiàng)），總之是順利安裝了。這時因?yàn)?PingCAP 才剛發(fā)布了 ansible 安裝的方式，所以文件對于水平擴(kuò)展部分，如新增 TiKV、 PD 、TiDB 機(jī)器，或者移除機(jī)器，官方 doc 沒有詳細(xì)說明，于是就寫了封 mail 聯(lián)系 PingCAP，發(fā)完信出去吃午餐回來，官方已經(jīng)回復(fù)并且邀請加入 wechat，提供更即時的溝通跟支援，實(shí)在是很令人驚艷。

備份與還原的機(jī)制，TiDB 在這部分提供了一個性能比官方的 mysqldump 更快的方案- mydumper/loader，這里我們一開始使用 GitHub 上的 source 自己 build，但是有點(diǎn)問題，跟官方交流后，才知道原來 tidb-enterprise-tools 這個工具包里面已經(jīng)有提供了。mydumper 能夠使用正則表達(dá)式去挑選出想要的 database 跟 table 備份，對于原本架構(gòu)就會分庫分表的設(shè)計，更添加了不少方便，備份出來的檔案會全部放在一個資料夾內(nèi)，使用 loader 就可以將這個備份的資料再次進(jìn)入 DB。但是采用 TiDB 不就是為了使用同一張表的便利性嗎?當(dāng)巨量的數(shù)據(jù)都在同一個表內(nèi)的時候，雖然 mydumper/loader 的效能很好，由于必需全量備份的關(guān)系，還是需要一點(diǎn)時間，因?yàn)?TiDB 也支援 mysqldump，所以如果需要進(jìn)行增量備份，也可以采用 mysqldump 搭配 where 條件式來進(jìn)行。

因?yàn)樾枰獙τ诓煌姆?wù)進(jìn)行權(quán)限的管制，所以也一并測試了 TiDB 的帳號權(quán)限機(jī)制，那時還是 pre-GA 版本，根據(jù)文件上賦予模糊匹配會無法獲得權(quán)限，必須要完全匹配才能正常取得；另外是在使用 revoke 回收權(quán)限方面會沒有正確收回權(quán)限。但是在回報 PingCAP 后，很快的在 GA 版中就修復(fù)了。

初期上線采用了 4 core cpu、記憶體 32 GB 作為 TiKV，8 core cpu、記憶體 16 GB 作為 TiDB/PD，3 臺 TiKV、3 臺 PD 、2 臺 TiDB 跟 PD 混搭的方式。透過 prometheus 觀察，發(fā)現(xiàn) loading 都集中在同一臺 TiKV 上，且 loadaverage 在高峰期間會沖到 7 以上，初步判斷可能是規(guī)格不夠，于是決定將 TiKV 都提升到 16 core 、24 GB 記憶體。因?yàn)榫€上正在舉辦活動，所以不希望停機(jī)，采用先增加三臺 TiKV 機(jī)器同步后，再移除三臺原本 TiKV 的方式進(jìn)行，也特別感謝 PingCAP 在置換機(jī)器中間，一直在線上支援，過程中很平順的完成了切換機(jī)器。機(jī)器提高規(guī)格后，高峰期的 loadaverage 下降到 4，但是還是會集中在其中某一臺 TiKV 上不會分散到三臺，在 PingCAP 的協(xié)助分析下，判斷出可能是業(yè)務(wù)行為中的 select count(1) 這個 SQL 太過頻繁，涉及該業(yè)務(wù)數(shù)據(jù)一直存取在同 1 個 region，通過嘗試在文件上的提高開發(fā)度的方式，還是無法解決(最新的 v1.1 版有在對 count(*) 進(jìn)行最佳化)，最后結(jié)合數(shù)據(jù)特性對業(yè)務(wù)行為進(jìn)行了變更，loadavg 幾乎都是保持在 1 以下。

比較原本架構(gòu)與 TiDB 架構(gòu)，原本架構(gòu)上是采用多組 DB 的方式來讓使用者分布在不同組 DB 上面，來達(dá)到所需的效能。但是當(dāng)其中某幾組負(fù)荷較大時，其他組 DB 并無法協(xié)助分擔(dān)負(fù)荷。采用 TiDB 的架構(gòu)后，在機(jī)器的使用上更有效率，并且在使用后臺查找分析資料時，原本的架構(gòu)下，只要時間一拉長到一個月以上，就會對該組 DB 的效能造成影響；在 TiDB 的架構(gòu)下，并不會有這樣的問題。
現(xiàn)在運(yùn)營上最直接的效益就是硬體成本的節(jié)約,原架構(gòu)下每一組 DB 規(guī)格都必須符合尖峰期間的運(yùn)作。但是在 TiDB 的架構(gòu)下，將全部的機(jī)器整合成一體后，只要全部機(jī)器加總起來的效能能夠達(dá)到尖峰期間即可，在監(jiān)控上搭配 Prometheus/Grafana 的視覺化系統(tǒng)與能彈性的自訂規(guī)則的警示，也免去了原本使用 snmp 自建監(jiān)視系統(tǒng)的成本。另外由于降低了撰寫程式的復(fù)雜度，當(dāng)運(yùn)營企劃人員提出新的想得知的分析資料時，能夠更快的從資料庫中取出，而可以有更多的時間來應(yīng)對與分析使用者偏好。

目前正在評估 TiSpark 的使用，未來計劃將后臺分析資料部份，改采用 TiSpark。因?yàn)?TiSpark 可以直接操作 TiKV，也能夠應(yīng)用 Spark 提供的許多現(xiàn)成的函式庫來對收集到的 log 做數(shù)據(jù)分析。預(yù)期利用 Spark 的機(jī)器學(xué)習(xí)來初步判斷系統(tǒng)內(nèi)的每個功能是否正常運(yùn)作，并提出警示，例如當(dāng)使用者的登入頻率異常時等，來協(xié)助人工監(jiān)控游戲運(yùn)行狀態(tài)。

作者：張明塘 FUNYOURS JAPAN 運(yùn)營系統(tǒng)工程師