2023年初marc kwiatkowski通過memecache@facebook介紹了facebook的memcache架構，現在重新審視這個架構，仍有很多方面在業界保持先進性。作為weibo內部資料處理量最大，對資料延遲最敏感的部門，基於本廠2年多來對mc的使用心得，我在本文總結對mc架構的一些新思考。
1. memcache使用中的雷區
通常你可能考慮不到，但又隱藏在某處等著你踩的稱之為「雷」。
頻寬和連線數
memcache具有很高吞吐能力，memecache@facebook中介紹memcache支援8萬/s讀和2萬/s寫，在weibo內部我們通常認為單個memcache例項支援7w/s讀，2w/s寫是安全的。和facebook一樣，為了充分榨取伺服器效能，我們會在一台物理機上部署多個memcache。為了確保memcache的正常工作，我們通常會通過定期執行mc stats命令來對記憶體使用量，踢出率，命中率等進行監控。比如微博早期監控中就包括如圖所示的這些內容，
這些監控中我們最重視的往往是記憶體使用量和命中率。但隨著前端服務不斷增加和cache層不斷擴容，單台快取物理機上的連線數，頻寬都成為新的瓶頸。因此必須重視對頻寬和連線數的監控。memecache@facebook中介紹單台mc伺服器可支撐10w連線。
hot key
hot key通常不常見，但weibo和facebook都遇到這類問題，簡單的講就是在大併發下，有大量的請求到同乙個在mc中不存在的資源，然後全部read through到後端資料庫，把資料庫讀跨。具體方法請見timyang的部落格：同時後面的討論也很精彩。不過我查閱大量微博**卻沒有發現有使用mc mutex，也就是說hot key是個不常見的問題，乙個不容易踩到的雷。
memcache client
不記得是不是在memecache@facebook提到過，也和**的同行交流過，共同的的經驗是：memcache優化的重點和難點在客戶端。這個展開起來很大，概況講有2個重點：（1）tcp連線池（2）基於nio的multiget；可以參考我的另一篇文章：通過nio實現memcached multi get （
2. memcache集群是否支援線性擴容？
擴容問題之一：如果不降低命中率？
擴容memcache不降低命中率，好像在高速路上給汽車換輪胎。
我們通常從課本上學到的是，前端採用一致性hash，邏輯節點達2^32個，物理節點擴容也不會導致大量cache命中移動。一致性hash足以應對大多數場景，但在微博業務中，每秒超過十幾萬次讀，及時下降1%的命中率也會直接讀跨資料庫，因此我們的要求是擴容不能降低命中率。為達到該目的，我們把水平擴充套件，變為垂直擴充套件，即通過多層cache解決擴容而同時不降低命中率的問題。
另外乙個好處是，新加入的cache層無需預熱，當線上服務出現意外高峰時，可以立刻投入使用。
擴容問題之二：memcache集群具備水平擴充套件性嗎？
隨著快取層的增長，資料被分散到更多快取伺服器上，獲取相同資訊需要傳送的網路包的數量也在不斷增長。比如，只有一台快取伺服器時，由於作業系統網路層傳送緩衝區的設計，get 100個key的資料可以在乙個ip packet中傳輸，結果可以也可以在乙個ip packet中獲取。但當有100臺快取伺服器時，獲取100個key的資料就有需要向100臺伺服器傳送100個ip packet（假設100個資料均勻的分布在100臺物理機上），相應的核心中斷也顯著增加。
因此，我不認為memcache集群在這個概念下具備水平擴充套件能力。但通常我們通過劃分不同資料大小的快取池控制memcache集群的大小，而且隨著96g或以上大記憶體伺服器的廣泛使用。即便在微博這個場景下，12臺伺服器一組的快取就已經非常大規模的了。
3. memcache其實還能更快？
如果你追求極致的memcache訪問速度，可以登入上你的memcache伺服器，檢查一下cpu使用情況。我找了一台線上服務，情況如下：
顯然cpu7的系統使用率比其他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 作業系統，使用broadcom 5709網絡卡晶元的伺服器存在cpu軟中斷不均衡，只有1個cpu處理軟中斷。
解決方法可以是公升級核心，不過也有朋友說沒用，需要通過vip繫結2塊網絡卡的方式解決，具體方案見：
通過對比核心支援4個佇列的伺服器（最多只能利用到4核，無法在硬體驅動層直接配置成更多佇列），只分配乙個cpu的memcache伺服器在大壓力下可能會慢1~2ms。
關於新架構的思考
1.對request和session的深層封裝真的有實際意義嗎?2.如果request封裝的真的很厚實,那麼,我們必須要保證的,控制器在完全屏棄request以後,能夠方便獲取request中的物件.方便訪問session中的物件,這點,在分層體系架構的設計上是非常重要的.3.對於bo和持久層,以及...
企業架構思考
roger sessions是objectwatch的cto。在紐西蘭teched2009的session arc203 services and complexity 分享了自己關於企業架構的獨特觀點，非常令人印象深刻，無疑可以給大家帶來很多思考。roger認為ea企業架構可以實現的所謂 立即的 ...
程式架構思考
可以將程式分為3部分，乙個是邏輯 logic 乙個是控制 control 資料結構 data structures 邏輯是用來解決實際問題的，也就是具體問題的實現。控制是將多個邏輯組合起來工作的方式，即邏輯組合的策略。資料結構是計算機中儲存 組織資料的方式。程式執行的效率取決於這三者的組合結果。如果...