Redis哨兵-3

1.Redis持久化策略

1.1 什麼是持久化:

說明:

Redis運行環境在內存中,若是服務器關閉則內存數據講話丟失;

需求: 如何保持內存數據

解決方案:能夠按期將內存數據持久化到磁盤中

持久化策略規則:

當redis正常運行時,按期的將數據保存到磁盤中,當redis服務器重啓時,則根據配置文件中指定的持久化方式,事項數據的回覆(讀取數據以後回覆數據)

1.2 RDB模式:

1.2.1 RDB模式 是Redis默認的策略;
1.2.2 RDB模式 可以按期持久化(時間間隔),弊端_可能致使數據的丟失;
1.2.3 RDB模式 記錄的是內存數據的快照,持久化效率較高,快照只保留最新記錄;
1.2.4 RDB模式命令:

• save 命令:將內存數據持久化到磁盤中 ----主動式操做

缺點___ 會形成線程的阻塞

• bgsave 命令:將內存數據採用後臺運行的方式,持久化到磁盤中
• 默認的持久化的機制:

a. save 900 1 若是在900秒內執行了1次更新操做,則持久化一次
b. save 300 10 若是在300秒內執行了10次更新操做,則持久化一次
c. save 60 10000 若是在60秒內執行了10000次更新操做,則持久化一

1.3 AOF模式:

1.3.1 AOF模式特色:

• AOF模式默認條件下是關閉的,須要手動開啓;
• AOF模式記錄的是用戶的操做過程,因此能夠實現實時持久化操做;
• AOF模式因爲記錄的是實時的操做過程,因此持久化文件較大,須要按期維護;

1.3.2 啓動AOF模式:

(redis 重啓 redis-cli sutd縮寫)

• 說明: 若是開啓AOF模式 則一AOF模式爲準
  如何開啓:進入 vim redis.conf 修改appendonly no 修改成yes

1.4 關於持久化操做總結:

• 當內存數據容許少許丟失是,使用RDB模式(快);
• 當內存數據不容許數據丟失是,採用AOF(按期須要維護);
• 通常在工做中採用AOF+RDB模式共同做用,保證數據的有效性

2. Redis內存策略

2.1爲何須要內存優化

• 說明:因爲redis在內存中保存數據,若是一直存儲,則內存必然溢出

因此須要按期維護內存數據的大小

• 維護策略:
  刪除舊的不用的數據,保存新的經常使用的數據;

2.2 LRU算法:

• 說明:
  LRU最近最少使用,是一種經常使用的頁面置換算法,選擇最近最久未使用的數據予以淘汰;
• 計算維度
  時間T
• 注意事項:
  是迄今爲止內存中最好用的數據置換算法;

2.3 LFU算法

• 說明:
  最不常常使用數據置換算法 ,要求在數據置換是置換引用計數最下的數據,由於常常使用的數據應該有一個較大的引用次數;
• 計算維度:
  使用次數

2.4 隨機算法

2.5 TTL算法

• 說明
  根據存活時間,將立刻要超時的數據提早刪除;

2.6 配置內存優化策略

• valatile-lru 在設定了超時時間的數據,採用lru算法
• allkeys-lru 在全部的數據中採用lru算法
• volatile-lfu 在設定了超時時間的詩句中採用lfu算法
• allkeys-lfu 全部數據採用lfu算法
• volatile-random 設置超時時間數據的隨機算法
• allkeys-random 全部數據隨機
• volatile-ttl 將設定了超時時間的數據 提早刪除
• noeviction 若是設置了noeviction 則不刪除數據 直接保存返回

3. 關於緩存的面試問題

問題出發點:

因爲緩存失效,致使大量用戶直接訪問後臺數據庫,

• 3.1 緩存穿透

說明:
用戶頻繁訪問數據庫中不存在的數據是,可能出現緩存穿透的現象,若是該操做是高斌發操做,則肯能直接威脅數據庫服務器;

解決方法:
A. 能夠採用IP限流的方式,下降用戶訪問服務器次數;
B. 微服務處理方式:
利於斷路器 返回指定的業務數據便可;不執行數據操做保護數據庫
C. 微服務處理方式:API網關設計,

• 3.2 緩存擊穿

說明:
因爲REdis中某個熱點數據超時/刪除等操做,致使數據失效,若是用戶高併發訪問該數據,則可能致使數據可宕機,該操做稱之爲 緩存擊穿

解決方案:
能夠採用多級緩存的設計;

• 3.3 緩存雪崩

說明:
因爲redis數據大量失效,致使用戶訪問命中率過低,=>大量用戶直接訪問數據庫,致使服務器宕機;
解決方案:
能夠採用多級緩存的設計;
設定不一樣超時時間
禁止直行flushall等敏感操做;

### 4. Redis分片說明

• 說明:

4.2部署

4.2.1 編制配置文件和修改端口

• 搭建端口號 6379 6380 6381
• 進入redis 根目錄 cd /usr/local/src/redis

• 啓動redis-server 6380.conf (redis-cli -p 6380 進入服務器)

4.2.2 redis分片測試

• 一致性HASH算法:
  A. 概念:是一種特殊的哈希算法,目的就是解決分佈式緩存的問題,在移除和添加服務器的時候,可以儘量小的改變映射關係;
  B. 原理說明:

  1). 常規hash由8位16進制數組成;
  2). uuid由23位16進制數組成

  C. 只負責管理 不負責存儲數據

4.2.3 hash特性一 平衡性

實現平衡性的方案: 引入虛擬節點

4.2.4 hash特性二 單調性

特色:在進行數據遷移時儘量小的改變的改變數據

4.2.5 hash特性三 分散性

4.2.6 redis的分散佈局

第一步:配置文件

第二步:編輯配置類
API: ShardedJedis對象

5. Redis哨兵機制

5.1 分片機制存在的問題

• 說明:
  實現內存數據的擴容,若是redis其中有一個節點宕機,就會直接影響全部節點的運行;
• 採用哨兵機制,實現節點的高可用;

5.2 redis主從的部署

• 關閉redis分片的節點,
• 複製分片的目錄 更名爲sentinel
• 刪除多餘的持久化文件,保存redis的配置文件
• 啓動三臺redis服務器

實現redis的主從

• 命令: info replication 查看節點的狀態(默認redis都是主機)

實現redis的主從的掛載

• 修改redis服務器狀態 (主機和從機的修改)

A.slave of (進入80) 6379 爲主機~~~~

B. redis全部節點均可以相同通訊,

5.2 哨兵機制的工做原理

5.3 哨兵機制的配置