2021-01-28：redis使用過程中的注意事項有哪些？

福哥答案2021-01-28：

[答案1：](https://italk.mashibing.com/question/detail/ques_00005101)

1.使用key值前綴來作命名空間

雖然說Redis支持多個數據庫（默認32個，可以配置更多），但是除了默認的0號庫以外，其它的都需要通過一個額外請求才能使用。所以用前綴作為命名空間可能會更明智一點。

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

2.創建一個類似 ”registry” 的key用于標記key使用情況

為了更好的管理你的key值的使用，比如哪一類key值是屬于哪個業務的，你通常會在內部wiki或者什么地方創建一個文檔，通過查詢這個文檔，我們能夠知道Redis中的key都是什么作用。

與之結合，一個推薦的做法是，在Redis里面保存一個registry值，這個值的名字可以類似于 key_registry 這樣的，這個key對應的value就是你文檔的位置，這樣我們在使用Redis的時候，就能通過直接查詢這個值獲取到當前Redis的使用情況了。

3.注意垃圾回收

Redis是一個提供持久化功能的內存數據庫，如果你不指定上面值的過期時間，并且也不進行定期的清理工作，那么你的Redis內存占用會越來越大，當有一天它超過了系統可用內存，那么swap上場，離性能陡降的時間就不遠了。所以在Redis中保存數據時，一定要預先考慮好數據的生命周期，這有很多方法可以實現。

比如你可以采用Redis自帶的過期時間為你的數據設定過期時間。但是自動過期有一個問題，很有可能導致你還有大量內存可用時，就讓key過期去釋放內存，或者是內存已經不足了key還沒有過期。

如果你想更精準的控制你的數據過期，你可以用一個ZSET來維護你的數據更新程度，你可以用時間戳作為score值，每次更新操作時更新一下score，這樣你就得到了一個按更新時間排序序列串，你可以輕松地找到最老的數據，并且從最老的數據開始進行刪除，一直刪除到你的空間足夠為止。

4.設計好你的Sharding機制

Redis目前并不支持Sharding，但是當你的數據量超過單機內存時，你不得不考慮Sharding的事（注意：Slave不是用來做Sharding操作的，只是數據的一個備份和讀寫分離而已）。

所以你可能需要考慮好數據量大了后的分片問題，比如你可以在只有一臺機器的時候就在程序上設定一致性hash機制，雖然剛開始所有數據都hash到一臺機器，但是當你機器越加越多的時候，你就只需要遷移少量的數據就能完成了。

5.不要有個錘子看哪都是釘子

當你使用Redis構建你的服務的時候，一定要記住，你只是找了一個合適的工具來實現你需要的功能。而不是說你在用Redis構建一個服務，這是很不同的，你把Redis當作你很多工具中的一個，只在合適使用的時候再使用它，在不合適的時候選擇其它的方法。

[答案2：](http://bbs.xiangxueketang.cn/question/1277)

緩存雪崩，緩存擊穿，緩存穿透，以及緩存數據和數據庫的一致性。

還有就是緩存key過期的問，合理使用避免頻繁和redis建立IO鏈接。

安全問題，禁用一些危險的命令比如 keys，通用端口最后做一下修改，之前好像暴露出過安全問題。

redis配置bind 理解偏差問題，bind的作用不是白名單不是允許哪些IP可以訪問。

[答案3：](https://blog.csdn.net/LMY413231718/article/details/95616756)

Redis功能強大，數據類型豐富，再快的系統，也經不住瘋狂的濫用。通過禁用部分高風險功能，并掛上開發的枷鎖，業務更能夠以簡潔、通用的思想去考慮問題，而不是綁定在某種實現上。

Redis根據不同的用途，會有不同的持久化策略和逐出策略，所以，在使用和申請 Redis 集群前，請明確是用來做緩存還是存儲。Redis的集群有主從和 cluster 兩種模式，各有優缺點。以下規范不區分集群模式，我們分別從使用場景和操作限制兩方面說明。

使用規范

1、冷熱數據區分

雖然 Redis支持持久化，但將所有數據存儲在 Redis 中，成本非常昂貴。建議將熱數據 (如 QPS超過 5k) 的數據加載到 Redis 中。低頻數據可存儲在 Mysql、 ElasticSearch中。

2、業務數據分離

不要將不相關的數據業務都放到一個 Redis中。一方面避免業務相互影響，另一方面避免單實例膨脹，并能在故障時降低影響面，快速恢復。

3、消息大小限制

由于 Redis 是單線程服務，消息過大會阻塞并拖慢其他操作。保持消息內容在 1KB 以下是個好的習慣。嚴禁超過 50KB 的單條記錄。消息過大還會引起網絡帶寬的高占用，持久化到磁盤時的 IO 問題。

4、連接數限制

連接的頻繁創建和銷毀，會浪費大量的系統資源，極限情況會造成宿主機當機。請確保使用了正確的 Redis 客戶端連接池配置。

5、緩存 Key 設置失效時間

作為緩存使用的 Key，必須要設置失效時間。失效時間并不是越長越好，請根據業務性質進行設置。注意，失效時間的單位有的是秒，有的是毫秒，這個很多同學不注意容易搞錯。

6、緩存不能有中間態

緩存應該僅作緩存用，去掉后業務邏輯不應發生改變，萬不可切入到業務里。

緩存的高可用會影響業務；

產生深耦合會發生無法預料的效果；

會對維護行產生膚效果。

擴展方式首選客戶端 hash

如果應用太小就別考慮了，如單 redis 集群并不能為你的數據服務，不要著急擴大你的 redis 集群（包括 M/S 和 Cluster)，集群越大，在狀態同步和持久化方面的性能越差。 優先使用客戶端 hash 進行集群拆分。如：根據用戶 id 分 10 個集群，用戶尾號為 0 的落在第一個集群。

操作限制

1、嚴禁使用 Keys

Keys 命令效率極低，屬于 O(N)操作，會阻塞其他正常命令，在 cluster 上，會是災難性的操作。嚴禁使用，DBA 應該 rename 此命令，從根源禁用。

2、嚴禁使用 Flush

flush 命令會清空所有數據，屬于高危操作。嚴禁使用，DBA 應該 rename 此命令，從根源禁用，僅 DBA 可操作。

3、嚴禁作為消息隊列使用

如沒有非常特殊的需求，嚴禁將 Redis 當作消息隊列使用。Redis 當作消息隊列使用，會有容量、網絡、效率、功能方面的多種問題。如需要消息隊列，可使用高吞吐的 Kafka 或者高可靠的 RocketMQ。

4、嚴禁不設置范圍的批量操作

redis 那么快，慢查詢除了網絡延遲，就屬于這些批量操作函數。大多數線上問題都是由于這些函數引起。

1、[zset] 嚴禁對 zset 的不設范圍操作

ZRANGE、 ZRANGEBYSCORE等多個操作 ZSET 的函數，嚴禁使用 ZRANGE myzset 0 -1 等這種不設置范圍的操作。請指定范圍，如 ZRANGE myzset 0 100。如不確定長度，可使用 ZCARD 判斷長度

2、[hash] 嚴禁對大數據量 Key 使用 HGETALL

HGETALL會取出相關 HASH 的所有數據，如果數據條數過大，同樣會引起阻塞，請確保業務可控。如不確定長度，可使用 HLEN 先判斷長度

3、[key] Redis Cluster 集群的 mget 操作

Redis Cluster 的 MGET 操作，會到各分片取數據聚合，相比傳統的 M/S架構，性能會下降很多，請提前壓測和評估

4、[其他] 嚴禁使用 sunion, sinter, sdiff等一些聚合操作

5、禁用 select 函數

select函數用來切換 database，對于使用方來說，這是很容易發生問題的地方，cluster 模式也不支持多個 database，且沒有任何收益，禁用。

6、禁用事務

redis 本身已經很快了，如無大的必要，建議捕獲異常進行回滾，不要使用事務函數，很少有人這么干。

7、禁用 lua 腳本擴展

lua 腳本雖然能做很多看起來很 cool 的事情，但它就像是 SQL 的存儲過程，會引入性能和一些難以維護的問題，禁用。

8、禁止長時間 monitor

monitor函數可以快速看到當前 redis 正在執行的數據流，但是當心，高峰期長時間阻塞在 monitor 命令上，會嚴重影響 redis 的性能。此命令不禁止使用，但使用一定要特別特別注意。

9、Key 規范

Redis 的 Key 一定要規范，這樣在遇到問題時，能夠進行方便的定位。Redis 屬于無 scheme 的 KV 數據庫，所以，我們靠約定來建立其 scheme 語義。其好處：

1、能夠根據某類 key 進行數據清理 2、能夠根據某類 key 進行數據更新 3、能夠方面了解到某類 key 的歸屬方和應用場景 4、為統一化、平臺化做準備，減少技術變更

一般，一個 key 需要帶以下維度：業務、key 用途、變量等，各個維度使用 : 進行分隔，以下是幾個 key 的實例:

面試官問，實際項目中用Redis要注意哪些規范？

最后

適當的約束是架構成熟的必要條件，通過約定能達到規范是集體開發的最高境界。Redis用的多，也要用的穩，給點約束、立點規矩，生活將變的美好。通過二次封裝redis客戶端，直接阻斷，效果更佳。

答案4：

主庫壓力很大，可以考慮讀寫分離。

Master 最好不要做持久化工作，如 RDB 內存快照和 AOF 日志文件。(Master 寫內存快照，save 命令調度 rdbSave 函數，會阻塞主線程，文件較大時會間斷性暫停服務；AOF 文件過大會影響 Master 重啟的恢復速度)。

如果數據比較重要，使用 AOF 方式備份數據，設置合理的備份頻率。

保證主從復制的速度和網絡連接的穩定性，主從機器最好在同一內網。

官方推薦，使用 sentinel 集群配合多個主從節點集群，解決單點故障問題實現高可用。

***

[評論](https://user.qzone.qq.com/3182319461/blog/1611788476)

Redis Spring 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。