福哥答案2021-01-28：面試
答案1：
1.使用key值前綴來做命名空間
雖說Redis支持多個數據庫（默認32個，能夠配置更多），可是除了默認的0號庫之外，其它的都須要經過一個額外請求才能使用。因此用前綴做爲命名空間可能會更明智一點。redis
另外，在使用前綴做爲命名空間區隔不一樣key的時候，最好在程序中使用全局配置來實現，直接在代碼裏寫前綴的作法要嚴格避免，這樣可維護性實在太差了。sql
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看成你不少工具中的一個，只在合適使用的時候再使用它，在不合適的時候選擇其它的方法。
緩存雪崩，緩存擊穿，緩存穿透，以及緩存數據和數據庫的一致性。
還有就是緩存key過時的問，合理使用避免頻繁和redis創建IO連接。
安全問題，禁用一些危險的命令好比 keys，通用端口最後作一下修改，以前好像暴露出過安全問題。
redis配置bind 理解誤差問題，bind的做用不是白名單不是容許哪些IP能夠訪問。
答案3：
Redis功能強大，數據類型豐富，再快的系統，也經不住瘋狂的濫用。經過禁用部分高風險功能，並掛上開發的枷鎖，業務更可以以簡潔、通用的思想去考慮問題，而不是綁定在某種實現上。
Redis根據不一樣的用途，會有不一樣的持久化策略和逐出策略，因此，在使用和申請 Redis 集羣前，請明確是用來作緩存仍是存儲。Redis的集羣有主從和 cluster 兩種模式，各有優缺點。如下規範不區分集羣模式，咱們分別從使用場景和操做限制兩方面說明。
使用規範
一、冷熱數據區分
雖然 Redis支持持久化，但將全部數據存儲在 Redis 中，成本很是昂貴。建議將熱數據 (如 QPS超過 5k) 的數據加載到 Redis 中。低頻數據可存儲在 Mysql、 ElasticSearch中。
二、業務數據分離
不要將不相關的數據業務都放到一個 Redis中。一方面避免業務相互影響，另外一方面避免單實例膨脹，並能在故障時下降影響面，快速恢復。
三、消息大小限制
因爲 Redis 是單線程服務，消息過大會阻塞並拖慢其餘操做。保持消息內容在 1KB 如下是個好的習慣。嚴禁超過 50KB 的單條記錄。消息過大還會引發網絡帶寬的高佔用，持久化到磁盤時的 IO 問題。
四、鏈接數限制
鏈接的頻繁建立和銷燬，會浪費大量的系統資源，極限狀況會形成宿主機當機。請確保使用了正確的 Redis 客戶端鏈接池配置。
五、緩存 Key 設置失效時間
做爲緩存使用的 Key，必需要設置失效時間。失效時間並非越長越好，請根據業務性質進行設置。注意，失效時間的單位有的是秒，有的是毫秒，這個不少同窗不注意容易搞錯。
六、緩存不能有中間態
緩存應該僅做緩存用，去掉後業務邏輯不該發生改變，萬不可切入到業務裏。
緩存的高可用會影響業務；
產生深耦合會發生沒法預料的效果；
會對維護行產生膚效果。
擴展方式首選客戶端 hash
若是應用過小就別考慮了，如單 redis 集羣並不能爲你的數據服務，不要着急擴大你的 redis 集羣（包括 M/S 和 Cluster)，集羣越大，在狀態同步和持久化方面的性能越差。 優先使用客戶端 hash 進行集羣拆分。如：根據用戶 id 分 10 個集羣，用戶尾號爲 0 的落在第一個集羣。
操做限制
一、嚴禁使用 Keys
Keys 命令效率極低，屬於 O(N)操做，會阻塞其餘正常命令，在 cluster 上，會是災難性的操做。嚴禁使用，DBA 應該 rename 此命令，從根源禁用。
二、嚴禁使用 Flush
flush 命令會清空全部數據，屬於高危操做。嚴禁使用，DBA 應該 rename 此命令，從根源禁用，僅 DBA 可操做。
三、嚴禁做爲消息隊列使用
如沒有很是特殊的需求，嚴禁將 Redis 看成消息隊列使用。Redis 看成消息隊列使用，會有容量、網絡、效率、功能方面的多種問題。如須要消息隊列，可以使用高吞吐的 Kafka 或者高可靠的 RocketMQ。
四、嚴禁不設置範圍的批量操做
redis 那麼快，慢查詢除了網絡延遲，就屬於這些批量操做函數。大多數線上問題都是因爲這些函數引發。
一、[zset] 嚴禁對 zset 的不設範圍操做
ZRANGE、 ZRANGEBYSCORE等多個操做 ZSET 的函數，嚴禁使用 ZRANGE myzset 0 -1 等這種不設置範圍的操做。請指定範圍，如 ZRANGE myzset 0 100。如不肯定長度，可以使用 ZCARD 判斷長度
二、[hash] 嚴禁對大數據量 Key 使用 HGETALL
HGETALL會取出相關 HASH 的全部數據，若是數據條數過大，一樣會引發阻塞，請確保業務可控。如不肯定長度，可以使用 HLEN 先判斷長度
三、[key] Redis Cluster 集羣的 mget 操做
Redis Cluster 的 MGET 操做，會到各分片取數據聚合，相比傳統的 M/S架構，性能會降低不少，請提早壓測和評估
四、[其餘] 嚴禁使用 sunion, sinter, sdiff等一些聚合操做
五、禁用 select 函數
select函數用來切換 database，對於使用方來講，這是很容易發生問題的地方，cluster 模式也不支持多個 database，且沒有任何收益，禁用。
六、禁用事務
redis 自己已經很快了，如無大的必要，建議捕獲異常進行回滾，不要使用事務函數，不多有人這麼幹。
七、禁用 lua 腳本擴展
lua 腳本雖然能作不少看起來很 cool 的事情，但它就像是 SQL 的存儲過程，會引入性能和一些難以維護的問題，禁用。
八、禁止長時間 monitor
monitor函數能夠快速看到當前 redis 正在執行的數據流，可是小心，高峯期長時間阻塞在 monitor 命令上，會嚴重影響 redis 的性能。此命令不由止使用，但使用必定要特別特別注意。
九、Key 規範
Redis 的 Key 必定要規範，這樣在遇到問題時，可以進行方便的定位。Redis 屬於無 scheme 的 KV 數據庫，因此，咱們靠約定來創建其 scheme 語義。其好處：
一、可以根據某類 key 進行數據清理 二、可以根據某類 key 進行數據更新 三、可以方面瞭解到某類 key 的歸屬方和應用場景 四、爲統一化、平臺化作準備，減小技術變動
通常，一個 key 須要帶如下維度：業務、key 用途、變量等，各個維度使用 : 進行分隔，如下是幾個 key 的實例:
面試官問，實際項目中用Redis要注意哪些規範？
最後
適當的約束是架構成熟的必要條件，經過約定能達到規範是集體開發的最高境界。Redis用的多，也要用的穩，給點約束、立點規矩，生活將變的美好。經過二次封裝redis客戶端，直接阻斷，效果更佳。
答案4：
主庫壓力很大，能夠考慮讀寫分離。
Master 最好不要作持久化工做，如 RDB 內存快照和 AOF 日誌文件。(Master 寫內存快照，save 命令調度 rdbSave 函數，會阻塞主線程，文件較大時會間斷性暫停服務；AOF 文件過大會影響 Master 重啓的恢復速度)。
若是數據比較重要，使用 AOF 方式備份數據，設置合理的備份頻率。
保證主從複製的速度和網絡鏈接的穩定性，主從機器最好在同一內網。
官方推薦，使用 sentinel 集羣配合多個主從節點集羣，解決單點故障問題實現高可用。