在Feed系統(tǒng)中，有簡單數(shù)據(jù)類型的緩存，有集合類數(shù)據(jù)的。還有一些個性業(yè)務的緩存。比如大量的計數(shù)器場景，存在性判斷場景等。微博解決存在性判斷業(yè)務的緩存層叫EXISTENCE 緩存層，解決計算器場景的緩存叫COUNTER緩存。

EXISTENCE 緩存層主要用于緩存各種存在性判斷的業(yè)務，諸如是否已贊（liked）、是否已閱讀（readed）這類需求。

Feed系統(tǒng)內(nèi)部有大量的計數(shù)場景，如用戶維度有關(guān)注數(shù)、粉絲數(shù)、feed發(fā)表數(shù)，feed維度有轉(zhuǎn)發(fā)數(shù)、評論數(shù)、贊數(shù)以及閱讀數(shù)等。前面提到，按照傳統(tǒng)Redis、Memcached計數(shù)緩存方案，單單存每日新增的十億級的計數(shù)，就需要新占用百G級的內(nèi)存，成本開銷巨大。因此微博開發(fā)了計數(shù)服務組件CounterService。下面以計數(shù)場景來管中窺豹。

提出問題

對于計數(shù)業(yè)務，經(jīng)典的構(gòu)建模型有兩種：1 db+cache模式，全量計數(shù)存在db，熱數(shù)據(jù)通過cache加速；2全量存在Redis中。方案1 通用成熟，但對于一致性要求較高的計數(shù)服務，以及在海量數(shù)據(jù)和高并發(fā)訪問場景下，支持不夠友好，運維成本和硬件成本較高，微博上線初期曾使用該方案，在Redis面世后很快用新方案代替。方案2基于Redis的計數(shù)接口INCR、DECR，能很方便的實現(xiàn)通用的計數(shù)緩存模型，再通過hash分表，master-slave部署方式，可以實現(xiàn)一個中小規(guī)模的計數(shù)服務。

但在面對千億級的歷史海量計數(shù)以及每天十億級的新增計數(shù)，直接使用Redis的計數(shù)模型存在嚴重的成本和性能問題。首先Redis計數(shù)作為通用的全內(nèi)存計數(shù)模型，內(nèi)存效率不高。存儲一個key為8字節(jié)（long型id）、value為4字節(jié)的計數(shù)，Redis至少需要耗費65字節(jié)。1000億計數(shù)需要100G*65=6.5T以上的內(nèi)存，算上一個master配3個slave的開銷，總共需要26T以上的內(nèi)存，按單機內(nèi)存96G計算，扣掉Redis其他內(nèi)存管理開銷、系統(tǒng)占用，需要300-400臺機器。如果算上多機房，需要的機器數(shù)會更多。其次Redis計數(shù)模型的獲取性能不高。一條微博至少需要3個計數(shù)查詢，單次feed請求如果包含15條微博，僅僅微博計數(shù)就需要45個計數(shù)查詢。

解決問題

在Feed系統(tǒng)的計數(shù)場景，單條feed的各種計數(shù)都有相同的key（即微博id），可以把這些計數(shù)存儲在一起，就能節(jié)省大量的key的存儲空間，讓1000億計數(shù)變成了330億條記錄；近一半的微博沒有轉(zhuǎn)、評論、贊，拋棄db+cache的方案，改用全量存儲的方案，對于沒有計數(shù)為0的微博不再存儲，如果查不到就返回0，這樣330億條記錄只需要存160億條記錄。然后又對存儲結(jié)構(gòu)做了進一步優(yōu)化，三個計數(shù)和key一起一共只需要8+4*3=20字節(jié)。總共只需要16G*20=320G，算上1主3從，總共也就只需要1.28T，只需要15臺左右機器即可。同時進一步通過對CounterService增加SSD擴展支持，按table滾動，老數(shù)據(jù)落在ssd，新數(shù)據(jù)、熱數(shù)據(jù)在內(nèi)存，1.28T的容量幾乎可以用單臺機器來承載（當然考慮訪問性能、可用性，還是需要hash到多個緩存節(jié)點，并添加主從結(jié)構(gòu)）。

計數(shù)器組件的架構(gòu)如圖13-14，主要特性如下：

1）  內(nèi)存優(yōu)化：通過預先分配的內(nèi)存數(shù)組Table存儲計數(shù)，并且采用 double hash 解決沖突，避免Redis 實現(xiàn)中的大量指針開銷。

2）  Schema支持多列:一個feed id對應的多個計數(shù)可以作為一條計數(shù)記錄，還支持動態(tài)增減計數(shù)列，每列的計數(shù)內(nèi)存使用精簡到bit；

3）  冷熱數(shù)據(jù)分離，根據(jù)時間維度，近期的熱數(shù)據(jù)放在內(nèi)存，之前的冷數(shù)據(jù)放在磁盤，降低機器成本；

4）  LRU緩存：之前的冷數(shù)據(jù)如果被頻繁訪問則放到LRU緩存進行加速；

5）  異步IO線程訪問冷數(shù)據(jù)：冷數(shù)據(jù)的加載不影響服務的整體性能。

圖 13-14 基于Redis擴展后的計數(shù)器存儲架構(gòu)

通過上述的擴展，內(nèi)存占用降為之前的5-10%以下，同時一條feed的評論/贊等多個計數(shù)、一個用戶的粉絲/關(guān)注/微博等多個計數(shù)都可以一次性獲取，讀取性能大幅提升，基本徹底解決了計數(shù)業(yè)務的成本及性能問題。