redis
1.0
RDB（Redis DataBase）
什麼是RDB？
在指定的時間間隔内将記憶體中的資料集快照寫入磁盤，也就是行話講的Snapshot快照，它恢複時是将快
照檔案直接讀到記憶體裡
Redis會單獨建立（fork）一個子程序來進行持久化，會先将資料寫入到一個臨時檔案中，待持久化過程
都結束了，再用這個臨時檔案替換上次持久化好的檔案。整個過程中，主程序是不進行任何IO操作的。
這就確定了極高的性能。如果需要進行大規模資料的恢複，且對于資料恢複的完整性不是非常敏感，那
RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的資料可能丢失。
2.0
Fork
Fork的作用是複制一個與目前程序一樣的程序。新程序的所有資料（變量，環境變量，程式計數器等）
數值都和原程序一緻，但是是一個全新的程序，并作為原程序的子程序
3.0
AOF（Append Only File）
是什麼？
以日志的形式來記錄每個寫操作，将Redis執行過的所有指令記錄下來（讀操作不記錄），隻許追加檔案
但不可以改寫檔案，redis啟動之初會讀取該檔案重新建構資料，換言之，redis重新開機的話就根據日志檔案
的内容将寫指令從前到後執行一次以完成資料的恢複工作
`Aof儲存的是 appendonly.aof 檔案``
4.0
總結1、RDB 持久化方式能夠在指定的時間間隔内對你的資料進行快照存儲
2、AOF 持久化方式記錄每次對伺服器寫的操作，當伺服器重新開機的時候會重新執行這些指令來恢複原始
的資料，AOF指令以Redis 協定追加儲存每次寫的操作到檔案末尾，Redis還能對AOF檔案進行背景重
寫，使得AOF檔案的體積不至于過大。
3、隻做緩存，如果你隻希望你的資料在伺服器運作的時候存在，你也可以不使用任何持久化
4、同時開啟兩種持久化方式
在這種情況下，當redis重新開機的時候會優先載入AOF檔案來恢複原始的資料，因為在通常情況下AOF
檔案儲存的資料集要比RDB檔案儲存的資料集要完整。
RDB 的資料不實時，同時使用兩者時伺服器重新開機也隻會找AOF檔案，那要不要隻使用AOF呢？作者
建議不要，因為RDB更适合用于備份資料庫（AOF在不斷變化不好備份），快速重新開機，而且不會有
AOF可能潛在的Bug，留着作為一個萬一的手段。
5、性能建議
因為RDB檔案隻用作後備用途，建議隻在Slave上持久化RDB檔案，而且隻要15分鐘備份一次就夠
了，隻保留 save 900 1 這條規則。
如果Enable AOF ，好處是在最惡劣情況下也隻會丢失不超過兩秒資料，啟動腳本較簡單隻load自
己的AOF檔案就可以了，代價一是帶來了持續的IO，二是AOF rewrite 的最後将 rewrite 過程中産
生的新資料寫到新檔案造成的阻塞幾乎是不可避免的。隻要硬碟許可，應該盡量減少AOF rewrite
的頻率，AOF重寫的基礎大小預設值64M太小了，可以設到5G以上，預設超過原大小100%大小重
寫可以改到适當的數值。
如果不Enable AOF ，僅靠 Master-Slave Repllcation 實作高可用性也可以，能省掉一大筆IO，也
減少了rewrite時帶來的系統波動。代價是如果Master/Slave 同時倒掉，會丢失十幾分鐘的資料，
啟動腳本也要比較兩個 Master/Slave 中的 RDB檔案，載入較新的那個，微網誌就是這種架構。
5.0
Redis事務
理論
Redis事務的概念：
Redis 事務的本質是一組指令的集合。事務支援一次執行多個指令，一個事務中所有指令都會被序列
化。在事務執行過程，會按照順序串行化執行隊列中的指令，其他用戶端送出的指令請求不會插入到事
務執行指令序列中。
總結說：redis事務就是一次性、順序性、排他性的執行一個隊列中的一系列指令。
Redis事務沒有隔離級别的概念：
批量操作在發送 EXEC 指令前被放入隊列緩存，并不會被實際執行！
Redis不保證原子性：
Redis中，單條指令是原子性執行的，但事務不保證原子性，且沒有復原。事務中任意指令執行失敗，其
餘的指令仍會被執行。
Redis事務的三個階段：
開始事務
指令入隊
執行事務
Redis事務相關指令：
watch key1 key2 ... #監視一或多個key,如果在事務執行之前，被監視的key被其他指令改動，則 事務被打斷 （ 類似樂觀鎖 ） multi # 标記一個事務塊的開始（ queued ） exec # 執行所有事務塊的指令 （ 一旦執行exec後，之前加的監控鎖都會被取消掉 ） discard # 取消事務，放棄事務塊中的所有指令 unwatch # 取消watch對所有key的監控
6.0
若在事務隊列中存在指令性錯誤（類似于java編譯性錯誤），則執行EXEC指令時，所有指令都不會
執行
若在事務隊列中存在文法性錯誤（類似于java的1/0的運作時異常），則執行EXEC指令時，其他正确
指令會被執行，錯誤指令抛出異常。
7.0
Watch 監控
悲觀鎖：
悲觀鎖(Pessimistic Lock),顧名思義，就是很悲觀，每次去拿資料的時候都認為别人會修改，是以每次在
拿資料的時候都會上鎖，這樣别人想拿到這個資料就會block直到它拿到鎖。傳統的關系型資料庫裡面就
用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在操作之前先上鎖。
樂觀鎖：
樂觀鎖(Optimistic Lock),顧名思義，就是很樂觀，每次去拿資料的時候都認為别人不會修改，是以不會
上鎖。但是在更新的時候會判斷一下再此期間别人有沒有去更新這個資料，可以使用版本号等機制，樂
觀鎖适用于多讀的應用類型，這樣可以提高吞吐量，樂觀鎖政策：送出版本必須大于記錄目前版本才能
執行更新
小結
watch指令類似于樂觀鎖，在事務送出時，如果watch監控的多個KEY中任何KEY的值已經被其他用戶端
更改，則使用EXEC執行事務時，事務隊列将不會被執行，同時傳回Nullmulti-bulk應答以通知調用者事
務執行失敗。
8.0
Redis 釋出訂閱
是什麼
下圖展示了頻道 channel1 ， 以及訂閱這個頻道的三個用戶端 —— client2 、 client5 和 client1 之間的
關系：
當有新消息通過 PUBLISH 指令發送給頻道 channel1 時， 這個消息就會被發送給訂閱它的三個客戶
端：
9.0
原理
Redis是使用C實作的，通過分析 Redis 源碼裡的 pubsub.c 檔案，了解釋出和訂閱機制的底層實作，籍
此加深對 Redis 的了解。
Redis 通過 PUBLISH 、SUBSCRIBE 和 PSUBSCRIBE 等指令實作釋出和訂閱功能。
通過 SUBSCRIBE 指令訂閱某頻道後，redis-server 裡維護了一個字典，字典的鍵就是一個個 channel
，而字典的值則是一個連結清單，連結清單中儲存了所有訂閱這個 channel 的用戶端。SUBSCRIBE 指令的關
鍵，就是将用戶端添加到給定 channel 的訂閱連結清單中。
通過 PUBLISH 指令向訂閱者發送消息，redis-server 會使用給定的頻道作為鍵，在它所維護的 channel
字典中查找記錄了訂閱這個頻道的所有用戶端的連結清單，周遊這個連結清單，将消息釋出給所有訂閱者。
Pub/Sub 從字面上了解就是釋出（Publish）與訂閱（Subscribe），在Redis中，你可以設定對某一個
key值進行消息釋出及消息訂閱，當一個key值上進行了消息釋出後，所有訂閱它的用戶端都會收到相應
的消息。這一功能最明顯的用法就是用作實時消息系統，比如普通的即時聊天，群聊等功能。
使用場景
Pub/Sub建構實時消息系統
Redis的Pub/Sub系統可以建構實時的消息系統
比如很多用Pub/Sub建構的實時聊天系統的例子。
10.0
Redis主從複制
概念
主從複制，是指将一台Redis伺服器的資料，複制到其他的Redis伺服器。前者稱為主節點
(master/leader)，後者稱為從節點(slave/follower)；資料的複制是單向的，隻能由主節點到從節點。
Master以寫為主，Slave 以讀為主。
預設情況下，每台Redis伺服器都是主節點；且一個主節點可以有多個從節點(或沒有從節點)，但一個從
節點隻能有一個主節點。
主從複制的作用主要包括：
1、資料備援：主從複制實作了資料的熱備份，是持久化之外的一種資料備援方式。
2、故障恢複：當主節點出現問題時，可以由從節點提供服務，實作快速的故障恢複；實際上是一種服務
的備援。
3、負載均衡：在主從複制的基礎上，配合讀寫分離，可以由主節點提供寫服務，由從節點提供讀服務
（即寫Redis資料時應用連接配接主節點，讀Redis資料時應用連接配接從節點），分擔伺服器負載；尤其是在寫
少讀多的場景下，通過多個從節點分擔讀負載，可以大大提高Redis伺服器的并發量。
4、高可用基石：除了上述作用以外，主從複制還是哨兵和叢集能夠實施的基礎，是以說主從複制是
Redis高可用的基礎。
一般來說，要将Redis運用于工程項目中，隻使用一台Redis是萬萬不能的，原因如下：
1、從結構上，單個Redis伺服器會發生單點故障，并且一台伺服器需要處理所有的請求負載，壓力較
大；
2、從容量上，單個Redis伺服器記憶體容量有限，就算一台Redis伺服器記憶體容量為256G，也不能将所有
記憶體用作Redis存儲記憶體，一般來說，單台Redis最大使用記憶體不應該超過20G。
電商網站上的商品，一般都是一次上傳，無數次浏覽的，說專業點也就是"多讀少寫"。
對于這種場景，我們可以使如下這種架構：
10.0
哨兵模式
概述
主從切換技術的方法是：當主伺服器當機後，需要手動把一台從伺服器切換為主伺服器，這就需要人工
幹預，費事費力，還會造成一段時間内服務不可用。這不是一種推薦的方式，更多時候，我們優先考慮
哨兵模式。Redis從2.8開始正式提供了Sentinel（哨兵） 架構來解決這個問題。
謀朝篡位的自動版，能夠背景監控主機是否故障，如果故障了根據投票數自動将從庫轉換為主庫。
哨兵模式是一種特殊的模式，首先Redis提供了哨兵的指令，哨兵是一個獨立的程序，作為程序，它會獨
立運作。其原理是哨兵通過發送指令，等待Redis伺服器響應，進而監控運作的多個Redis執行個體。
這裡的哨兵有兩個作用
通過發送指令，讓Redis伺服器傳回監控其運作狀态，包括主伺服器和從伺服器。
當哨兵監測到master當機，會自動将slave切換成master，然後通過釋出訂閱模式通知其他的從服
務器，修改配置檔案，讓它們切換主機。
然而一個哨兵程序對Redis伺服器進行監控，可能會出現問題，為此，我們可以使用多個哨兵進行監控。
各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。
假設主伺服器當機，哨兵1先檢測到這個結果，系統并不會馬上進行failover過程，僅僅是哨兵1主觀的認
為主伺服器不可用，這個現象成為主觀下線。當後面的哨兵也檢測到主伺服器不可用，并且數量達到一
定值時，那麼哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover[故障轉移]操作。
切換成功後，就會通過釋出訂閱模式，讓各個哨兵把自己監控的從伺服器實作切換主機，這個過程稱為
客觀下線。
優點
- 哨兵叢集模式是基于主從模式的，所有主從的優點，哨兵模式同樣具有。
- 主從可以切換，故障可以轉移，系統可用性更好。
-
哨兵模式是主從模式的更新，系統更健壯，可用性更高。
缺點
- Redis較難支援線上擴容，在叢集容量達到上限時線上擴容會變得很複雜。
- 實作哨兵模式的配置也不簡單，甚至可以說有些繁瑣
**10.0**
Jedis
Jedis是Redis官方推薦的Java連接配接開發工具。要在Java開發中使用好Redis中間件，必須對Jedis熟悉才能
寫成漂亮的代碼
11.0
SpringBoot整合
在SpringBoot中一般使用RedisTemplate提供的方法來操作Redis。那麼使用SpringBoot整合Redis需要
那些步驟呢。
1、 JedisPoolConfig (這個是配置連接配接池)
2、 RedisConnectionFactory 這個是配置連接配接資訊，這裡的RedisConnectionFactory是一個接
口，我們需要使用它的實作類，在SpringD Data Redis方案中提供了以下四種工廠模型：
JredisConnectionFactory
JedisConnectionFactory
LettuceConnectionFactory
SrpConnectionFactory
3、 RedisTemplate 基本操作
yaml配置
spring:
redis:
host: 127.0.0.1
port: 6379
password: 123456
jedis:
pool:
max-active: 8
max-wait: -1ms
max-idle: 500
min-idle: 0
lettuce:
shutdown-timeout: 0ms
12.0
寫一個Redis工具類（直接用RedisTemplate操作Redis，需要很多行代碼，是以直接封裝好一個
RedisUtils，這樣寫代碼更友善點。這個RedisUtils交給Spring容器執行個體化，使用時直接注解注入。）
一些工具類見下