1.Counting（計數(shù)）
可以預見的是荆姆，有很多同學認為把計數(shù)全部存在內(nèi)存中成本非常高浑厚，我在這里用個圖表來表達下我的觀點：
很多情況大家都會設想純使用內(nèi)存的方案會很有很高成本游添，但實際情況往往會有一些不一樣：
COST癞志，對于有一定吞吐需求的應用來說抖锥，肯定會單獨申請DB蜂莉、Cache資源，很多擔心DB寫入性能的同學還會主動將DB更新記入異步隊列欣硼，而這三塊的資源的利用率一般都不會太高题翰。資源算下來，你驚異的發(fā)現(xiàn)：反而純內(nèi)存的方案會更精簡！
KISS原則豹障，這對于開發(fā)是非常友好的冯事，我只需要建立一套連接池，不用擔心數(shù)據(jù)一致性的維護血公，不用維護異步隊列昵仅。
Cache穿透風險，如果后端使用DB累魔，肯定不會提供很高的吞吐能力摔笤，cache宕機如果沒有妥善處理，那就悲劇了垦写。
大多數(shù)的起始存儲需求吕世，容量較小。
2.Reverse cache（反向cache）
面對微博常常出現(xiàn)的熱點梯投，如最近出現(xiàn)了較為火爆的短鏈命辖，短時間有數(shù)以萬計的人點擊、跳轉(zhuǎn)分蓖，而這里會常常涌現(xiàn)一些需求尔艇，比如我們向快速在跳轉(zhuǎn)時判定用戶等級，是否有一些賬號綁定么鹤，性別愛好什么的漓帚，已給其展示不同的內(nèi)容或者信息。
普通采用memcache+Mysql的解決方案午磁，當調(diào)用id合法的情況下尝抖，可支撐較大的吞吐。但當調(diào)用id不可控迅皇，有較多垃圾用戶調(diào)用時昧辽，由于memcache未有命中，會大量的穿透至Mysql服務器登颓，瞬間造成連接數(shù)瘋長搅荞，整體吞吐量降低，響應時間變慢框咙。
這里我們可以用redis記錄全量的用戶判定信息咕痛，如string key:uid int:type，做一次反向的cache喇嘱，當用戶在redis快速獲取自己等級等信息后茉贡，再去Mc+Mysql層去獲取全量信息。如圖：
當然這也不是最優(yōu)化的場景者铜，如用Redis做bloomfilter腔丧，可能更加省用內(nèi)存放椰。
3.Top 10 list
產(chǎn)品運營總會讓你展示最近、最熱愉粤、點擊率最高砾医、活躍度最高等等條件的top list。很多更新較頻繁的列表如果使用MC+MySQL維護的話緩存失效的可能性會比較大衣厘，鑒于占用內(nèi)存較小的情況如蚜，使用Redis做存儲也是相當不錯的。
4.Last Index
用戶最近訪問記錄也是redis list的很好應用場景影暴，lpush lpop自動過期老的登陸記錄错邦，對于開發(fā)來說還是非常友好的。
5.Relation List/Message Queue
這里把兩個功能放在最后坤检，因為這兩個功能在現(xiàn)實問題當中遇到了一些困難，但在一定階段也確實解決了我們很多的問題期吓，故在這里只做說明早歇。
Message Queue就是通過list的lpop及l(fā)push接口進行隊列的寫入和消費，由于本身性能較好也能解決大部分問題讨勤。
6.Fast transaction with Lua
Redis 的Lua的功能擴展實際給Redis帶來了更多的應用場景箭跳，你可以編寫若干command組合作為一個小型的非阻塞事務或者更新邏輯，如：在收到message推送時潭千，同時1.給自己的增加一個未讀的對話 2.給自己的私信增加一個未讀消息 3.最后給發(fā)送人回執(zhí)一個完成推送消息谱姓，這一層邏輯完全可以在Redis Server端實現(xiàn)。
但是刨晴，需要注意的是Redis會將lua script的全部內(nèi)容記錄在aof和傳送給slave屉来，這也將是對磁盤，網(wǎng)卡一個不小的開銷狈癞。
7.Instead of Memcache
很多測試和應用均已證明茄靠，
在性能方面Redis并沒有落后memcache多少，而單線程的模型給Redis反而帶來了很強的擴展性蝶桶。
在很多場景下慨绳，Redis對同一份數(shù)據(jù)的內(nèi)存開銷是小于memcache的slab分配的。
Redis提供的數(shù)據(jù)同步功能真竖，其實是對cache的一個強有力功能擴展脐雪。
