Redis 在 SNS 類應用中的最佳實踐有哪些？

01-16

1. 消息隊列（通知類、延遲更新類）

2. 熱點數據的實時緩存（比如feed，資料庫、緩存同時寫）

3. 熱點列表數據緩存（首頁、熱門話題等）

4. counter（計數器，大多是用緩存實現的）

5. 記日誌最好不要用redis，用mongodb比較適合。

聽聞新浪微博用來做計數，規模在國內可能是最大的～

1.用key-hash保存用戶關係。優點快速獲取用戶的關注以及粉絲數，也可以通過求交屬性快速獲取兩個人的共同關注，共同粉絲；缺點：單線程單核計算，一次拿過多的key可能導致cpu到100%從而死機，共同關注一般ok，基本每個人關注用戶數目差不多，共同粉絲不太適合微博這種媒體性質有大v的社交產品。

2. key-list，可以做隊列，也可以作為用戶的feeds流，在推模式下，來一個feed，list追加即可，也可以比較容易的截斷設計feeds數目上限（媒體性質的社交不適合，要推送的太多）

3. key-sorted_set，可以認為是一個帶有分數權重的優先順序隊列，在feeds流下可以用這個做自定義的排序，只要塞入feed時加入合適分數；還有做一個實時的排行榜也很容易，可以理解為一個大頂堆。缺點：很吃類存

4. key-string，有點像mc，但是這個string可以變，可以追加。

5. key-所有都可以根據業務和數據結構作為緩存

海量 and 高性能應用;

參考:http://antirez.com/post/take-advantage-of-redis-adding-it-to-your-stack.html?utm_source=feedburnerutm_medium=feedutm_campaign=Feed%3A+antirez+%28antirez+weblog%29

俺一般用Redis做緩存、消息隊列，詳情請看《在談Redis應用場景》

搬運工
:

微博關係服務與Redis的故事

Redis計數在新浪微博的應用

節約內存：Instagram的Redis實踐

Bump的Redis應用經驗

Facebook用memcached改的tao，最近我們也需要一個tao這樣的東西，既然沒有歷史包袱，那就拿redis來改吧。

好處是networking的multiplexing已經弄好了，直接掛上mariadb的nonblocking api就可以整合到redis的事件循環里了。壞處是畢竟整個redis的設計都是單線程的模式，如果要支持多線程的話，就得對redis自身代碼做比較多的改動，不利於以後和上游版本的合併。於是就還是維持單線程模式，所以寫代碼得注意時間複雜度，避免降低整體吞吐以及增加事件處理的時延。

其它的好處就很多了，各種語言的api binding遍地都是，只要支持發raw command就相當於有了這個語言的客戶端了。可以用現有的replication機制來實現多層緩衝，即便要實現facebook tao的leader follower的話，也可以比較輕鬆的實現。還有內嵌的一堆數據結構也可以直接拿來用，雖然寫起來也不麻煩，但是畢竟重新發明輪子怎麼也趕不上一個有那麼多人幫著優化的輪子。

改的時候還發現了一個redis的一個buffer underflow bug，不過等想要去提交pull的時候發現上游已經修掉了，不得不感慨有開源真好，大家拾柴火焰高啊。

排序哈哈

實時性要求高，寫頻繁的應用場合，比如

統計系統，推送服務，消息隊列

Session

計數器

消息隊列

feeds,關注,timeline等列索引緩存

我用它做消息隊列...

TOP N話題

消息隊列

量不大的情況下，可以用來存多終端的漫遊消息，性價比非常高。可以根據活躍用戶數和消息量的統計分布，動態調整單用戶的會話數上限和單會話的消息條數上限。數據不需要持久化，當然在內存里直接放消息內容也要注意安全。