應(yīng)用背景介紹

　　我所在職的Oray是一家提供各種互聯(lián)網(wǎng)服務(wù)且具有海量用戶的企業(yè)，我們也一直在實(shí)踐各種新技術(shù)新架構(gòu)；緩存方面，我們從memcached、ttserver、redis等都有較多應(yīng)用，其中redis在我們的dns體系中有著很深度的集成使用；MySQL InnoDB memcached plugin出來有挺長時(shí)間了，網(wǎng)上還沒見到國內(nèi)有把它用到生產(chǎn)環(huán)境的實(shí)例，我今天就給大家說下小白鼠體驗(yàn)。

　　創(chuàng)始產(chǎn)品花生殼是個(gè)簡單的動(dòng)態(tài)域名產(chǎn)品，用戶可以用它發(fā)布自己的各類服務(wù)，從網(wǎng)站到各類專用數(shù)據(jù)連接；就算在中國互聯(lián)網(wǎng)環(huán)境如此殘酷同時(shí)IPv4資源在不斷萎縮的今天，這個(gè)產(chǎn)品還在不斷的發(fā)展壯大。雖然表面看起來是個(gè)簡單的工具軟件，但它為中國一代代的互聯(lián)網(wǎng)人解決了很多基礎(chǔ)的連接問題！

　　但很大一部分用戶使用我們的花生殼也就是為了遠(yuǎn)程操作電腦，所以2010年，在我們埋頭苦干了1年多后推出了向日葵遠(yuǎn)程控制產(chǎn)品，這個(gè)產(chǎn)品的基本功能就是讓用戶不需要關(guān)心IP端口等技術(shù)知識(shí)就可以遠(yuǎn)程管理控制他的所有電腦，這個(gè)產(chǎn)品主要依賴以下技術(shù)：

　　1、通過關(guān)系型數(shù)據(jù)庫管理用戶主機(jī)清單；

　　2、使用長連接維持被控在線狀態(tài)；

　　3、P2P通信技術(shù)傳輸控制信號(hào)以及圖像信號(hào)；

　　4、優(yōu)化的算法盡可能的降低用戶帶寬占用以及提高圖像質(zhì)量；

　　5、其他周邊技術(shù)，如HTML5免插件遠(yuǎn)程控制、遠(yuǎn)程開機(jī)等。

　　客戶端、操作系統(tǒng)以及相關(guān)遠(yuǎn)控技術(shù)問題我們今天先不探討，向日葵也不是一個(gè)簡單的C/S結(jié)構(gòu)軟件，我們需要像聊天服務(wù)器那樣與客戶端進(jìn)行實(shí)時(shí)交互，而客戶端在線量一直在兇猛的增長中，我們的系統(tǒng)以及運(yùn)維和開發(fā)團(tuán)隊(duì)也就不停的迭代并成長。

　　2、向日葵遠(yuǎn)程控制技術(shù)的數(shù)據(jù)需求

　　上面提到，向日葵使用關(guān)系型數(shù)據(jù)庫存貯某一個(gè)用戶擁有哪些主機(jī)，以及這些主機(jī)的具體相關(guān)信息；在此同時(shí)，我們也需要臨時(shí)存儲(chǔ)一些關(guān)鍵的實(shí)時(shí)數(shù)據(jù)：

　　1、 主機(jī)鑒權(quán)信息

　　2、 主機(jī)在線狀態(tài)

　　3、 如何連接主機(jī)

　　從這些數(shù)據(jù)內(nèi)容可以看出它們是實(shí)時(shí)產(chǎn)生且需要多方可以直接訪問的，向日葵的被控端可能登陸在全國各地任意一臺(tái)長連接服務(wù)器上，而試圖過來訪問這個(gè)被控的主控端則需要通過API服務(wù)實(shí)時(shí)讀取被控的狀態(tài)信息，以及讀取這個(gè)被控通過哪個(gè)長連接服務(wù)能被訪問到；整個(gè)向日葵有多少臺(tái)主機(jī)，這個(gè)實(shí)時(shí)數(shù)據(jù)就有多少條；每條數(shù)據(jù)大概也就幾百個(gè)字節(jié)，目前每組服務(wù)數(shù)百萬條記錄。這些數(shù)據(jù)的更新頻繁度也非常高，因?yàn)槟敲创罅康谋豢囟丝偸窃诓煌５纳舷戮€，目前峰值的時(shí)候QPS可以達(dá)到萬次。

　　其實(shí)剛發(fā)布向日葵的幾個(gè)月我們是把它們同時(shí)放在關(guān)系數(shù)據(jù)庫里的，那個(gè)時(shí)候主要考慮的也不是服務(wù)端的性能問題，而是整個(gè)系統(tǒng)跑通，只是我們的數(shù)據(jù)庫后來吃不消了，很快我們就走上了漫長緩存優(yōu)化之路。

　　3、緩存優(yōu)化史

　　既然存在關(guān)系數(shù)據(jù)庫中不合適，我們就開始用各種緩存技術(shù)來存儲(chǔ)這種實(shí)時(shí)數(shù)據(jù)。

　　3.1 從memcached到ttserver

　　3.1.1 memcached

　　第一代的主機(jī)狀態(tài)數(shù)據(jù)緩存化，我們把它放在了memcached，整個(gè)客戶端的登陸過程是這樣的（里頭略去了各種錯(cuò)誤處理及異常以及各種附屬架構(gòu)，比如負(fù)載均衡或者備份等）：

　　把狀態(tài)等需要頻繁訪問的數(shù)據(jù)放到緩存后，這個(gè)大框架到現(xiàn)在也還基本上是這樣，API負(fù)責(zé)所有跟持久化DB的交互操作，長連接只負(fù)責(zé)跟memcached的通信，這樣也避免了我們的DB有過多角色參與讀寫；另外這個(gè)時(shí)候我們只有一臺(tái)memcached服務(wù)器，因?yàn)槲覀兯氵^16G內(nèi)存大約可以放上億的主機(jī)信息。

　　但這些數(shù)據(jù)跑memcached真的合適嗎？

　　memcached剛剛上線的很長一段時(shí)間內(nèi)系統(tǒng)運(yùn)行還是很完美的，速度也完全夠用，因?yàn)閿?shù)據(jù)量以及QPS對memcached來說也還不太大，但后來我們的向日葵用戶量發(fā)展迅速，主機(jī)和在線量都在急劇的上漲；而由于memcached并沒有主從同步之類的機(jī)制，任一個(gè)主機(jī)的緩存信息只能存在一個(gè)memcached中，而一個(gè)memcached其實(shí)也就是一個(gè)進(jìn)程，我們沒法保證這個(gè)進(jìn)程永遠(yuǎn)活著，它會(huì)崩潰，機(jī)器也會(huì)死掉，網(wǎng)絡(luò)也會(huì)死掉。

　　在經(jīng)歷了兩次memcached崩潰后我們也崩潰了，memcached的數(shù)據(jù)是完全放在內(nèi)存里的，崩潰后存在其中的所有主機(jī)全部會(huì)變成不在線且只能通過重啟所有服務(wù)器解決，而重啟所有服務(wù)器意味著所有原先在線客戶端都得全部重新登陸一次，這個(gè)過程會(huì)極其漫長，以小時(shí)計(jì)的。

　　3.1.2 ttserver

　　我們要改進(jìn)了，順其自然的，我們想到了ttserver，ttserver可以在崩潰重啟后恢復(fù)數(shù)據(jù)且具備主備同步功能，而丟失那部分?jǐn)?shù)據(jù)我們可以在客戶端登陸時(shí)從DB里自動(dòng)恢復(fù)出來；

　　由于ttserver跟memcached通信協(xié)議上完全兼容，但為了避免全局性的災(zāi)難，我們在完成多cache服務(wù)優(yōu)化后，新系統(tǒng)很快就上線了。

　　新緩存體系的結(jié)構(gòu)長這樣的：

　　完全堆疊式的設(shè)計(jì)，理論上也是可以無限擴(kuò)容的，但我們沒意識(shí)到ttserver幾個(gè)大問題：

　　ttserver不支持key過期的，需要開啟table database模式，并通過lua腳本的方式來實(shí)現(xiàn)，但該模式ttserver的運(yùn)行性能相當(dāng)差，并且在數(shù)據(jù)很大的時(shí)候出現(xiàn)不穩(wěn)定的現(xiàn)象。

　　這個(gè)不穩(wěn)定現(xiàn)象我們不湊巧也遇到了：由于它會(huì)自動(dòng)把不頻繁讀寫的數(shù)據(jù)swap到磁盤，它倒不會(huì)像memcached那樣容易崩潰，但它會(huì)偶爾神經(jīng)質(zhì)似的卡；卡到什么程度呢：手工上去敲個(gè)get，大概要幾百ms才會(huì)得到結(jié)果；而我們對ttserver做了很多優(yōu)化依舊于事無補(bǔ)。前兩次卡死，重啟能解決，但后來，我們不得不把它保存的文件徹底刪除才能恢復(fù)性能，這不又回到了memcached時(shí)代嗎？怎么辦？

　　3.2 MySQL InnoDB memcached plugin

　　在我們出現(xiàn)ttserver危機(jī)的時(shí)候，已經(jīng)沒有什么能讓我更絞盡腦汁的事情了，天天到各社區(qū)調(diào)研，某個(gè)偶然的機(jī)會(huì)，我看到了MySQL居然支持memcached插件，這真是個(gè)神奇的組合：

　　傳統(tǒng)關(guān)系型數(shù)據(jù)庫在大數(shù)據(jù)時(shí)代的性能與擴(kuò)展，離不開內(nèi)存與分布式這兩大主題。

　　在傳統(tǒng)的關(guān)系型數(shù)據(jù)庫中，Oracle的Timesten，SQL Server的Hekaton，都是選擇與內(nèi)存數(shù)據(jù)庫相集合，但實(shí)際上卻少有突出的應(yīng)用場景。而MySQL嵌入nosql ，在性能與管理、分析上達(dá)到互補(bǔ)，則是更為有意義的結(jié)合。

　　MySQL5.6.6后開始內(nèi)嵌 memcached 的支持，在MySQL 5.7較新的版本性能大幅提升，有測試表明在48核只讀環(huán)境下QPS可以達(dá)到百萬以上。