1.冷熱數(shù)據(jù)分離，不要將所有數(shù)據(jù)全部都放到Redis中

雖然Redis支持持久化，但是Redis的數(shù)據(jù)存儲全部都是在內(nèi)存中的，成本昂貴。建議根據(jù)業(yè)務只將高頻熱數(shù)據(jù)存儲到Redis中【QPS大于5000】，對于低頻冷數(shù)據(jù)可以使用MySQL/ElasticSearch/MongoDB等基于磁盤的存儲方式，不僅節(jié)省內(nèi)存成本，而且數(shù)據(jù)量小在操作時速度更快、效率更高！

2.不同的業(yè)務數(shù)據(jù)要分開存儲
不要將不相關(guān)的業(yè)務數(shù)據(jù)都放到一個Redis實例中，建議新業(yè)務申請新的單獨實例。因為Redis為單線程處理，獨立存儲會減少不同業(yè)務相互操作的影響，提高請求響應速度；同時也避免單個實例內(nèi)存數(shù)據(jù)量膨脹過大，在出現(xiàn)異常情況時可以更快恢復服務！

3.存儲的Key一定要設(shè)置超時時間
如果應用將Redis定位為緩存Cache使用，對于存放的Key一定要設(shè)置超時時間！因為若不設(shè)置，這些Key會一直占用內(nèi)存不釋放，造成極大的浪費，而且隨著時間的推移會導致內(nèi)存占用越來越大，直到達到服務器內(nèi)存上限！另外Key的超時長短要根據(jù)業(yè)務綜合評估，而不是越長越好！

4.對于必須要存儲的大文本數(shù)據(jù)一定要壓縮后存儲
對于大文本【超過500字節(jié)】寫入到Redis時，一定要壓縮后存儲！大文本數(shù)據(jù)存入Redis，除了帶來極大的內(nèi)存占用外，在訪問量高時，很容易就會將網(wǎng)卡流量占滿，進而造成整個服務器上的所有服務不可用，并引發(fā)雪崩效應，造成各個系統(tǒng)癱瘓！

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

6.可靠的消息隊列服務
Redis List經(jīng)常被用于消息隊列服務。假設(shè)消費者程序在從隊列中取出消息后立刻崩潰，但由于該消息已經(jīng)被取出且沒有被正常處理，那么可以認為該消息已經(jīng)丟失，由此可能會導致業(yè)務數(shù)據(jù)丟失，或業(yè)務狀態(tài)不一致等現(xiàn)象發(fā)生。為了避免這種情況，Redis提供了RPOPLPUSH命令，消費者程序會原子性的從主消息隊列中取出消息并將其插入到備份隊列中，直到消費者程序完成正常的處理邏輯后再將該消息從備份隊列中刪除。同時還可以提供一個守護進程，當發(fā)現(xiàn)備份隊列中的消息過期時，可以重新將其再放回到主消息隊列中，以便其它的消費者程序繼續(xù)處理。

7.謹慎全量操作Hash、Set等集合結(jié)構(gòu)
在使用HASH結(jié)構(gòu)存儲對象屬性時，開始只有有限的十幾個field，往往使用HGETALL獲取所有成員，效率也很高，但是隨著業(yè)務發(fā)展，會將field擴張到上百個甚至幾百個，此時還使用HGETALL會出現(xiàn)效率急劇下降、網(wǎng)卡頻繁打滿等問題【時間復雜度O(N)】,此時建議根據(jù)業(yè)務拆分為多個Hash結(jié)構(gòu)；或者如果大部分都是獲取所有屬性的操作,可以將所有屬性序列化為一個STRING類型存儲！同樣在使用SMEMBERS操作SET結(jié)構(gòu)類型時也是相同的情況！

8.根據(jù)業(yè)務場景合理使用不同的數(shù)據(jù)結(jié)構(gòu)類型
目前Redis支持的數(shù)據(jù)庫結(jié)構(gòu)類型較多：字符串（String），哈希（Hash），列表（List），集合（Set），有序集合（Sorted Set）, Bitmap, HyperLogLog和地理空間索引（geospatial）等,需要根據(jù)業(yè)務場景選擇合適的類型，常見的如：String可以用作普通的K-V、計數(shù)類；Hash可以用作對象如商品、經(jīng)紀人等，包含較多屬性的信息；List可以用作消息隊列、粉絲/關(guān)注列表等；Set可以用于推薦；Sorted Set可以用于排行榜等！

9.命名規(guī)范
redis的key命名盡量簡單明確，容易閱讀理解，如：系統(tǒng)名+業(yè)務名+業(yè)務數(shù)據(jù)+其他

10.線上禁止使用monitor命令
禁止生產(chǎn)環(huán)境使用monitor命令，monitor命令在高并發(fā)條件下，會存在內(nèi)存暴增和影響Redis性能的隱患

11.禁止大string

核心集群禁用1mb的string大key(雖然redis支持512MB大小的string)，如果1mb的key每秒重復寫入10次，就會導致寫入網(wǎng)絡(luò)IO達10MB;

12.redis容量
單實例的內(nèi)存大小不建議過大，建議在10~20GB以內(nèi)。

redis實例包含的鍵個數(shù)建議控制在1kw內(nèi)，單實例鍵個數(shù)過大，可能導致過期鍵的回收不及時。

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

https://www.quora.com/Redis/What-are-5-mistakes-to-avoid-when-using-Redis

總結(jié)

以上是生活随笔為你收集整理的Redis开发规范的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。