採用的當然是redis的list資料結構，而實際上nosqlfan之前還討論過採用sorted sets結構來做帶權重的訊息佇列的方法。
實際上還是乙個佇列，多個端點將日誌資訊寫入redis，然後乙個worker統一將所有日誌寫到磁碟。
比如將每個人的好友存在乙個集合（set）中，這樣求兩個人的共同好友的操作，可能就只需要用求交集命令即可。
用來做持久化儲存的快取，和memcached一樣，可以在持久化儲存獲取成功後將資料在redis中進行快取，我們知道，redis的效能優於memcached。
用作持久儲存的時候，可以選擇定時flush成rdb或開啟aof日誌的做法，具體選擇哪一種，可以根據業務上可接受的資料可靠程度而定。
乙個提醒，在bump早期，曾將redis和mongodb放在同一臺機器，而由於redis的單執行緒，常由於mongodb對於cpu或磁碟io的占用而導致其某個過程（比如malloc或者寫aof）執行時間過長，從而進一步導致其所有操作被阻塞並延遲，所以盡量不要將其用於可能被大量占用cpu或磁碟io，導致redis工作執行緒被阻塞的場合。
Redis使用經驗
首先，快取的物件有三種 1 資料庫中單條的的資料 以表名跟id作為key永久儲存到redis 在有更新的地方都要更新快取 不適用於需要經常更新的資料 2 對於一些不分頁，不需要實時 需要多表查詢 的列表，我們可以將列表結果快取到redis中，設定一定快取時間作為該資料的存活時間。用獲取該列表的方法名...
Redis使用經驗
首先，快取的物件有三種 1 資料庫中單條的的資料 以表名跟id作為key永久儲存到redis 在有更新的地方都要更新快取 不適用於需要經常更新的資料 2 對於一些不分頁，不需要實時 需要多表查詢 的列表，我們可以將列表結果快取到redis中，設定一定快取時間作為該資料的存活時間。用獲取該列表的方法名...
hash型別的應用場景 Redis實戰經驗
hash型別是乙個string型別的field和value的對映表，每個 hash 可以儲存 232 1 鍵值對 40多億 hash型別主要有以下應用場景。1.購物車 以使用者id為key，商品id為field，商品數量為value，恰好構成了購物車的3個要素，如下圖所示。2.儲存物件 hash型別...