|
2011年初Marc Kwiatkowski通過Memecache@Facebook介紹了Facebook的Memcache架構，現在重新審視這個架構，仍有很多方面在業(yè)界保持先進性。作為weibo內部數據處理量最大，對數據延遲最敏感的部門，基于本廠2年多來對mc的使用心得，我在本文總結對MC架構的一些新思考。
1. Memcache使用中的雷區(qū) 通常你可能考慮不到，但又隱藏在某處等著你踩的稱之為“雷”。
帶寬和連接數 Memcache具有很高吞吐能力，Memecache@Facebook中介紹Memcache支持8萬/s讀和2萬/s寫，在weibo內部我們通常認為單個Memcache實例支持7w/s讀，2w/s寫是安全的。和Facebook一樣，為了充分榨取服務器性能，我們會在一臺物理機上部署多個Memcache。為了確保Memcache的正常工作，我們通常會通過定期執(zhí)行MC stats命令來對內存使用量，踢出率，命中率等進行監(jiān)控。比如微博早期監(jiān)控中就包括如圖所示的這些內容，
這些監(jiān)控中我們最重視的往往是內存使用量和命中率。但隨著前端服務不斷增加和cache層不斷擴容，單臺緩存物理機上的連接數，帶寬都成為新的瓶頸。因此必須重視對帶寬和連接數的監(jiān)控。Memecache@Facebook中介紹單臺MC服務器可支撐10w連接。
Hot Key Hot Key通常不常見，但Weibo和Facebook都遇到這類問題，簡單的講就是在大并發(fā)下，有大量的請求到同一個在MC中不存在的資源，然后全部read through到后端數據庫，把數據庫讀跨。具體方法請見TimYang的博客：http:///programming/memcache-mutex/，同時后面的討論也很精彩。不過我查閱大量微博代碼卻沒有發(fā)現有使用MC mutex，也就是說Hot Key是個不常見的問題，一個不容易踩到的雷。
Memcache Client 不記得是不是在Memecache@Facebook提到過，也和淘寶的同行交流過，共同的的經驗是：Memcache優(yōu)化的重點和難點在客戶端。這個展開起來很大，概況講有2個重點：（1）TCP連接池（2）基于NIO的multiget；可以參考我的另一篇文章：通過NIO實現Memcached multi get （http://maoyidao./blog/1739282）
2. Memcache集群是否支持線性擴容？ 擴容問題之一：如果不降低命中率？ 擴容Memcache不降低命中率，好像在高速路上給汽車換輪胎。 我們通常從課本上學到的是，前端采用一致性Hash，邏輯節(jié)點達2^32個，物理節(jié)點擴容也不會導致大量cache命中移動。一致性Hash足以應對大多數場景，但在微博業(yè)務中，每秒超過十幾萬次讀，及時下降1%的命中率也會直接讀跨數據庫，因此我們的要求是擴容不能降低命中率。為達到該目的，我們把水平擴展，變?yōu)榇怪睌U展，即通過多層Cache解決擴容而同時不降低命中率的問題。
擴容問題之二：Memcache集群具備水平擴展性嗎？ 隨著緩存層的增長，數據被分散到更多緩存服務器上，獲取相同信息需要發(fā)送的網絡包的數量也在不斷增長。比如，只有一臺緩存服務器時，由于操作系統(tǒng)網絡層發(fā)送緩沖區(qū)的設計，get 100個key的數據可以在一個IP packet中傳輸，結果可以也可以在一個IP packet中獲取。但當有100臺緩存服務器時，獲取100個key的數據就有需要向100臺服務器發(fā)送100個IP packet（假設100個數據均勻的分布在100臺物理機上），相應的內核中斷也顯著增加。
因此，我不認為Memcache集群在這個概念下具備水平擴展能力。但通常我們通過劃分不同數據大小的緩存池控制Memcache集群的大小，而且隨著96G或以上大內存服務器的廣泛使用。即便在微博這個場景下，12臺服務器一組的緩存就已經非常大規(guī)模的了。
3. Memcache其實還能更快？ 如果你追求極致的Memcache訪問速度，可以登錄上你的Memcache服務器，檢查一下CPU使用情況。我找了一臺線上服務，情況如下：
顯然CPU7的系統(tǒng)使用率比其他CPU要高。檢查一下軟中斷：
再看看線上服務的版本： [jichao1@yf179 ~]$ uname -a Linux yf179 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
在kernel-2.6.18-194.3.1.el 版本以下的Redhat以及CentOS 操作系統(tǒng)，使用Broadcom 5709網卡芯片的服務器存在cpu軟中斷不均衡，只有1個cpu處理軟中斷。
解決方法可以是升級內核，不過也有朋友說沒用，需要通過VIP綁定2塊網卡的方式解決，具體方案見：http://hi.baidu.com/higkoo/item/42ba6c353bc8aed76d15e9c3 通過對比內核支持4個隊列的服務器（最多只能利用到4核，無法在硬件驅動層直接配置成更多隊列），只分配一個CPU的Memcache服務器在大壓力下可能會慢1~2ms。
|
|
|
