0. redis與mysql區(qū)別

1.數(shù)據(jù)庫(kù)類型MySQL是關(guān)系型數(shù)據(jù)庫(kù)Redis是緩存數(shù)據(jù)庫(kù)（非關(guān)系型數(shù)據(jù)庫(kù)）
2.數(shù)據(jù)存放位置MySQL：數(shù)據(jù)存放在磁盤中Redis：數(shù)據(jù)存放在內(nèi)存中
3.支持?jǐn)?shù)據(jù)類型MySQL：數(shù)值、日期/時(shí)間、字符串Redis：String、Hash、List、Set、Zset

1. redis是單線程架構(gòu)還是多線程架構(gòu)

redis6.0版本之前是單線程，這里的單線程指的是網(wǎng)絡(luò)IO和鍵值對(duì)讀寫命令是由一個(gè)線程完成的
redis6.0版本之前之后是多線程，這里的多線程指的是在網(wǎng)絡(luò)IO請(qǐng)求過程中采用了多線程，但是鍵值對(duì)讀寫命令仍然是單線程的，并且持久化、集群數(shù)據(jù)同步、異步刪除都是由額外的線程完成的。

所以redis仍然是線程安全的

2. redis單線程為什么這么快

1. 命令執(zhí)行基于內(nèi)存操作，單條命令操作時(shí)間是幾十納秒

2. 命令執(zhí)行是單線程操作，避免了多線程上下文切換開銷

3. 高效的數(shù)據(jù)結(jié)構(gòu)，包括全局Hash表、簡(jiǎn)單動(dòng)態(tài)字符串、雙向鏈表、跳躍表、整數(shù)數(shù)組

4. 基于IO多路復(fù)用技術(shù)，能夠保證大量并發(fā)下的效率，提高系統(tǒng)的吞吐量

3. redis過期key刪除策略

1.惰性刪除:	key達(dá)到過期時(shí)間，不會(huì)被立即刪除，只有當(dāng)讀寫到這個(gè)已經(jīng)過期的key時(shí)，才會(huì)觸發(fā)惰性刪除策略刪除該key2.定時(shí)刪除:	由于惰性刪除策略無法保證冷數(shù)據(jù)被及時(shí)刪掉，所以Redis會(huì)定期(默認(rèn)每100ms)主動(dòng)淘汰一批已過期的key,這里的一批只是部分過期key,所以可能會(huì)出現(xiàn)部分key已經(jīng)過期但仍然還沒有被清理掉的情況3.主動(dòng)刪除:	當(dāng)redis已用內(nèi)存超過maxmemory限定時(shí)，觸發(fā)主動(dòng)清理策略，共8種內(nèi)存淘汰策略
a)針對(duì)設(shè)置了過期時(shí)間的key1. volatile-ttl:	在設(shè)置了過期時(shí)間的鍵值對(duì)，根據(jù)過期時(shí)間的先后進(jìn)行刪除，越早過期的越先被刪除。2. volatile-random:	在設(shè)置了過期時(shí)間的鍵值對(duì)，進(jìn)行隨機(jī)刪除。3. volatile-lru:	會(huì)使用LRU算法篩選設(shè)置了過期時(shí)間的鍵值對(duì)刪除。4. volatile-lfu:	會(huì)使用LFU算法篩選設(shè)置了過期時(shí)間的鍵值對(duì)刪除。b)針對(duì)所有的key5. allkeys-random:	從所有鍵值對(duì)中隨機(jī)選擇并刪除數(shù)據(jù)。6. allkeys-lru:		使用LRU算法在所有數(shù)據(jù)中進(jìn)行篩選刪除。7. allkys-lfu:		使用LFU算法在所有數(shù)據(jù)中進(jìn)行篩選刪除。c)不處理8. noeviction:不會(huì)剔除任何數(shù)據(jù)，拒絕所有寫入操作并返回客戶端錯(cuò)誤信息，此時(shí)Redis只響應(yīng)讀操作。LRU算法(Least Recently Used,最近最久未使用):		 淘汰很久沒被訪問過的數(shù)據(jù)，以最近-次訪問時(shí)間作為參考
LFU算法(Least Frequently Used,最不經(jīng)常使用):		淘汰最近一段時(shí)間被訪問次數(shù)最少的數(shù)據(jù)，以次數(shù)作為參考
絕大多數(shù)情況我們都可以用LRU策略，當(dāng)存在大量的熱點(diǎn)緩存數(shù)據(jù)時(shí)，LFU可能更好點(diǎn)

4. redis主從復(fù)制架構(gòu)原理

常見的主從復(fù)制架構(gòu)：總體來說，主數(shù)據(jù)庫(kù)Master以寫為主，從數(shù)據(jù)庫(kù)Slave以讀為主，整體負(fù)責(zé)讀寫分離、容災(zāi)恢復(fù)。

case1：一主二仆【中心化架構(gòu)】 slaveof 新主庫(kù)IP 新主庫(kù)端口

case2：薪火相傳【去中心化架構(gòu)】 slaveof 新主庫(kù)IP 新主庫(kù)端口

case3：反客為主 slaveof no one

// 主從數(shù)據(jù)庫(kù)數(shù)據(jù)同步過程
1.全量復(fù)制：【當(dāng)主從服務(wù)器剛建立連接的時(shí)候，進(jìn)行全量數(shù)據(jù)同步】a、首先從服務(wù)器連接到主服務(wù)器，發(fā)送psync命令進(jìn)行數(shù)據(jù)全量同步（Redis2.8之前是sync命令）b、主服務(wù)器收到psync命令之后，執(zhí)行bgsave命令生成RDB快照文件發(fā)送給從服務(wù)器c、從服務(wù)器收到RDB快照文件后，清空內(nèi)存舊數(shù)據(jù)，將接收到的數(shù)據(jù)寫入磁盤2、增量復(fù)制：【全量復(fù)制結(jié)束后，進(jìn)行增量復(fù)制】a、主服務(wù)器每執(zhí)行一個(gè)寫命令就會(huì)向從服務(wù)器發(fā)送相同的寫命令b、從服務(wù)器接收并執(zhí)行收到的寫命令。優(yōu)點(diǎn)：（1）數(shù)據(jù)熱備份：主從復(fù)制實(shí)現(xiàn)了數(shù)據(jù)的熱備份，是持久化之外的一種數(shù)據(jù)冗余方式。（2）故障恢復(fù)：	如果master宕掉了，哨兵模式可以提升一個(gè)新的master，實(shí)現(xiàn)故障轉(zhuǎn)移，達(dá)到高可用。（3）負(fù)載均衡：	可以輕易實(shí)現(xiàn)橫向擴(kuò)展，實(shí)現(xiàn)讀寫分離，一個(gè)master用于寫，多個(gè)slave 用于分?jǐn)傋x的壓力缺點(diǎn)：（1）網(wǎng)絡(luò)延遲：由于所有的寫操作都是先在Master上操作，然后同步更新到Slave上，所以從Master同步到Slave服務(wù)器有一定的延遲（2）如果master宕掉了，普通主從模式無法自動(dòng)切換master，必須使用哨兵模式

5. redis哨兵模式架構(gòu)原理

優(yōu)點(diǎn)：可以動(dòng)態(tài)切換主從庫(kù)，中心型公司首選

缺點(diǎn)：

1. 單個(gè)master主節(jié)點(diǎn)提供寫服務(wù)，redis存儲(chǔ)的數(shù)據(jù)有限(<10G)，并發(fā)量不足(<3w)
2. 自動(dòng)切換主從庫(kù)會(huì)產(chǎn)生訪問瞬斷的情況，切換沒有那么快

工作原理：

	哨兵是一個(gè)分布式系統(tǒng)，可以在一個(gè)架構(gòu)中運(yùn)行多個(gè)哨兵進(jìn)程，這些進(jìn)程使用流言協(xié)議(gossip protocols)來傳播Master是否下線的信息，并使用投票協(xié)議(agreement protocols)來決定是否執(zhí)行自動(dòng)故障遷移以及選擇哪個(gè)Slave作為新的Master。哨兵模式的簡(jiǎn)單工作原理如下：
（1）監(jiān)控：哨兵會(huì)不斷地檢查你的Master和Slave是否運(yùn)作正常。
（2）提醒：當(dāng)被監(jiān)控的某個(gè)Redis節(jié)點(diǎn)出現(xiàn)問題時(shí)，哨兵可以通過 API 向管理員或者其他應(yīng)用程序發(fā)送通知。
（3）自動(dòng)故障遷移：當(dāng)Master不能正常工作時(shí)，哨兵會(huì)進(jìn)行自動(dòng)故障遷移操作，將其中一個(gè)Slave升級(jí)為新的Master  

6. redis高可用集群架構(gòu)原理

1. redis集群是一個(gè)由多個(gè)主從節(jié)點(diǎn)群組成的分布式服務(wù)器群，它具有復(fù)制、高可用和分片存儲(chǔ)特性

2. redis集群將每個(gè)節(jié)點(diǎn)設(shè)置成集群模式，這種集群模式?jīng)]有中心節(jié)點(diǎn)，可水平擴(kuò)展，可線性擴(kuò)展到上萬個(gè)節(jié)點(diǎn)(官方推薦不超過1000個(gè)節(jié)點(diǎn))

3. redis集群的性能和高可用性均優(yōu)于之前版本的哨兵模式，且集群配置非常簡(jiǎn)單。

   大型公司首選

7. redis持久化之RDB

RDB（Redis DataBase）在指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤，也就是行話講的Snapshot快照，它恢復(fù)時(shí)將快照文件 (dump.rdb) 移動(dòng)到redis安裝目錄并啟動(dòng)服務(wù)即可。

save 3600 1		# 15分鐘變動(dòng)1次
save 300 100	# 5分鐘變動(dòng)100次
save 60 10000	# 1分鐘變動(dòng)1w次save				save時(shí)只管保存，其它不管，全部阻塞。
bgsave			Redis會(huì)在后臺(tái)異步進(jìn)行快照操作， 快照同時(shí)還可以響應(yīng)客戶端請(qǐng)求。

RDB優(yōu)點(diǎn)：1、持久化速度快：RDB在保存RDB文件時(shí)父進(jìn)程唯一需要做的就是fork出一個(gè)子進(jìn)程，接下來的工作全部由子進(jìn)程來做，父進(jìn)程不需要再做其他I0操作，所以RDB持久化方式可以最大化redis的性能。[適合大規(guī)模的數(shù)據(jù)持久化]2、恢復(fù)速度快：與AOF相比，RDB是一個(gè)非常緊湊的文件，RDB數(shù)據(jù)恢復(fù)會(huì)更快一些RDB缺點(diǎn)：1、內(nèi)存膨脹：Fork的作用是復(fù)制一個(gè)與當(dāng)前進(jìn)程一樣的進(jìn)程，新進(jìn)程的所有數(shù)據(jù)（變量、環(huán)境變量、程序計(jì)數(shù)器等）數(shù)值都和原進(jìn)程一致，大致2倍的膨脹性需要考慮。2、數(shù)據(jù)丟失：在一定間隔時(shí)間做一次備份，所以如果redis意外down掉的話，就會(huì)丟失最后一次快照后的所有修改

8. redis持久化之AOF

AOF（Append Only File）是以日志的形式來記錄每個(gè)寫操作，將Redis執(zhí)行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件，redis啟動(dòng)之初會(huì)讀取該文件重新構(gòu)建數(shù)據(jù)，換言之，redis 重啟的話就根據(jù)日志文件的內(nèi)容將寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復(fù)工作。

AOF配置【APPEND ONLY MODE】
appendonly no  										# 默認(rèn)no
appendfilename "appendonly.aof" 	# 文件名
appendfsync [always/everysec/no]always		同步持久化，redis每次發(fā)生數(shù)據(jù)改變都會(huì)被立即記錄到磁盤，性能較差但數(shù)據(jù)完整性最好everysec		默認(rèn)推薦，異步操作，每秒記錄一次，最多損失1s的數(shù)據(jù)no			不進(jìn)行持久化
no-appendfsync-on-rewrite no 				# 重寫時(shí)是否運(yùn)用appendfsync，默認(rèn)no即可，保證數(shù)據(jù)安全性
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOF優(yōu)點(diǎn)：每修改同步：appendfsync always 同步持久化 每次發(fā)生數(shù)據(jù)變更會(huì)被立即記錄到磁盤，性能較差但數(shù)據(jù)完整性比較好每秒同步：appendfsync everysec 異步操作，每秒記錄 如果一秒內(nèi)宕機(jī)，有數(shù)據(jù)丟失不同步：appendfsync no 從不同步AOF缺點(diǎn)：1、文件大、恢復(fù)慢：相同數(shù)據(jù)集的數(shù)據(jù)而言aof文件要遠(yuǎn)大于rdb文件，恢復(fù)速度慢于rdb2、Aof運(yùn)行效率要慢于rdb,每秒同步策略效率較好，不同步效率和rdb相同

redis默認(rèn)使用AOF恢復(fù)數(shù)據(jù)，因?yàn)閍of保存的數(shù)據(jù)更全面

9. redis持久化之混合持久化

背景：

1. 重啟Redis時(shí)，我們很少只使用RDB來恢復(fù)內(nèi)存數(shù)據(jù)，因?yàn)檫@會(huì)丟失大量數(shù)據(jù)
2. 通常使用AOF日志重放來恢復(fù)數(shù)據(jù)，但是重放AOF日志性能相對(duì)RDB來說要慢很多,當(dāng)Redis數(shù)據(jù)很大，啟動(dòng)需要花費(fèi)很長(zhǎng)的時(shí)間
   Redis 4.0為了解決這個(gè)問題，帶來了一個(gè)新的持久化選項(xiàng)一混合持久化

實(shí)現(xiàn)步驟：
步驟一：通過如下配置可以開啟混合持久化(必須先開啟aof):aof-use-rdb-preamble yes步驟二：此時(shí)AOF在重寫時(shí)，不再是單純將內(nèi)存數(shù)據(jù)轉(zhuǎn)換為RESP命令寫入AOF文件，而是將重寫這一刻之前的內(nèi)存做RDB
快照處理，并且將RDB快照內(nèi)容和增量的AOF修改內(nèi)存數(shù)據(jù)的命令存在一起，都寫入新的AOF文件步驟三：新的文件一開始不叫appendonly.aof,等到重寫完新的AOF文件才會(huì)進(jìn)行改名,覆蓋原有的AOF文件,完成新舊兩個(gè)AOF文件的替換。步驟四：redis重啟的時(shí)候，可以先加載RDB的內(nèi)容,然后再重放增量AOF日志就可以完全替代之前的AOF全量文件重放,因此重啟效率大幅得到提升。