redis
目錄
1.1-什麼是redis
redis是一個key-value存儲的非關係型數據庫，先把數據存到內存中，會根據一定的策略持久化到磁盤，即使斷電也不會丟失數據，支持的數據類型也比較多。
1.2-redis緩存代碼
1.3-redis的功能
主要用來緩存數據庫數據和web集羣式來當做中央緩存存放session
1.4-redis的使用
把經常需要查詢的數據，放到讀取速度比較快的空間（內存），以便下次訪減少時間，減輕壓力，減少訪問時間。
1.5-redis的使用場景
-
計數器
-
Session緩存服務器
1.6-redis對象保存的方式
Json字符串:
需要把對象轉換爲json對象，當作字符串處理，直接使用get或者set來設置或者獲取
序列化：
需要做序列化，把對象序列化爲對象保存
使用Json字符串方式的優缺點:
-
優點：設置和獲取比較簡單
-
缺點：沒有用提供專門的方法需要把對象轉換爲json
1.7-redis的數據淘汰機制
內存大小優先，需要保存有效的數據
-
volatile-lru：從已設置過期時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰
-
volatile-ttl：從已設置過期時間的數據集（server.db[i].expires）中挑選將要過期的數據淘汰
-
volatile-random：從已設置過期時間的數據集（server.db[i].expires）中任意選擇數據淘汰
-
allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰
-
allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰
-
no-enviction（驅逐）：禁止驅逐數據
1.8-redis的優缺點
優點：
- 讀取性能快（讀110000次/s，寫81000次/s）；
- 支持數據持久化；
- 數據結構簡單，對數據操作也簡單
- 支持事務，所有的操作都是原子性的，數據的更改要麼全部執行，要麼全部不執行；
- 支持主從複製，主機會自動將數據同步到從機，可以進行讀寫分離；
缺點：
- 會受到內存的影響，只能適用於存儲比較小的數據量Redis
- 只要斷電數據就丟失，或者說重啓Redis原來的數據也不會保存，不具備自動容錯和恢復功能，主機從機的宕機都會導致前端部分讀寫請求失敗，需要等待機器重啓或者手動切換前端的IP才能恢復。
- 緩存和數據庫雙寫一致性問題，主機宕機，宕機前有部分數據未能及時同步到從機，切換IP後還會引入數據不一致的問題，降低了系統的可用性。
- Redis 較難支持在線擴容，在集羣容量達到上限時在線擴容會變得很複雜。爲避免這一問題，運維人員在系統上線時必須確保有足夠的空間，這對資源造成了很大的浪費。
1.9-單線程的redis爲什麼這麼快
-
純內存操作
-
避免了頻繁的上下文切換
-
採用了非阻塞I/O多路複用機制
1.10-redis的數據類型
字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。
1.11-redis持久化
將Redis的數據從內存存儲到磁盤，防止服務宕機了內存數據丟失。
1.12-使用持久化的目的
- redis的數據存儲在內存中，讀寫的熟讀很快，高效率
- 爲了解決數據丟失的問題，同時啓動時能夠加載上次數據
1.13-redis的持久化流程
-
客戶端向服務端發送在內存中的數據的寫請求操作
-
服務端收到寫請求操作的數據；
-
服務端調用write這個系統調用，將數據往磁盤上寫，數據還在內存的緩衝區；（如果redis數據庫發生故障，後面兩步驟系統代替完成）
-
操作系統將緩衝區中的數據轉移到磁盤控制器上，數據在磁盤中；
-
磁盤控制器將數據寫到磁盤的物理介質中，到了這一步纔是真正的到達磁盤中；
1.14-redis的持久化機制有哪些
redis的持久化方式有兩種：
-
一種是全量式（快照式）：RDB
-
一種是增量式（日誌式）：AOF
1.15-RDB機制
指在指定的時間間隔內將內存中的數據集快照寫入磁盤，數據恢復時將快照文件直接再讀到內存
1.16-RDB的三種觸發機制
save、bgsave、自動化
save觸發方式：該命令會阻塞當前Redis服務器，執行save命令期間，Redis不能處理其他命令，直到RDB過程完成爲止。
bgsave觸發方式：執行該命令時，Redis會在後臺異步進行快照操作，快照同時還可以響應客戶端請求
自動觸發：自動觸發是由我們的配置文件來完成的。
1.17-RDB的優點
- 適合用於備份和災難恢復；
- 生成RDB文件的時候，redis主進程會fork()一個子進程來處理所有保存工作，主進程不需要進行任何磁盤IO操作；
- RDB恢復數據快
1.18-RDB的缺點
- 因爲是全量備份，內存緊湊；
- 快照持久化期間修改的數據不會被保存，可能丟失數據；
1.19-AOF機制
每次接收到一條改變數據的命令時，它將把該命令寫到一個 AOF 文件中，當 Redis 重啓時，它通過執行 AOF 文件中所有的命令來恢復數據。
1.20-AOF的三種觸發機制
always，everysec，no
always（每修改同步）：同步持久化 每次發生數據變更會被立即記錄到磁盤 性能較差但數據完整性比較好
每秒同步everysec（每秒同步）：異步操作，每秒記錄 如果一秒內宕機，有數據丟失
no（不同步）：從不同步
1.21-AOF的優點
- 對數據保護的更好，不容易丟失，即使丟失也是隻丟失1秒的數據
- AOF文件過大導致重寫操作的時候，不會影響客戶端的讀寫操作
- 可以通過恢復機制，自動恢復所有數據
1.22-AOF的缺點
- AOF的文件會比較大
- 性能比RDB低
1.23-RDB和AOF的選擇
RDB的體積小，恢復速度快，但是容易丟失數據，AOF的體積比較大，恢復速度慢，可以更好地保護數據，以防止丟失，RDB相對於AOF來說效率更高，建議晚上服務器壓力不大的時候可以使用全量持久化，白天使用增量持久化。
1.24-什麼是redis集羣
集羣：通過使用多臺計算機處理一件事情，來擴展系統的性能，這種方式稱爲集羣
redis集羣：Redis 集羣是一個分佈式（distributed）、容錯（fault-tolerant）的 Redis 實現， 集羣可以使用的功能是普通單機 Redis 所能使用的功能的一個子集（subset）
1.25-集羣可以解決的問題
- 讀寫分離：通過集羣，主服務器提供寫服務，從服務器提供讀服務。提高系統吞吐量
- 提高可用性：即使某一臺服務器宕機，其他服務器還能夠代替這臺機器工作
- 提高系統性能：一臺機器處理不了那麼多數據，多臺機器處理
1.26-集羣的方式
主從複製，哨兵，Cluster，除了三個redis自身的功能外，還有國人開發的Condis
詳細點擊鏈接參考:https://www.cnblogs.com/51life/p/10233340.html
1.27-什麼是CAP原則
一個分佈式系統不可能同時滿足一致性（C），可用性(A)和分區容錯性(P)這三個基本需求，最多隻能同時滿足其中的2個。
一致性(C):數據在多個副本之間能夠保持一致的特性。
可用性(A) ：系統提供的服務必須一直處於可用的狀態，每次請求都能獲取到非錯的響應——但是不保證獲取的數據爲最新數據。
分區容錯性(P)：分佈式系統在遇到任何網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務，除非整個網絡環境都發生了故障。
1.28- Redis集羣保證了CAP的什麼
redis集羣是通過犧牲一致性來保證可用性和分區容錯性。無法保證強一致性，只能保證最終一致性（主從服務器始終無法保證一致保持數據一致，所以選擇最終從服務器與主服務器數據一致）
1.29-Redis集羣會有寫操作丟失嗎？
redis並不能保證數據的強一致性，所以在實際中集羣在特定的條件下可能會丟失寫操作。
1.30-大量的key需要設置同一時間過期，一般需要注意
如果我們把打倆ing的Key過期時間設在同一時間，時間一到，服務器會暫時性壓力過大，redis會出現短暫的卡頓現象，嚴重的話會出現緩存雪崩，所以我們可以設置隨機值，讓過期時間都有所不同，不要再同一時間。