1.事務

Redis的事務只能保持命令是連續執行的，僅此而已。

• MULTI：開啟一個事務，執行成功返回OK
• EXEC：真正執行事務
• DISCARD：放棄當前事務。此時直接清空事務隊列。之前的操作都不會真正執行到。
• WATCH：開啟事務時，如果對watch的事務進行修改，就會記錄當前key的"版本號"。在真正提交事務的時候，如果發現當前服務器上的key版本號已經超過了事務開始時的版本號，就會讓事務執行失敗（事務中所有的操作都不執行）。
• UNWATCH：取消對key的監控

客戶端1事務先不執行呢：

127.0.0.1:6379> watch k1 # 開始監控 k1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 100 # 進?修改, 從服務器獲取 k1 的版本號是 0. 記錄 k1 的
版本號. (還沒真修改呢, 版本號不變)
QUEUED
127.0.0.1:6379> set k2 1000
QUEUED

客戶端2然后修改k1：

127.0.0.1:6379> set k1 200 # 修改成功, 使服務器端的 k1 的版本號 0 -> 1
OK

客戶端1再執行，發現命令被撤回了。

127.0.0.1:6379> EXEC # 真正執?修改操作, 此時對?版本發現, 客?端的 k1 的版
本號是 0, 服務器上的版本號是 1, 版本不?致! 說明有其他客?端在事務中間修改了 k1 !!!
(nil)
127.0.0.1:6379> get k1
"200"
127.0.0.1:6379> get k2
(nil)

2. 主從復制

節點：每臺redis-server主機就是一個節點
主節點：可讀可寫的節點。
從節點：只能讀數據的節點。
主從復制：將主節點的數據復制到從節點，使從節點和主節點保持一致。

• 可用性：一個節點掛了，其他節點可以頂上。
• 性能提升：對于讀操作可以平均分攤到多個機器上。

2.1 如何啟動多個Redis服務器

正常來說，每個redis服務器程序，應該在一個單獨的主機上。學習階段可以部署到一臺機器上，但是得要求端口不一樣。

• 配置文件在/etc/redis/redis.conf，復制出來修改port，和daemonize yes
• 啟動 redis-server [新配置文件路徑] ，下圖中就把另外兩個redis啟動起來了
  
• 設置主從結構，修改配置文件加上主從結構配置。在末尾加上 slave [主節點ip] [主節點port]
  
• 再次啟動查看端口號。
  
  最終達到的效果：主節點這邊數據產生任何修改，從節點就能立即感知到。

2.2 監控主從節點的狀態

info replication

主節點
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=100,lag=0
master_replid:2fbd35a8b8401b22eb92ff49ad5e42250b3e7a06
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:100
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:100

從節點
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:170
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:2fbd35a8b8401b22eb92ff49ad5e42250b3e7a06
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:170
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:170

2.3 斷開主從復制關系

slaveof no one 來斷開主節點復制關系
1）斷開與主節點復制關系。
2）從節點晉升為主節點。

slaveof 新主機 新port 認另一個服務作為主節點
1）斷開與舊主節點復制關系。
2）與新主節點建?復制關系。
3）刪除從節點當前所有數據。
4）從新主節點進?復制操作。

以上方法僅僅是臨時性的，但是當我們重啟之后，還會以配置文件為準。

2.4 額外注意

安全性：主節點可以使用密碼來保證自己服務器的安全性
只讀：對于從節點進行修改，主節點是感知不到的。
傳輸延遲：

2.5拓撲結構

• 一主一從
  寫請求較多時，主節點負載較大。此時可以將主節點的AOF關閉，從節點開啟AOF。當主機宕機的時候，需要先從從節點獲取AOF文件再重啟。
  

• 一主多從
  實際開發中，讀請求夠多，可以選擇一主多從，但是同步時，由于從節點過多，增加帶寬，同樣對于主節點是一個壓力。
  優點：同步速度快
  

• 樹形主從
  解決了主節點同步時帶寬過高的場景，因為從節點也可以同步它的子節點。
  缺點：同步的延時變長。
  

2.6 復制過程

2.6.1 數據同步

Redis使用psync完成主從數據同步，同步過程分為：全量復制和部分復制。

• 全量復制：一般用于初次復制場景，當數據量大時，可能會對主從節點和網絡造成很大開銷。
• 部分復制：用于處理在主從復制中因網絡閃斷等原因造成的數據丟失場景，當從節點再次連接上主節點后，如果條件允許，主節點會補發數據給從節點。

主節點
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=100,lag=0
master_replid:2fbd35a8b8401b22eb92ff49ad5e42250b3e7a06      主節點ID
master_replid2:0000000000000000000000000000000000000000    備用ID 
master_repl_offset:100
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:100

從節點
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:170
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:2fbd35a8b8401b22eb92ff49ad5e42250b3e7a06
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:170
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:170

PSYNC語法格式：

PSYNC replicationed offset
replicationed=?,offset=-1，表示全量復制
具體的值就是嘗試進行部分復制

1. replicationid/replid（復制ID）
   主節點的復制id，主節點重新啟動，或者從節點晉升為主節點，都會生成一個replicationid。（同一個節點每次重啟，replicationid都會變化）
   從節點和主節點連接后，就會獲取到主節點的replicationid。

2. offset(偏移量)
   主節點每進行一次寫操作會記錄一下偏移量，統計在master_repl_offset中。并且也會記錄從節點的復制偏移量，保存在slave0中。
   從節也會記錄自己的偏移量在slave_repl_offset
   因此可以通過對比主從節點的偏移量，來看數據是否一致。
   

psync 運?流程 ：

步驟：1.從節點發送psync命令給主節點，replied和offset的默認值是?和-1。
2.主節點根據psync參數和自身數據情況決定響應結果 +FULLRESYNC replid offset，從節點需要進行全量；+CONTINEU，部分復制；
-ERR，說明 Redis 主節點版本過低，不?持 psync 命令。

全量復制：

1）從節點發送 psync 命令給主節點進?數據同步，由于是第?次進?復制，從節點沒有主節點的運
? ID 和復制偏移量，所以發送 psync ? -1。
2）主節點根據命令，解析出要進?全量復制，回復 +FULLRESYNC 響應。
3）從節點接收主節點的運?信息進?保存。
4）主節點執? bgsave 進? RDB ?件的持久化。
5）從節點發送 RDB ?件給從節點，從節點保存 RDB 數據到本地硬盤。
6）主節點將從?成 RDB 到接收完成期間執?的寫命令，寫?緩沖區中，等從節點保存完 RDB ?件
后，主節點再將緩沖區內的數據補發給從節點，補發的數據仍然按照 rdb 的?進制格式追加寫?到收
到的 rdb ?件中. 保持主從?致性。
7）從節點清空??原有舊數據。
8）從節點加載 RDB ?件得到與主節點?致的數據。
9）如果從節點加載 RDB 完成之后，并且開啟了 AOF 持久化功能，它會進? bgrewrite 操作，得到最
近的 AOF ?件。

生成RDB文件在發送比較麻煩：

即使是省去了讀寫硬盤的開銷，但是此操作的大頭是網絡傳輸，這個沒法省，所以開銷仍然很大。

部分復制：

1）當主從節點之間出現?絡中斷時，如果超過 repl-timeout 時間，主節點會認為從節點故障并終端
復制連接。
2）主從連接中斷期間主節點依然響應命令，但這些復制命令都因?絡中斷?法及時發送給從節點，所
以暫時將這些命令滯留在復制積壓緩沖區中。
3）當主從節點?絡恢復后，從節點再次連上主節點。
4）從節點將之前保存的 replicationId 和 復制偏移量作為 psync 的參數發送給主節點，請求進?部分
復制。
5）主節點接到 psync 請求后，進?必要的驗證。隨后根據 offset 去復制積壓緩沖區查找合適的數據，
并響應 +CONTINUE 給從節點。
6）主節點將需要從節點同步的數據發送給從節點，最終完成?致性。

復制積壓緩沖區：
復制積壓緩沖區是保存在主節點上的?個固定?度的隊列，默認??為 1MB，當主節點有連接的從節
點（slave）時被創建，這時主節點（master）響應寫命令時，不但會把命令發送給從節點，還會寫?
復制積壓緩沖區，如圖所?。

由于緩沖區本質上是先進先出的定?隊列，所以能實現保存最近已復制數據的功能，?于部分復制和復制命令丟失的數據補救。復制緩沖區相關統計信息可以通過主節點的 info replication 中：

實時復制：
主從節點在建?復制連接后，主節點會把??收到的 修改操作 , 通過 tcp ?連接的?式, 源源不斷的傳輸給從節點. 從節點就會根據這些請求來同時修改??的數據. 從?保持和主節點數據的?致性.

另外, 這樣的?連接, 需要通過?跳包的?式來維護連接狀態. (這?的?跳是指應?層??實現的?跳,
?不是 TCP ?帶的?跳).
1）主從節點彼此都有?跳檢測機制，各?模擬成對?的客?端進?通信。
2）主節點默認每隔 10 秒對從節點發送 ping 命令，判斷從節點的存活性和連接狀態。
3）從節點默認每隔 1 秒向主節點發送 replconf ack {offset} 命令，給主節點上報??當前的復制偏移
量。
如果主節點發現從節點通信延遲超過 repl-timeout 配置的值（默認 60 秒），則判定從節點下線，斷
開復制客?端連接。從節點恢復連接后，?跳機制繼續進?。

3.哨兵

基本流程是：

1. 哨兵監控
2. 哨兵發現某個節點掛了，會協商選出一個leader
3. leader去完成后續故障轉移工作。從節點中選一個作為新的主節點；讓其他從節點同步新主節點；通知應用層轉移到新主節點上；
   

選舉原理

1. 主觀下線，這個哨兵通過心跳包，判定redis是否正常工作。
2. 客觀下線，多個哨兵都認為這個主節點掛了，（達到了法定票數）
3. 讓多個哨兵節點選一個leader
4. leader選完后，leader就需要選一個從節點，作為新的主節點。
   優先級：每個redis數據節點，都會在配置文件中有一個優先級，slave-priority優先級大的勝出
   offset：offset越大說明同步數據的進度越大。
   run id：每個redis節點啟動的時候隨機生成一串數字。
5. 選出之后，leader就會控制這個節點，執行slave no one，成為master。再控制其他節點，執行slave of，換主結點即可。

注意事項

• 哨兵節點不能只有?個. 否則哨兵節點掛了也會影響系統可?性.
• 哨兵節點最好是奇數個. ?便選舉 leader, 得票更容易超過半數.
• 哨兵節點不負責存儲數據. 仍然是 redis 主從節點負責存儲.
• 哨兵 + 主從復制解決的問題是 “提?可?性”, 不能解決 “數據極端情況下寫丟失” 的問題.
• 哨兵 + 主從復制不能提?數據的存儲容量. 當我們需要存的數據接近或者超過機器的物理內存, 這樣的結構就難以勝任了.

4.集群

Redis 的集群就是引?多組 Master / Slave , 每?組 Master / Slave 存儲數據全集的?部分, 從?構成?個更?的整體, 稱為 Redis 集群 (Cluster).

4.1 數據分片算法

• 哈希求余
  優點：簡單高效、數據分配均勻
  缺點：一旦需要擴容，N改變了，原有的規則映射被破壞，就需要重新排列數據，開銷大。

• 一致性哈希算法
  第?步, 把 0 -> 2^32-1 這個數據空間, 映射到?個圓環上. 數據按照順時針?向增?.
  第?步, 假設當前存在三個分?, 就把分?放到圓環的某個位置上.
  第三步, 假定有?個 key, 計算得到 hash 值 H, 規則很簡單, 就是從 H 所在位置, 順時針往下找, 找到的第?個分?, 即為該 key 所從屬的分?.
  當增加分片時，只有相鄰的分片才會進行搬運，大大減少了搬運規模
  優點: ??降低了擴容時數據搬運的規模, 提?了擴容操作的效率.
  缺點: 數據分配不均勻 (有的多有的少, 數據傾斜).

• 哈希槽分區算法 (Redis 使?) （解決搬運成本高，數據分配不均勻）
  hash_slot = crc16(key) % 16384 [0-16383]個槽位
  
  現在需要擴容一個分片，只需要從0、1、2號分片中適當拿出一點，就可以湊夠了。
  分片的規則很靈活：每個分片持有的槽位不一定連續。每個節點使用位圖來表示自己持有哪些槽位。16384個槽位，需要2KB大小的內存空間表示。

問題1：Redis集群最多有16384個分片嗎？
不對，每個分片的槽位應該不超過1000。
有的槽位可能有多個key，有的槽位可能沒有key。因為多個key的哈希可能映射到同一個槽位。
? 節點之間通過?跳包通信. ?跳包中包含了該節點持有哪些 slots. 這個是使?位圖這樣的數據結構
表?的. 表? 16384 (16k) 個 slots, 需要的位圖??是 2KB. 如果給定的 slots 數更多了, ?如 65536
個了, 此時就需要消耗更多的空間, 8 KB 位圖表?了. 8 KB, 對于內存來說不算什么, 但是在頻繁的?
絡?跳包中, 還是?個不?的開銷的.
? 另???, Redis 集群?般不建議超過 1000 個分?. 所以 16k 對于最? 1000 個分?來說是?夠?
的, 同時也會使對應的槽位配置位圖體積不?于很?.

4.2 故障檢測

1）故障判定
集群中的所有節點，都會周期性的使用心跳包進行通信。

1. 節點A給節點B發送ping包，B就會給A返回一個pong包。ping喝pong除了message type不一樣外，其它都一樣。都包含了集群中的配置信息（該節點的id，該節點從屬于哪個分片，是主節點還是從節點，從屬于誰，持有哪些slots圖）。
2. 每個節點，每秒鐘，都會給一些隨機的節點發起ping包，而不是全發一遍。
3. 當節點A給節點B發起ping包，B不能如期回應的時候，此時A就會嘗試重置和B的TCP連接，看能否連接成功。如果仍然連接失敗，A就會把B設置為PFALL狀態。
4. A判定B為PFALL之后，就會通過redis內置的Gossip協議，和其他節點進行溝通，向其他節點確認B的狀態。
5. 此時A發現其他很多節點，也認為B為PFALL，并且數目超過總集群個數的一半，那么A就會把B標記成FAIL（客觀下線），并且這個消息同步給其他節點。

2）故障遷移（把從節點提拔成主節點）（選舉過程：Raft算法）
上面的例子，B故障，A會把B FAIL的消息告知集群中的其他節點

• 如果B是從節點，那么不需要進行故障遷移。
• 如果B是主節點，那么就會由B的從節點(比如C和D)觸發故障遷移。
  流程如下：

6. 從節點判定自己是否具有參選資格。如果從節點和主節點已經太久沒通信（數據差距太大），時間超過閾值，就是去競選資格
7. 具有資格的從節點，比如C和D，會先休眠一定時間，休眠時間=500ms擠出時間+[0, 500ms]隨機時間+排名*1000ms。offset值越大，排名越靠考前。
8. 比如C的休眠時間到了，C就會給其他所有集群中的節點，進行拉票操作。但是只有主節點才有投票資格。
9. 主節點會把自己的票投給C，當C收到的票數超過主節點數目的一半，C就會晉升成主節點。
   10.同時C還會把自己成為主節點的消息，同步給其他集群的節點。

5. 緩存

最重要的是熱key，熱key如何生成呢？
1)定期生成
每隔一段時間，會訪問的數據頻次進行統計。挑選出訪問頻次最高的前N%數據。
優點：實現起來比較簡單，過程更可控，方便排查問題。
缺點：實時性不夠，如果出現一些突發事件，有一些不是熱詞的內容，成了熱詞了。新的熱詞就可能給后面的數據庫帶來較大的壓力。

2)實時生成
先給緩存設定容量上限(可以通過 Redis 配置?件的 maxmemory 參數設定).

• 如果redis查到了直接返回。
• redis中不存在，就從數據庫查，把查到的結果同時寫入redis。
• 如果緩存已經滿了(達到上限), 就觸發緩存淘汰策略, 把?些 “相對不那么熱?” 的數據淘汰掉.

淘汰策略：
FIFO (First In First Out) 先進先出
把緩存中存在時間最久的 (也就是先來的數據) 淘汰掉.

LRU (Least Recently Used) 淘汰最久未使?的
記錄每個 key 的最近訪問時間. 把最近訪問時間最?的 key 淘汰掉.

LFU (Least Frequently Used) 淘汰訪問次數最少的
記錄每個 key 最近?段時間的訪問次數. 把訪問次數最少的淘汰掉.

Random 隨機淘汰
從所有的 key 中抽取幸運?被隨機淘汰掉.

Redis內置淘汰策略如下：

5.1 緩存問題

1. 緩存預熱（Cache preheating）
   通過統計的方式把熱點數據導入到redis中，通過實時生成，達到緩存預熱的工作。

2. 緩存穿透Cache penetration
   查詢的某個key，在redis中沒有，mysql也沒有。這個key也不會更新到key中。
   原因：業務設計不合理，非法的key也被進行查詢了；數據庫的數據不小心被刪除了；黑客惡意攻擊。
   解決辦法：對參數進行嚴格校驗，是否符合查詢的格式；針對數據庫上不存在的key，也存到Redis中，比如value就設置”“；使用布隆過濾器先判斷key是否真存在，再真正查詢。

3. 緩存雪崩Cache avalanche
   短時間內大量的key再緩存上失效，導致數據庫壓力驟增。
   原因：Redis掛了；Redis大量的key同時過期。
   如何解決：部署高可用的集群，并完善監控報警體系；不給key設置過期事件或者設置過期事件的時候添加隨機事件因子。

4. 緩存擊穿(Cache breakdown)
   原因：緩存雪崩的特殊情況，針對熱key突然過期了，導致大量的請求直接打到數據庫上，引起數據庫宕機。
   如何解決：基于統計方式發現熱key，設置永不過期；進行必要的服務降級，利用訪問數據庫時使用分布式鎖，限制同時請求數據庫的并發數。

6. 分布式鎖

分布式鎖是一種或一組單獨的服務器程序，給其他服務器提供加鎖服務。
AB進程在訪問Mysql時，在之間設置一個鎖Redis服務器。
A進行買票時，會往Redis設置一個鍵值對，B想設置時，發現該鍵值對已經設置過了，就加不了鎖了。A操作之后，就將該鍵值對刪除。
問題1：若A沒有執行完掛掉了，誰來釋放（刪除）鎖呢？
解決：設置key的過期時間，來防止A掛掉。
問題2：有沒有可能B去解鎖呢？
解決：首先給服務器編號，加鎖時，value對應著服務器的編號。后續解鎖時候，就可以進行校驗了。（就可能避免B可能會誤解鎖了）

問題3：解鎖是兩步的，先查詢判定，在del。有可能A服務器里有兩個線程會導致重復del。在這兩個線程del之間，有B加鎖了。因此需要保證操作為原子性。
解決：使用lua寫一些邏輯，存到服務器上。 客戶端可以調用lua這個API來保證操作原子性。

問題4：過期時間續約問題？設置多少合適呢？
專門負責續約的線程，每次快過期的時候再重新設置時間，叫做”看門狗“（watch dog）。這個是加鎖的服務器上的。

問題5：RedLock？（少數服從多數）

加鎖的時候, 按照?定的順序, 寫多個 master 節點. 在寫鎖的時候需要設定操作的 “超時時間”. ?如
50ms. 即如果 setnx 操作超過了 50ms 還沒有成功, 就視為加鎖失敗.
如果給某個節點加鎖失敗, 就?即再嘗試下?個節點.
當加鎖成功的節點數超過總節點數的?半, 才視為加鎖成功.
同理, 釋放鎖的時候, 也需要把所有節點都進?解鎖操作. (即使是之前超時的節點, 也要嘗試解鎖, 盡量保
證邏輯嚴密).