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

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

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

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

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

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

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

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

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

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

比較原本架構(gòu)與 TiDB 架構(gòu)，原本架構(gòu)上是采用多組 DB 的方式來讓使用者分布在不同組 DB 上面，來達(dá)到所需的效能。但是當(dāng)其中某幾組負(fù)荷較大時(shí)，其他組 DB 并無法協(xié)助分擔(dān)負(fù)荷。采用 TiDB 的架構(gòu)后，在機(jī)器的使用上更有效率，并且在使用后臺(tái)查找分析資料時(shí)，原本的架構(gòu)下，只要時(shí)間一拉長到一個(gè)月以上，就會(huì)對(duì)該組 DB 的效能造成影響；在 TiDB 的架構(gòu)下，并不會(huì)有這樣的問題。
現(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)營企劃人員提出新的想得知的分析資料時(shí)，能夠更快的從資料庫中取出，而可以有更多的時(shí)間來應(yīng)對(duì)與分析使用者偏好。

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

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