使用場景一：高頻率使用但不頻繁更新的業務數據。由于不頻繁更新，所以可以在系統啟動時，從數據庫中加載，放入redis。如果更新，需重啟服務，當然這比較笨。更好的做法下面會列出。
使用場景二：高頻率使用更新還算頻繁的業務數據。由于有一定頻率的更新，所以可以在用戶訪問時，查詢緩存，如果沒有值，則從數據庫中加載入redis，并設置過期時間。這樣，過期時間內的訪問就都走緩存了。這種策略也有問題，就是大并發訪問時，容易造成數據庫瞬間高并發讀，如果程序再寫的爛點，查詢語句再復雜點，那可能造成數據庫死鎖。更好的辦法，下面列出。
使用場景三：高頻率使用高頻率更新的業務數據。這種數據就需要在寫入數據庫的同時放入緩存，不設置過期時間，這樣用戶每次訪問都走緩存。為了保證數據的一致，還有數據對內存的占用，還需要有一些額外的策略。
對于場景一：更好的做法是在系統啟動的同時，利用redis的pub/sub功能，啟動一個監聽通道。當數據發生更新時，往通道publish一個消息，系統接收到消息后，重新從數據庫中加載數據，放入緩存。這樣系統實現了無中斷的更新緩存。
對于場景二：更好的做法是單獨啟動一個定時任務，把定時任務看做是一個用戶，他每隔一段時間從數據庫中讀取數據，然后放入緩存。而前臺用戶訪問的始終是緩存數據，不會觸發數據庫的相關操作。這個策略也可以用在場景一中。
當然，使用memcached也可以實現類似的功能，但是我更喜歡用redis，基于他強大的性能和數據結構，可以實現多種復雜的業務需求。