002---Redis

主從複製

主節點負責寫數據、從節點負責讀數據。主節點按期將數據同步到從節點，從而保證數據的一致性。

• 一主一從

• 一主多從
  針對「讀」較多的場景，「讀」由多個從節點來分擔，但節點越多，主節點同步到多節點的次數也越多，影響帶寬，也加劇主節點的穩定

• 樹狀主從：一主多從的缺點（主節點推送次數多壓力大）可用些方案解決，主節點只推送一次數據到從節點B，再由從節點B推送到C，減輕主節點推送的壓力。

缺點：

• 主節點出現問題，需手動配置將從節點變爲主節點
• 主從複製的主節點寫能力單機，能力有限

發佈與訂閱

redis提供了「發佈、訂閱」模式的消息機制，其中消息訂閱者與發佈者不直接通訊，發佈者向指定的頻道（channel）發佈消息，訂閱該頻道的每一個客戶端均可以接收到消息

Redis哨兵機制（Sentinel）

哨兵機制正式爲了解決主從複製的缺點

原理：當主節點出現故障時，由Redis Sentinel自動監控完成故障發現和轉移，並通知應用方，實現高可用性

Redis 持久化

支持RDB、AOF。兩種持久化機制。持久化可避免進程丟失而形成數據丟失。

• RDB持久化

RDB持久化把當前進程數據生成快照（.rdb）文件保存到硬盤的過程，有手動觸發和自動觸發
手動觸發有save和bgsave兩命令

save命令：阻塞當前Redis，直到RDB持久化過程完成爲止，若內存實例比較大會形成長時間阻塞，線上環境不建議用它

bgsave命令：redis進程執行fork操做建立子線程，由子線程完成持久化，阻塞時間很短（微秒級），是save的優化,在執行redis-cli shutdown關閉redis服務時，若是沒有開啓AOF持久化，自動執行bgsave;
顯然bgsave是對save的優化
優勢：1，壓縮後的二進制文文件適用於備份、全量複製，用於災難恢復

2，加載RDB恢復數據遠快於AOF方式

缺點：1，沒法作到實時持久化，每次都要建立子進程，頻繁操做成本太高

2，保存後的二進制文件，存在老版本不兼容新版本rdb文件的問題

• AOF持久化

Redis的過時策略

Redis的分佈式鎖實現

redis常見集羣技術

• 客戶端分片
• 代理分片
• Redis Cluster

codis

Twemproxy代理分片

應用場景

• 緩存

• 排行榜：redis的有序列表數據結構很是方便。

• 計數器：點贊、訪問數。

• 限速器：搶購秒殺，防止用戶瘋狂點擊帶來沒必要要的壓力；

• session共享：session默認保存在服務器中，即當前服務器。若是是集羣服務，用戶的信息可能在不一樣機器，因此會形成用戶頻繁登陸。利用redis保存session，不管哪臺機器均可以獲取session信息。

• 簡單的消息隊列：除了Redis自身的發佈/訂閱模式，咱們也能夠利用List來實現一個隊列機制，好比：到貨通知、郵件發送之類的需求