說明：個人原創，本人在一線互聯網大廠維護著幾千套集群，關于redis使用的一些坑進行了經驗總結，希望能給大家帶來一些幫助
適用場景：并發量大、訪問量大的業務
規范：介紹軍規內容
解讀：講解軍規設定原因，解讀比軍規內容更重要
寫在前面的話：
總是在災難發生后，才想起容災的重要性；
總是在吃過虧后，才記得曾經有人提醒過。
一、基礎規范【5條】
1. 必須配置訪問密碼
解讀：裸奔的Redis除了方便被外部盜取資料外，內部管理上也極易出現誤操作風險，如誤連造成資料被覆寫、丟失！
2.必須以非root用戶啟動
解讀：Redis的設計過于靈活，這直接讓攻擊者可以遠程通過root運行的redis服務獲取到作業系統root權限！
3.禁止將Redis當做持久化存盤使用
解讀：Redis雖然支持AOF、RDB持久化模式，但是并不會記錄每條操作的詳細時間戳（對比MySQL的binlog會詳細記錄執行時間），出現誤操作時無法進行精確回滾！
4.禁止不同業務混合部署使用同一套Redis
解讀：（1）Redis為單執行緒模型，不同業務的資料存盤在一起，除了管理上混亂，單執行緒模型下只要有一個請求命令變慢，就會影響所有存盤在同Redis中的所有請求！
（2）雖然redis支持多個db，但是請求并不會被隔離，比如請求0號庫的一個慢操作，也一樣樣會阻塞其它1、2、3、4庫的連接和請求！
5.選擇相對較新的版本，強烈建議5.0以上版本
解讀：除了5.0版本引入了更多新特性及bug修復外，5.0對Redis的記憶體碎片管理效率帶來了極大的提升，而碎片絕對是Redis的一大性能殺手，但早期的2.x、3.x、4.x版本都沒有很好的解決這一問題！
?看完本文有識訓？請轉發分享給更多人
關注「資料庫架構師」，提升資料庫技能
博客地址：https://blog.csdn.net/samyunhuan/article/details/106151516
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/54142.html
標籤：高性能數據庫開發
上一篇：WPF wordcount關閉程式后word行程沒有結束
下一篇：求大佬幫助