redis簡介

1、redis是一個開源的使用C語言編寫的，可基于內存也可以持久化的Key-Value數據庫。

2、解壓之后可以使用redis-cli進行啟動

3、Redis是很快的。
原因：完全基于內存。是一種類似于hashmap，它的優勢就是查找和操作地時間復雜度都是o(1).hash表是基于數組+鏈表的實現的。數組在內存中是一塊連續的空間，只要知道查找數據的下標就可快速定位到數據的內存地址，即數組查找數據的時間復雜度為O(1).
采用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的性能消耗；官網解釋為，單線程已經夠快了。沒必要做多線程。
使用多路I/O復用模型，非阻塞IO；
1.阻塞I/O模型
老李去火車站買票，排隊三天買到一張退票。
耗費：在車站吃喝拉撒睡 3天，其他事一件沒干。
2.非阻塞I/O模型
老李去火車站買票，隔12小時去火車站問有沒有退票，三天后買到一張票。耗費：往返車站6次，路上6小時，其他時間做了好多事。
3.I/O復用模型
1.select/poll
老李去火車站買票，委托黃牛，然后每隔6小時電話黃牛詢問，黃牛三天內買到票，然后老李去火車站交錢領票。
耗費：打電話
2.epoll
老李去火車站買票，委托黃牛，黃牛買到后即通知老李去領，然后老李去火車站交錢領票。
耗費：無需打電話

4、 redis數據結構
redis是一種高級的key-value存儲系統，其中支持5種不同的數據類型

字符串（string）
列表（list）
字符串集合（set）
有序字符串結合（sorted set）
哈希（hash）

5、redis數據結構 string
字符串可以存儲以下3種類型的值。

字符串（byte string）
整型
浮點型

6、redis數據結構 list
redis允許用戶從序列的兩端推入或者彈出元素

7、redis數據結構 set
redis的集合，是一種無序的集合，集合中的元素沒有先后順序。集合成員是唯一的，這就意味著集合中不能出現重復的數據。

8、redis數據結構 sorted set
Redis 有序集合和集合一樣也是string類型元素的集合,且不允許重復的成員。有序集合的成員是唯一的,但分數(score)卻可以重復。

9、redis數據結構 hash
Redis hash 是一個 string 類型的 field 和 value 的映射表，hash 特別適合用于存儲對象。

10、redis持久化
redis為持久化提供兩種方式：

RDB： 存在于某一個時刻的所有數據全部寫入到磁盤中。
AOF： 在執行寫命令的時候，將被執行的命令復制到磁盤里面。當服務器重啟時會重新執行這些命令來恢復數據。
當RDB與AOF同時使用的情況下，如果redis重啟，則會優先采用AOF進行數據恢復，因為AOF方式的數據恢復完整度更高。

11、持久化之RDB

RDB持久化配置
優勢：只有一個文件，時間間隔的數據，可以歸檔為一個文件，方便壓縮轉移（就一個文件）

劣勢：如果宕機，數據損失比較大，因為它是沒一個時間段進行持久化操作的。也就是積攢的數據比較多，一旦懵逼，就徹底懵逼了

總結
平時我們可以定期把rdb文件（不重要的數據）備份到指定地方，需要恢復的時候 直接把rdb搞到redis下即可。而重要的數據則存放到數據庫中。

#時間策略
save 900 1
save 300 10
save 60 10000#save 900 1 表示900s內如果有1條是寫入命令，就觸發產生一次快照，可以理解為就進行一次備份#save 300 10 表示300s內有10條寫入，就產生快照
#文件名稱
dbfilename dump.rdb
#文件保存路徑
dir /home/work/app/redis/data/
#如果持久化出錯，主進程是否停止寫入
stop-writes-on-bgsave-error yes# 這個配置也是非常重要的一項配置，這是當備份進程出錯時，主進程就停止接受新的寫入操作，是為了保護持久化的數據一致性問題。如果自己的業務有完善的監控系統，可以禁止此項配置， 否則請開啟。# 是否壓縮
rdbcompression yes#rdbcompression yes ，建議沒有必要開啟，畢竟Redis本身就屬于CPU密集型服務器，再開啟壓縮會帶來更多的CPU消耗，相比硬盤成本，CPU更值錢。
#導入時是否檢查
rdbchecksum yes

在redis中RDB持久化促發分為兩種：自己手動觸發與redis定時觸發。

手動觸發可以使用
save：會阻塞當前Redis服務器，直到持久化完成，線上應該禁止使用。
bgsave：該觸發方式會fork一個子進程，由子進程負責持久化過程，因此阻塞只會發生在fork子進程的時候。
自動觸發主要有
根據我們的 save m n 配置規則自動觸發；
從節點全量復制時，主節點發送rdb文件給從節點完成復制操作，主節點會觸發 bgsave；
執行 debug reload 時；
執行 shutdown時，如果沒有開啟aof，也會觸發。
運行流程圖

12、持久化之AOF
當 AOF 持久化功能處于打開狀態時， 服務器在執行完一個寫命令之后， 會以協議格式將被執行的寫命令追加到服務器狀態的 aof_buf 緩沖區的末尾。

(1)當 appendfsync 的值為 always 時， 服務器在每個事件循環都要將 aof_buf 緩沖區中的所有內容寫入到 AOF 文件， 并且同步 AOF 文件， 所以 always 的效率是 appendfsync 選項三個值當中最慢的一個， 但從安全性來說， always 也是最安全的， 因為即使出現故障停機， AOF 持久化也只會丟失一個事件循環中所產生的命令數據。

(2)當 appendfsync 的值為 everysec 時， 服務器在每個事件循環都要將 aof_buf 緩沖區中的所有內容寫入到 AOF 文件， 并且每隔超過一秒就要在子線程中對 AOF 文件進行一次同步： 從效率上來講， everysec 模式足夠快， 并且就算出現故障停機， 數據庫也只丟失一秒鐘的命令數據。

(3)當 appendfsync 的值為 no 時， 服務器在每個事件循環都要將 aof_buf 緩沖區中的所有內容寫入到 AOF 文件， 至于何時對 AOF 文件進行同步， 則由操作系統控制。

因為處于 no 模式下的 flushAppendOnlyFile 調用無須執行同步操作， 所以該模式下的 AOF 文件寫入速度總是最快的， 不過因為這種模式會在系統緩存中積累一段時間的寫入數據， 所以該模式的單次同步時長通常是三種模式中時間最長的： 從平攤操作的角度來看， no 模式和 everysec 模式的效率類似， 當出現故障停機時， 使用 no 模式的服務器將丟失上次同步 AOF 文件之后的所有寫命令數據。

還原數據邏輯：

1.創建一個不帶網絡連接的偽客戶端（fake client）。

2.讀取 AOF 所保存的文本，并根據內容還原出命令、命令的參數以及命令的個數。

3.根據命令、命令的參數和命令的個數，使用偽客戶端執行該命令。

4.執行 2 和 3 ，直到 AOF 文件中的所有命令執行完畢。

完成第 4 步之后， AOF 文件所保存的數據庫就會被完整地還原出來

AOF持久化配置

#是否開啟aof
appendonly yes
#文件名稱
appendfilename “appendonly.aof”
#同步方式
appendfsync everysec#三種模式#always：把每個寫命令都立即同步到aof，很慢，但是很安全#everysec：每秒同步一次，是折中方案#no：redis不處理交給OS來處理，非常快，但是也最不安全
#aof重寫期間是否同步
no-appendfsync-on-rewrite no
#重寫觸發配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
#加載aof時如果有錯如何處理
aof-load-truncated yes
#文件重寫策略
aof-rewrite-incremental-fsync yes

運行流程圖

重點回顧
·AOF文件通過保存所有修改數據庫的寫命令來記錄服務器的數據庫狀態
·AOF文件中所有命令都以Redis命令請求協議的格式保存
·命令請求會先保存到AOF緩沖區里面，之后再定期寫入并同步到AOF文件。
·appendfsync選項的不同值對AOF持久化功能的安全性以及Redis服務器的性能有很大的影響
·服務器只要載入并重新執行保存在AOF文件中的命令，就可以還原數據庫本來的狀態
·AOF重寫可以產生一個新的AOF文件，這個新的AOF文件就是當前數據庫狀態的dump，所以垃圾冗余數據被清理了
·AOF重寫是一個有歧義的名字，該功能是通過dump數據庫所有建值對實現的，程序無需對現有AOF文件進行任何操作。
·執行BGREWRITEAOF命令時，Redis服務器會維護一個AOF重寫緩沖區，以保證數據一致性。

13、Redis主從復制
　　（1）概述：
　　　　redis的復制功能是支持多個數據庫之間的數據同步。一類是主數據庫（master）一類是從數據庫（slave），主數據庫可以進行讀寫操作，當發生寫操作的時候自動將數據同步到從數據庫，而從數據庫一般是只讀的，并接收主數據庫同步過來的數據，一個主數據庫可以有多個從數據庫，而一個從數據庫只能有一個主數據庫。
　　　　通過redis的復制功能可以很好的實現數據庫的讀寫分離，提高服務器的負載能力。主數據庫主要進行寫操作，而從數據庫負責讀操作。
過程：

1：當一個從數據庫啟動時，會向主數據庫發送sync命令，
　　　　2：主數據庫接收到sync命令后會開始在后臺保存快照（執行rdb操作），并將保存期間接收到的命令緩存起來
　　　　3：當快照完成后，redis會將快照文件和所有緩存的命令發送給從數據庫。
　　　　4：從數據庫收到后，會載入快照文件并執行收到的緩存的命令。
Redis的哨兵(sentinel) 系統用于管理多個 Redis 服務器,該系統執行以下三個任務:

· 監控(Monitoring): 哨兵(sentinel) 會不斷地檢查你的Master和Slave是否運作正常。

· 提醒(Notification):當被監控的某個 Redis出現問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應用程序發送通知。

· 自動故障遷移(Automatic failover):當一個Master不能正常工作時，哨兵(sentinel) 會開始一次自動故障遷移操作,它會將失效Master的其中一個Slave升級為新的Master, 并讓失效Master的其他Slave改為復制新的Master; 當客戶端試圖連接失效的Master時,集群也會向客戶端返回新Master的地址,使得集群可以使用Master代替失效Master。

14、Redis 事務機制
MULTI 用于標記事務的開始，其后執行的命令都將被存入命令隊列，直到執行EXEC時，這些命令才會被原子執行.

EXEC 執行在一個事務內命令執行了WATCH命令，那么只有當WATCH所監控的keys沒有被修改的前提下，EXEC命令才能執行事務隊列中的所有命令，那么只有
當WATCH所監控的keys沒有被修改的前提下，EXEC命令才能執行事務隊列中的所有命令，否則EXEC將放棄當前事務中的所有命令。

DISCARD 回滾事務隊列中的所有命令，同時再將當前連接的狀態恢復為正常狀態，即非事務狀態。如 果WATCH命令被使用，該命令將UNWATCH所有的keys.

Watch 監視一個(或多個) key ，如果在事務執行之前這個(或這些) key 被其他命令所改動，那么事務將被打斷。
事務對異常的處理機制
Redis執行命令的錯誤主要分為兩種：

• 1.命令錯誤：執行命令語法錯誤，比如說將 set 命令寫成 sett
• 2.運行時錯誤：命令語法正確，但是執行錯誤，比如說對 List 集合執行 sadd 命令

Redis事務中如果發生上面兩種錯誤，處理機制也是不同的。

1）命令錯誤處理機制
這種情況需要區別Redis版本，Redis2.65之前的版本會忽略錯誤的命令，執行其他正確的命令，2.65之后的版本會忽略這個事務中的所有命令，都不執行，就比如上面的例子(使用的Redis版本是2.8的)；

（2）運行時錯誤處理機制
運行錯誤表示命令執行過程中出現錯誤，就比如用GET命令去獲取一個散列表類型的鍵值。

這種錯誤在命令執行之前Redis是無法發現的，所以在事務里這樣的命令都會被Redis接受并執行.如果事務里有一條命令執行錯誤，Redis不僅不會回滾事務，還會跳過這個運行時錯誤，其他命令依舊會執行(包括出錯后的命令)。

樂觀鎖和共享鎖
樂觀鎖(Optimistic Lock)又叫做共享鎖，每次別人拿數據的時候都認為別人不會修改數據，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。樂觀鎖適用于多讀得應用類型，這樣會提高吞吐量。

悲觀鎖(Pessimistic Lock)又叫做排它鎖（x鎖），每次拿刀數據的時候都認為別人會修改數據，所以每次在拿到數據的時候都會上鎖，這樣別人想拿到這個數據就會block直到
它拿到鎖。傳統的關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖，都是在操作之前先上鎖。

總結

以上是生活随笔為你收集整理的redis简介-各种基础的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。