1.冷熱資料分離，不要將所有資料全部都放到Redis中

雖然Redis支援持久化，但是Redis的資料儲存全部都是在記憶體中的，成本昂貴。建議根據業務只將高頻熱資料儲存到Redis中【QPS大於5000】，對於低頻冷資料可以使用MySQL/ElasticSearch/MongoDB等基於磁碟的儲存方式，不僅節省記憶體成本，而且資料量小在操作時速度更快、效率更高！

2.不同的業務資料要分開儲存
不要將不相關的業務資料都放到一個Redis例項中，建議新業務申請新的單獨例項。因為Redis為單執行緒處理，獨立儲存會減少不同業務相互操作的影響，提高請求響應速度；同時也避免單個例項記憶體資料量膨脹過大，在出現異常情況時可以更快恢復服務！

3.儲存的Key一定要設定超時時間

如果應用將Redis定位為快取Cache使用，對於存放的Key一定要設定超時時間！因為若不設定，這些Key會一直佔用記憶體不釋放，造成極大的浪費，而且隨著時間的推移會導致記憶體佔用越來越大，直到達到伺服器記憶體上限！另外Key的超時長短要根據業務綜合評估，而不是越長越好！

4.對於必須要儲存的大文字資料一定要壓縮後儲存
對於大文字【超過500位元組】寫入到Redis時，一定要壓縮後儲存！大文字資料存入Redis，除了帶來極大的記憶體佔用外，在訪問量高時，很容易就會將網絡卡流量佔滿，進而造成整個伺服器上的所有服務不可用，並引發雪崩效應，造成各個系統癱瘓！

5.線上Redis禁止使用Keys正則匹配操作

Redis是單執行緒處理，在線上KEY數量較多時，操作效率極低【時間複雜度為O(N)】，該命令一旦執行會嚴重阻塞線上其它命令的正常請求，而且在高QPS情況下會直接造成Redis服務崩潰！如果有類似需求，請使用scan命令代替！

6.可靠的訊息佇列服務
Redis List經常被用於訊息佇列服務。假設消費者程式在從佇列中取出訊息後立刻崩潰，但由於該訊息已經被取出且沒有被正常處理，那麼可以認為該訊息已經丟失，由此可能會導致業務資料丟失，或業務狀態不一致等現象發生。為了避免這種情況，Redis提供了RPOPLPUSH命令，消費者程式會原子性的從主訊息佇列中取出訊息並將其插入到備份佇列中，直到消費者程式完成正常的處理邏輯後再將該訊息從備份佇列中刪除。同時還可以提供一個守護程序，當發現備份佇列中的訊息過期時，可以重新將其再放回到主訊息佇列中，以便其它的消費者程式繼續處理。

7.謹慎全量操作Hash、Set等集合結構

在使用HASH結構儲存物件屬性時，開始只有有限的十幾個field，往往使用HGETALL獲取所有成員，效率也很高，但是隨著業務發展，會將field擴張到上百個甚至幾百個，此時還使用HGETALL會出現效率急劇下降、網絡卡頻繁打滿等問題【時間複雜度O(N)】,此時建議根據業務拆分為多個Hash結構；或者如果大部分都是獲取所有屬性的操作,可以將所有屬性序列化為一個STRING型別儲存！同樣在使用SMEMBERS操作SET結構型別時也是相同的情況！

8.根據業務場景合理使用不同的資料結構型別
目前Redis支援的資料庫結構型別較多：字串（String），雜湊（Hash），列表（List），集合（Set），有序集合（Sorted Set）, Bitmap, HyperLogLog和地理空間索引（geospatial）等,需要根據業務場景選擇合適的型別，常見的如：String可以用作普通的K-V、計數類；Hash可以用作物件如商品、經紀人等，包含較多屬性的資訊；List可以用作訊息佇列、粉絲/關注列表等；Set可以用於推薦；Sorted Set可以用於排行榜等！

9.命名規範
redis的key命名儘量簡單明確，容易閱讀理解，如：系統名+業務名+業務資料+其他

10.線上禁止使用monitor命令
禁止生產環境使用monitor命令，monitor命令在高併發條件下，會存在記憶體暴增和影響Redis效能的隱患

11.禁止大string

核心叢集禁用1mb的string大key(雖然redis支援512MB大小的string)，如果1mb的key每秒重複寫入10次，就會導致寫入網路IO達10MB; 

12.redis容量
單例項的記憶體大小不建議過大，建議在10~20GB以內。

redis例項包含的鍵個數建議控制在1kw內，單例項鍵個數過大，可能導致過期鍵的回收不及時。

參考文章
http://www.cnblogs.com/ae6623/p/6183714.html