隨著應(yīng)用對(duì)高性能需求的增加，NoSQL逐漸在各大名企的系統(tǒng)架構(gòu)中生根發(fā)芽。這里我們將為大家分享社交巨頭新浪微博、傳媒巨頭Viacom及圖片分享領(lǐng)域佼佼者Pinterest帶來的Redis實(shí)踐，首先我們看新浪微博 @啟盼cobain的Redis實(shí)戰(zhàn)經(jīng)驗(yàn)分享：
新浪微博：史上最大的Redis集群
Tape is Dead，Disk is Tape，F(xiàn)lash is Disk，RAM Locality is King. — Jim Gray
Redis不是比較成熟的memcache或者M(jìn)ysql的替代品，是對(duì)于大型互聯(lián)網(wǎng)類應(yīng)用在架構(gòu)上很好的補(bǔ)充?，F(xiàn)在有越來越多的應(yīng)用也在紛紛基于Redis做架構(gòu)的改造。首先簡(jiǎn)單公布一下Redis平臺(tái)實(shí)際情況：
- 2200+億 commands/day 5000億Read/day 500億Write/day
- 18TB+ Memory
- 500+ Servers in 6 IDC 2000+instances
應(yīng)該是國(guó)內(nèi)外比較大的Redis使用平臺(tái)，今天主要從應(yīng)用角度談?wù)凴edis服務(wù)平臺(tái)。
Redis使用場(chǎng)景
1.Counting（計(jì)數(shù)）
計(jì)數(shù)的應(yīng)用在另外一篇文章里較詳細(xì)的描述，計(jì)數(shù)場(chǎng)景的優(yōu)化 http://www.xdata.me/?p=262這里就不多加描述了。
可以預(yù)見的是，有很多同學(xué)認(rèn)為把計(jì)數(shù)全部存在內(nèi)存中成本非常高，我在這里用個(gè)圖表來表達(dá)下我的觀點(diǎn)：
很多情況大家都會(huì)設(shè)想純使用內(nèi)存的方案會(huì)很有很高成本，但實(shí)際情況往往會(huì)有一些不一樣：
- COST，對(duì)于有一定吞吐需求的應(yīng)用來說，肯定會(huì)單獨(dú)申請(qǐng)DB、Cache資源，很多擔(dān)心DB寫入性能的同學(xué)還會(huì)主動(dòng)將DB更新記入異步隊(duì)列，而這三塊的資源的利用率一般都不會(huì)太高。資源算下來，你驚異的發(fā)現(xiàn)：反而純內(nèi)存的方案會(huì)更精簡(jiǎn)！
- KISS原則，這對(duì)于開發(fā)是非常友好的，我只需要建立一套連接池，不用擔(dān)心數(shù)據(jù)一致性的維護(hù)，不用維護(hù)異步隊(duì)列。
- Cache穿透風(fēng)險(xiǎn)，如果后端使用DB，肯定不會(huì)提供很高的吞吐能力，cache宕機(jī)如果沒有妥善處理，那就悲劇了。
- 大多數(shù)的起始存儲(chǔ)需求，容量較小。
2.Reverse cache（反向cache）
面對(duì)微博常常出現(xiàn)的熱點(diǎn)，如最近出現(xiàn)了較為火爆的短鏈，短時(shí)間有數(shù)以萬計(jì)的人點(diǎn)擊、跳轉(zhuǎn)，而這里會(huì)常常涌現(xiàn)一些需求，比如我們向快速在跳轉(zhuǎn)時(shí)判定用戶等級(jí)，是否有一些賬號(hào)綁定，性別愛好什么的，已給其展示不同的內(nèi)容或者信息。
普通采用memcache+Mysql的解決方案，當(dāng)調(diào)用id合法的情況下，可支撐較大的吞吐。但當(dāng)調(diào)用id不可控，有較多垃圾用戶調(diào)用時(shí)，由于memcache未有命中，會(huì)大量的穿透至Mysql服務(wù)器，瞬間造成連接數(shù)瘋長(zhǎng)，整體吞吐量降低，響應(yīng)時(shí)間變慢。
這里我們可以用redis記錄全量的用戶判定信息，如string key:uid int:type，做一次反向的cache，當(dāng)用戶在redis快速獲取自己等級(jí)等信息后，再去Mc+Mysql層去獲取全量信息。如圖：
當(dāng)然這也不是最優(yōu)化的場(chǎng)景，如用Redis做bloomfilter，可能更加省用內(nèi)存。