張小峰 Oray技術(shù)總監(jiān)

簡(jiǎn)介

張小峰專注于高性能網(wǎng)絡(luò)辦事架構(gòu)，15年C++網(wǎng)絡(luò)應(yīng)用開發(fā)和團(tuán)隊(duì)辦理經(jīng)驗(yàn)；在DNS架構(gòu)、C++網(wǎng)絡(luò)通信技術(shù)、各操作系統(tǒng)API交互、圖像處理、加密算法等領(lǐng)域都有著深入的研究；在Oray技術(shù)團(tuán)隊(duì)中負(fù)責(zé)所有產(chǎn)品的網(wǎng)絡(luò)辦事及圖像底層架構(gòu)設(shè)計(jì)與開發(fā)；帶領(lǐng)團(tuán)隊(duì)先后研發(fā)了多款花生殼、向日葵遠(yuǎn)程控制軟件千萬量級(jí)的產(chǎn)品，從事其中的結(jié)構(gòu)設(shè)計(jì)與關(guān)鍵技術(shù)攻關(guān)。是Oray技術(shù)團(tuán)隊(duì)的領(lǐng)頭羊與靈魂人物。

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

創(chuàng)始產(chǎn)品花生殼是個(gè)簡(jiǎn)單的動(dòng)態(tài)域名產(chǎn)品，用戶可以用它發(fā)布本身的各類辦事，從網(wǎng)站到各類專用數(shù)據(jù)連接；就算在中國互聯(lián)網(wǎng)環(huán)境如此殘酷同時(shí)IPv4資源在不停萎縮的今天，這個(gè)產(chǎn)品還在不停的發(fā)展壯大。雖然外貌看起來是個(gè)簡(jiǎn)單的工具軟件，但它為中國一代代的互聯(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、 使用長(zhǎng)連接維持被控在線狀態(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è)簡(jiǎn)單的C/S結(jié)構(gòu)軟件，我們需要像聊天辦事器那樣與客戶端進(jìn)行實(shí)時(shí)交互，而客戶端在線量一直在兇猛的增長(zhǎng)中，我們的系統(tǒng)以及運(yùn)維和開發(fā)團(tuán)隊(duì)也就不竭的迭代并成長(zhǎng)。

上面提到，向日葵使用關(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í)剛發(fā)布向日葵的幾個(gè)月我們是把它們同時(shí)放在關(guān)系數(shù)據(jù)庫里的，阿誰時(shí)候主要考慮的也不是辦事端的性能問題，而是整個(gè)系統(tǒng)跑通，只是我們的數(shù)據(jù)庫后來吃不用了，這一段經(jīng)歷不長(zhǎng)，說真的也沒啥好講的。

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

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

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

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

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

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

由于ttserver跟memcached通信協(xié)議上完全兼容，但為了制止全局性的災(zāi)難，我們?cè)谕瓿啥郼ache辦事優(yōu)化后，新系統(tǒng)很快就上線了。

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

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

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