Redis開發建議

Redis開發建議

最後附上Redis的一些開發規範和建議：

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

雖然Redis支持持久化，可是Redis的數據存儲所有都是在內存中的，成本昂貴。建議根據業務只將高頻熱數據存儲到Redis中【QPS大於5000】，對於低頻冷數據可使用MySQL/ElasticSearch/MongoDB等基於磁盤的存儲方式，不只節省內存成本，並且數據量小在操做時速度更快、效率更高！

2.不一樣的業務數據要分開存儲

不要將不相關的業務數據都放到一個Redis實例中，建議新業務申請新的單獨實例。由於Redis爲單線程處理，獨立存儲會減小不一樣業務相互操做的影響，提升請求響應速度；同時也避免單個實例內存數據量膨脹過大，在出現異常狀況時能夠更快恢復服務！ 在實際的使用過程當中，redis最大的瓶頸通常是CPU，因爲它是單線程做業因此很容易跑滿一個邏輯CPU，可使用redis代理或者是分佈式方案來提高redis的CPU使用率。

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支持多個數據庫（默認32個，能夠配置更多），可是除了默認的0號庫之外，其它的都須要經過一個額外請求才能使用。因此用前綴做爲命名空間可能會更明智一點。

另外，在使用前綴做爲命名空間區隔不一樣key的時候，最好在程序中使用全局配置來實現，直接在代碼裏寫前綴的作法要嚴格避免，這樣可維護性實在太差了。

如：系統名:業務名:業務數據:其餘

可是注意，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內，單實例鍵個數過大，可能致使過時鍵的回收不及時。

13 可靠性

須要定時監控redis的健康狀況：使用各類redis健康監控工具，實在不行能夠定時返回redis 的 info信息。

客戶端鏈接儘可能使用鏈接池（長連接和自動重連）