沒聽過換樂網？沒錯，它在我的電腦裡
在專案中，redis主要用作快取。而在作為快取，意義最大的是快取計算結果，因為有些計算是乙個很耗時間和資源的過程，而計算的結果不會經常改變，這時使用redis將結果快取起來就非常有用。
在專案中有個需求：顯示乙個類目下的所有商品，分類可以是最終類目，也可以不是。比如，顯示「生活用品」類目下的商品，需要顯示出「洗漱用品」，「餐具」，「雨傘」等等所有子類目下的商品。
這個操作近似於遍歷樹，有乙個遞迴查詢的過程：找到「洗漱用品」等直接子類，如果這些子類不是最終類目，繼續向下查詢。
這個計算過程很耗資源，而且經常需要用到其計算結果，所以，放在redis裡面快取起來：
對於快取的更新，想到三種方案：
（1）每次修改資料庫的相關資料時，順便更新redis裡面的資料。
（2）設定快取的過期時間，這樣在某些情況下可以達到自動更新快取的效果，但不是什麼情況下都可用，一般如果快取只用作顯示的話，這樣做也無妨。
（3）或者設定乙個更改標記，每次修改了相關資料就把更改這個標記。這個標記的管理參看下部分「key管理」
快取物件一般快取：
（1）使用頻率很高的物件，比如當前使用者，幾乎每個頁面都要使用到。
（2）臨時物件。比如驗證碼。
專案中有個需求：使用者可以使用簡訊驗證碼登入，驗證碼60s內只能發一次，一天內同乙個使用者最多傳送20條，驗證碼5分鐘內輸入有效。
這裡，要達到限制每個使用者傳送條數的效果，就必須記錄使用者傳送的次數和ip位址，這種資料用乙個表或文件來存顯得太笨重了，而放在redis中則十分方便。
在專案中，儲存物件一般使用json，應為物件是單一的，而且儲存為字串的話可以設定過期時間。
作為計數器則redis是用得很多的乙個方面。比如說上面的發簡訊驗證碼的需求，可以用乙個計數器來限制使用者60s內只能發一條簡訊驗證碼，用另外乙個計數器來限制使用者驗證碼2分鐘內有效。
根據某一條原則：key應該集中管理。
集中管理的好處就是使用方便，結果一致，當需要某個key時，直接找管理者拿就好了，不管呼叫多少次，得到的key的值都是一樣的。總之，key統一管理是乙個不錯的選擇。
在專案中，對於使用者儲存在redis中的資料，都定義乙個key helper類來管理：
商品類目的redis快取結果key管理者：
public
class
redisgoodsclassentity
}
package com.huanle.model.session;
public
class
redisuserentity
/** 獲得使用者訂閱在redis的快取的key
*@param ip
*@return 使用者訂閱在redis的快取的key
*/public
static string getsubscritionkeybyaccount(string account)
}
博應用官網結構分析
是由很多網頁組成的，通過不同網頁板塊的結合而緊密聯絡為一體，有好的 結構分布才能讓使用者有更好的使用體驗，同時增加網際網路友好度，那麼下面給大家介紹下博應用官網 架構 1 寬屏與窄屏的顯示 其實對於 寬窄屏顯示的設定眾說紛紜，有的人說寬屏好有的人說窄屏好，其實寬窄屏顯示各有優勢，窄屏顯示 即 居中，...
《Redis實戰》一2 5 網頁分析
可以從使用者的訪問 互動和購買行為中收集到有價值的資訊。例如，如果我們只想關注那些瀏覽量最高的頁面，那麼我們可以嘗試修改頁面的格局 配色甚至是頁面上展示的其他鏈結。每乙個修改嘗試都能改變使用者對乙個頁面或者後續頁面的體驗，或好或壞，甚至還能影響使用者的購買行為。前面的2.1節和2.2節中介紹了如何記...
DB，Cache和Redis應用場景分析
資料儲存同時用到了db mysql cache memcache redis。其實最開始架構設計的時候是準備用mongodb的，由於學習成本太高，最終選擇放棄了，採用了比較保守的方案。這款產品做了將近一年，涵蓋了手機客戶端 ios,android web 剛上線不久 現在差不多有10多w使用者，光 ...