memcached plugin在實踐中的應用
應用背景介紹
我所在職的Oray是一家提供各種互聯網服務且具有海量用戶的企業，我們也一直在實踐各種新技術新架構；緩存方面，我們從memcached、ttserver、redis等都有較多應用，其中redis在我們的dns體系中有著很深度的集成使用；MySQL InnoDB memcached plugin出來有挺長時間了，網上還沒見到國內有把它用到生產環境的實例，我今天就給大家說下小白鼠體驗。
創始產品花生殼是個簡單的動態域名產品，用戶可以用它發布自己的各類服務，從網站到各類專用數據連接；就算在中國互聯網環境如此殘酷同時IPv4資源在不斷萎縮的今天，這個產品還在不斷的發展壯大。雖然表面看起來是個簡單的工具軟件，但它為中國一代代的互聯網人解決了很多基礎的連接問題！
但很大一部分用戶使用我們的花生殼也就是為了遠程操作電腦，所以2010年，在我們埋頭苦干了1年多后推出了向日葵遠程控制產品，這個產品的基本功能就是讓用戶不需要關心IP端口等技術知識就可以遠程管理控制他的所有電腦，這個產品主要依賴以下技術：
1、通過關系型數據庫管理用戶主機清單；
2、使用長連接維持被控在線狀態；
4、優化的算法盡可能的降低用戶帶寬占用以及提高圖像質量；
5、其他周邊技術，如HTML5免插件遠程控制、遠程開機等。
客戶端、操作系統以及相關遠控技術問題我們今天先不探討，向日葵也不是一個簡單的C/S結構軟件，我們需要像聊天服務器那樣與客戶端進行實時交互，而客戶端在線量一直在兇猛的增長中，我們的系統以及運維和開發團隊也就不停的迭代并成長。
2、向日葵遠程控制技術的數據需求
上面提到，向日葵使用關系型數據庫存貯某一個用戶擁有哪些主機，以及這些主機的具體相關信息；在此同時，我們也需要臨時存儲一些關鍵的實時數據：
1、 主機鑒權信息
2、 主機在線狀態
3、 如何連接主機
從這些數據內容可以看出它們是實時產生且需要多方可以直接訪問的，向日葵的被控端可能登陸在全國各地任意一臺長連接服務器上，而試圖過來訪問這個被控的主控端則需要通過API服務實時讀取被控的狀態信息，以及讀取這個被控通過哪個長連接服務能被訪問到；整個向日葵有多少臺主機，這個實時數據就有多少條；每條數據大概也就幾百個字節，目前每組服務數百萬條記錄。這些數據的更新頻繁度也非常高，因為那么大量的被控端總是在不停的上下線，目前峰值的時候QPS可以達到萬次。
其實剛發布向日葵的幾個月我們是把它們同時放在關系數據庫里的，那個時候主要考慮的也不是服務端的性能問題，而是整個系統跑通，只是我們的數據庫后來吃不消了，很快我們就走上了漫長緩存優化之路。
3、緩存優化史
既然存在關系數據庫中不合適，我們就開始用各種緩存技術來存儲這種實時數據。
3.1 從memcached到ttserver
3.1.1 memcached
第一代的主機狀態數據緩存化，我們把它放在了memcached，整個客戶端的登陸過程是這樣的（里頭略去了各種錯誤處理及異常以及各種附屬架構，比如負載均衡或者備份等）：
把狀態等需要頻繁訪問的數據放到緩存后，這個大框架到現在也還基本上是這樣，API負責所有跟持久化DB的交互操作，長連接只負責跟memcached的通信，這樣也避免了我們的DB有過多角色參與讀寫；另外這個時候我們只有一臺memcached服務器，因為我們算過16G內存大約可以放上億的主機信息。
但這些數據跑memcached真的合適嗎？
memcached剛剛上線的很長一段時間內系統運行還是很完美的，速度也完全夠用，因為數據量以及QPS對memcached來說也還不太大，但后來我們的向日葵用戶量發展迅速，主機和在線量都在急劇的上漲；而由于memcached并沒有主從同步之類的機制，任一個主機的緩存信息只能存在一個memcached中，而一個memcached其實也就是一個進程，我們沒法保證這個進程永遠活著，它會崩潰，機器也會死掉，網絡也會死掉。
在經歷了兩次memcached崩潰后我們也崩潰了，memcached的數據是完全放在內存里的，崩潰后存在其中的所有主機全部會變成不在線且只能通過重啟所有服務器解決，而重啟所有服務器意味著所有原先在線客戶端都得全部重新登陸一次，這個過程會極其漫長，以小時計的。
3.1.2 ttserver
我們要改進了，順其自然的，我們想到了ttserver，ttserver可以在崩潰重啟后恢復數據且具備主備同步功能，而丟失那部分數據我們可以在客戶端登陸時從DB里自動恢復出來；
由于ttserver跟memcached通信協議上完全兼容，但為了避免全局性的災難，我們在完成多cache服務優化后，新系統很快就上線了。
新緩存體系的結構長這樣的：
完全堆疊式的設計，理論上也是可以無限擴容的，但我們沒意識到ttserver幾個大問題：
ttserver不支持key過期的，需要開啟table database模式，并通過lua腳本的方式來實現，但該模式ttserver的運行性能相當差，并且在數據很大的時候出現不穩定的現象。
這個不穩定現象我們不湊巧也遇到了：由于它會自動把不頻繁讀寫的數據swap到磁盤，它倒不會像memcached那樣容易崩潰，但它會偶爾神經質似的卡；卡到什么程度呢：手工上去敲個get，大概要幾百ms才會得到結果；而我們對ttserver做了很多優化依舊于事無補。前兩次卡死，重啟能解決，但后來，我們不得不把它保存的文件徹底刪除才能恢復性能，這不又回到了memcached時代嗎？怎么辦？
3.2 MySQL InnoDB memcached plugin
在我們出現ttserver危機的時候，已經沒有什么能讓我更絞盡腦汁的事情了，天天到各社區調研，某個偶然的機會，我看到了MySQL居然支持memcached插件，這真是個神奇的組合：
傳統關系型數據庫在大數據時代的性能與擴展，離不開內存與分布式這兩大主題。
在傳統的關系型數據庫中，Oracle的Timesten，SQL Server的Hekaton，都是選擇與內存數據庫相集合，但實際上卻少有突出的應用場景。而MySQL嵌入nosql ，在性能與管理、分析上達到互補，則是更為有意義的結合。
MySQL5.6.6后開始內嵌 memcached 的支持，在MySQL 5.7較新的版本性能大幅提升，有測試表明在48核只讀環境下QPS可以達到百萬以上。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%