思維導圖：
https://www.processon.com/view/link/5e73239ee4b03b9965240e6a#map
REDIS 五中數據類型的底層實現
https://www.cnblogs.com/MouseDong/p/11134039.html
https://www.jianshu.com/p/fe2b4b9387b9
REDIS集羣配置講解
https://baijiahao.baidu.com/s?id=1643461909684941861&wfr=spider&for=pc
https://www.cnblogs.com/vieta/p/11192137.html
https://www.zhihu.com/question/21419897
https://www.jianshu.com/p/ee1ccbddb020
數據持久化
https://www.cnblogs.com/chenliangcl/p/7240350.html
MYSQL+REDIS數據一致性
https://www.zhihu.com/question/319817091
https://my.oschina.net/jiagouzhan/blog/2990423
阿里雲 Redis 開發規範深入解讀
https://zhuanlan.zhihu.com/p/108645085
一致性哈希和哈希槽對比
https://www.jianshu.com/p/4163916a2a8a
Redis Cluster 集羣擴容與收縮
https://blog.csdn.net/men_wen/article/details/72896682
內存淘汰機制：爲了節省內存。可以設置key的過期時間或者在redis.config中需要搜索 maxmemory-policy 來設置淘汰策略
內存持久化：
RDB:內存快照 以二進制存儲 默認文件dump.rdb
落地時機：1.redis正常關閉 執行shutdown 2.配置 N秒 X次寫操作 進行一次快照
優點：保存還原快速 快照快速 fork子進程來執行快照 不會影響服務器性能
缺點：意外宕機，會導致最後一次快照之後的操作數據丟失。 做快照時會佔用一定會的內存空間 不適合內存小的機器使用。
fork是寫複製，開始父子公用內存空間，父內存進行修改時子才複製內存。
AOF(append only file)：Reids的寫操作日誌以追加的方式寫入文件
落地時機：三中同步策略，即每秒同步、每修改同步和不同步。
每秒同步也是異步完成的，其效率也是非常高的，所差的是一旦系統出現宕機現象，那麼這一秒鐘之內修改的數據將會丟失。
每修改同步，我們可以將其視爲同步持久化，即每次發生的數據變化都會被立即記錄到磁盤中。這種方式在效率上是最低的。
優點：意外宕機 數據丟失要小
缺點：每次修改都要追加到文件中，影響服務器性能。寫操作以追加方式存儲在文件中，n個寫 就存 追加 n 次到文件中。會導致佔用的硬盤空間過大。
混合持久化：結合rdb 和 aof，每次進行重寫時，保存重寫時內存的rdb內容和增量aof命令。每次當aof文件大小超過配置限制或內存增大n倍時觸發重寫。
使用混合持久化可以加快redis恢復數據時間，並最大程度減少數據的丟失。
常見問題：
緩存雪崩 ：一段時間內大量的緩存失效，導致在這段時間內數據庫(mysql)壓力倍增
緩存穿透 : 緩存中不存在內容 到mysql中讀取。mysql中也沒有數據，則每次執行這個操作都去mysql中讀取。 解決辦法 mysql中沒數據，也在緩存中建立一個nil的key
緩存預熱： 啓動時預先加載熱數據，防止啓動後大量的數據庫請求，導致數據庫壓力過大
Redis併發競爭key的解決方案詳解：
1.分佈式鎖：在redis/zookeeper等用一個狀態值表示鎖，佔用和釋放都用這個值表示。
redis存儲在內存中，如果存儲在內存中，存儲容量肯定要比磁盤少很多，那麼要存儲大量數據，只能花更多的錢去購買內存，
造成在一些不需要高性能的地方是相對比較浪費的，所以目前基本都是mysql(主) + redis(輔)，在需要性能的地方使用redis，在不需要高性能的地方使用mysql
mysql+redis數據一致性：
一：基於業務中代碼
1.write mysql del redis
缺點：程序崩潰緩存沒有刪除
解決辦法：緩存設置超時時間，只有在超時時間內讀取的數據是髒數據
2.del redis write mysql
缺點：del 和 write 期間有其他線程 read 數據，到mysql read 到緩存中，則後期使用的緩存都是髒數據
解決辦法：write mysql 後再次del redis ，這樣只要在del redis write mysql期間內的數據纔是髒數據
del write del + 過期時間
二：基於binlog使用mysql_udf_redis，將數據庫中的數據同步到Redis。
缺點： mysql_udf_redis是有人實現的同步數據到Redis的功能，需要學習成本，第三方的插件不穩定
三：使用第三方的比如Kafka，RabbitMq等來實現，管理起來不方便，系統整體穩定性不行，而且只是這麼個比較小的箱格數據信息同步。
集羣：
主從複製：爲了解決單臺服務器因爲設備故障導致數據丟失，讀寫分離提高併發量。一主多從，主負責數據的寫操作，從服務器負責數據度。
當主數據改變時自動同步到從服務器。容災處理，當主掛掉，冷處理，手動重新配置主從關係。
哨兵模式：哨兵模式具備了所有主從複製的有點，並加入了主從複製模式不具備的錯誤轉移處理。 哨兵進程通過命令獲取redis實例的狀態，監控實例。當檢測到主服務器掛掉，那麼就選舉一個從服務器做爲主服務器，然後將新的主服務器信息
通知到其他的從服務器，進行連接。缺點是很難支持在線擴容
cluster集羣：n個節點，無中心節點，每個節點之間相互連接。key通過CRC16校驗後對16384取模來決定放置哪個槽，集羣的每個節點負責一部分hash槽。 當某個節點異常，不影響整個集羣。可在線擴容/縮容，擴容/縮容只需要轉移節點的數據。節點的主服務掛掉可以從節點的從服務器中選舉出一個作爲主節點。
可以說cluster集羣繼承了哨兵的有點，解決了哨兵的在線動態擴容的問題。但是cluster集羣對批量操作mget、mset keys 事務支持有限。
cluster集羣key命名，如果key中有{}那麼只計算{}內的CRC16 進行槽位映射
事務：順序的執行多個命令 當某個命令操作報錯，該命令不會被執行 但是其他命令還會被執行 並不會整體回滾。 語法錯誤 會導致直接回滾。集羣模式下事務不生效。
multi
命令1
命令2
exec
執行LUA腳本：eval和evalsha