一、redis是什么

redis是一種支持Key-Value等多種資料結構的存盤系統，可用于快取，事件發布或訂閱，高速佇列等場景，該資料庫使用ANSI C語言撰寫，支持網路，提供字串，哈希，串列，佇列，集合結構直接存取，基于記憶體，可持久化，

redis是一個非關系型的資料庫(not-only-sql即nosql),以鍵值對的方式存盤資料,將資料存放在記憶體中,存取速度快,但是對持久化的支持不夠好,所以redis一般配合關系型資料庫使用，redis可以做分布式快取,用在資料量大,高并發的情況下.redis通過很多命令進行操作,而且redis不適合保存內容大的資料.

二、redis的應用場景有哪些

1. 會話快取（最常用）；
2. 訊息佇列；
3. 活動排行榜或計數；
4. 發布，訂閱訊息（訊息通知）；
5. 商品串列，評論串列等

三、redis資料型別

Redis一共支持五種資料類：string（字串），hash（哈希），list（串列），set（集合）和zset（sorted set有序集合），

1. 字串（字串）

它是redis的最基本的資料型別，一個鍵對應一個值，需要注意是一個鍵值最大存盤512MB
使用場景：常規key-value快取應用，一般用于常規計數: 微博數, 粉絲數

2. hash（哈希）

hash是一個鍵值對的集合，是一個string型別的field和value的映射表，適合用于存盤物件

3. 表

是redis的簡單的字串串列，它按插入順序排序
使用場景： 可以輕松地實作最新訊息排行等功能，另一個應用就是訊息佇列

4.集合

是字串型別的無序集合，也不可重復
利用Redis提供的Set資料結構，可以存盤一些集合性的資料，在微博應用中，可以將一個用戶所有的關注人存在一個集合中，將其所有粉絲存在一個集合，Redis還為集合提供了求交集、并集、差集等操作，可以非常方便的實作如共同關注、共同喜好、二度好友等功能，對上面的所有集合操作，你還可以使用不同的命令選擇將結果回傳給客戶端還是存集到一個新的集合中

5. sorted set有序集合

和Set相比，Sorted Set增加了一個權重引數score，使得集合中的元素能夠按score進行有序排列并且是插入有序的，即自動排序，
使用場景：集合value可以是同學的學號，而score就可以是其考試得分，這樣在資料插入集合的時候，就已經進行了天然的排序，或者用Sorted Set來做帶權重的佇列，比如普通訊息的score為1，重要訊息的score為2，然后作業執行緒可以選擇按score的倒序來獲取作業任務，這樣就做到了讓重要的任務優先執行的效果

四、redis的服務相關的命令

slect＃選擇資料庫（資料庫編號0-15）
退出＃退出連接
資訊＃獲得服務的資訊與統計
monitor＃實時監控
config get＃獲得服務配置
flushdb＃洗掉當前選擇的資料庫中的key
flushall＃洗掉所有資料庫中的鍵

五、redis的發布與訂閱

redis的發布與訂閱（發布/訂閱）是它的一種訊息通信模式，一方發送資訊，一方接收資訊，
下圖是三個客戶端同時訂閱同一個頻道

六、redis的發布與訂閱

redis的發布與訂閱（發布/訂閱）是它的一種訊息通信模式，一方發送資訊，一方接收資訊，
下圖是三個客戶端同時訂閱同一個頻道

七、redis的持久化

redis持久有兩種方式：快照（快照）、僅附加檔案（AOF）

快照（RDB）

快照形式，定期把記憶體中當前時刻的資料保存到磁盤，Redis默認支持的持久化方案，速度快但是服務器斷電的時候會丟失部分資料

1. 將存盤在記憶體的資料以快照的方式寫入二進制檔案中，如默認dump.rdb中
2. 900秒內如果超過1個Key被修改，則啟動快照保存
3. 300秒內如果超過10個Key被修改，則啟動快照保存
4. 60秒內如果超過10000個重點被修改，則啟動快照保存

僅附加檔案（AOF）

append only
file，把所有對redis資料庫操作的命令，增刪改操作的命令，保存到檔案中，資料庫恢復時把所有的命令執行一遍即可，兩種持久化方案同時開啟使用AOF檔案來恢復資料庫.能保證資料的完整性,但是速度慢

1. 使用AOF持久時，服務會將每個收到的寫命令通過寫函式追加到檔案中（appendonly.aof）
2. AOF持久化存盤方式引數說明

appendonly yes ＃開啟AOF持久化存盤方式 
appendfsync always ＃收到寫命令后就立即寫入磁盤，效率最差，效果最好
appendfsync everysec  ＃每秒寫入磁盤一次，效率與效果居中
appendfsync no ＃完全依賴作業系統，效率最佳，效果沒法保證

redis的單執行緒為什么那么快

redis分客戶端和服務端，一次完整的redis請求事件有多個階段（客戶端到服務器的網路連接–>redis讀寫事件發生–>redis服務端的資料處理（單執行緒）–>資料回傳），平時所說的redis單執行緒模型，本質上指的是服務端的資料處理客戶端和服務器是socket通信方式，socket服務端監聽可同時接受多個客戶端請求也就是說，redis服務同時面對多個redis客戶端連接請求，而redis服務本身是單執行緒運行，

redis 核心就是 如果我的資料全都在記憶體里，我單執行緒的去操作 就是效率最高的，為什么呢，因為多執行緒的本質就是 CPU 模擬出來多個執行緒的情況，這種模擬出來的情況就有一個代價，就是背景關系的切換，對于一個記憶體的系統來說，它沒有背景關系的切換就是效率最高的，redis 用 單個CPU 系結一塊記憶體的資料，然后針對這塊記憶體的資料進行多次讀寫的時候，都是在一個CPU上完成的，所以它是單執行緒處理這個事，在記憶體的情況下，這個方案就是最佳方案使用單執行緒的方式是無法發揮多核CPU 性能, 為了充分利用多核CPU，常常在一臺server上會啟動多個實體(即多個redis行程)，而為了減少切換的開銷，有必要為每個實體(redis行程)指定其所運行的CPU而且因為redis是單執行緒的,所以不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的性能消耗，

總結:CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機器記憶體的大小或者網路帶寬，既然單執行緒容易實作，而且CPU不會成為瓶頸，那就順理成章地采用單執行緒的方案了

解決redis主從結構宕機
如果在主從復制架構中出現宕機的情況，需要分情況看：

從Redis宕機

a)這個相對而言比較簡單，在Redis中從庫重新啟動后會自動加入到主從架構中，自動完成同步資料；

b) 問題？ 如果從庫在斷開期間，主庫的變化不大，從庫再次啟動后，主庫依然會將所有的資料做RDB操作嗎？還是增量更新？（從庫有做持久化的前提下）

不會的，因為在Redis2.8版本后就實作了，主從斷線后恢復的情況下實作增量復制，

主Redis宕機

方法一：手動恢復

1. 在從資料庫中執行SLAVEOFNO ONE命令，斷開主從關系并且將從庫提升為主庫繼續服務
2. 將主庫重新啟動后，執行SLAVEOF命令，將其設定為其他庫的從庫，這時資料就能更新回來

方法二：哨兵功能自動恢復
基本原理是：心跳機制+投票裁決

1. 通過sentinel模式啟動redis后，自動監控master/slave的運行狀態, 已經被集成在redis2.4+的版本中
2. 如果Master例外，則會進行Master-Slave切換，將其中一個Slave作為Master，將之前的Master作為Slave