Redis基礎(chǔ)（下）

Linux命令

1.cd：更改目錄
cd~回到初始目錄
cd … 回到上級(jí)目錄
2.mkdir 創(chuàng)建目錄
3.cp 拷貝文件
eg：cp redis 5.06/redis.conf myredis/
4. ll 查看目錄內(nèi)的文件
5.vim 文本編輯器
兩種模式 ： 命令模式，編輯模式
打開文件時(shí)默認(rèn)時(shí)命令模式，可以查看文件的內(nèi)容，輸入i可以切換為編輯模式，此時(shí)才可以更改文件。按esc可以從編輯模式再切換為命令模式，此時(shí)才可以退出。
退出方式：輸入：+q(如果文件被修改，會(huì)提醒未保存)
不保存，輸入：q！
保存，輸入：wq

Redis配置文件

1.單位的問題
1k/1kb/1m/1mb/1g/1gb是不同的，沒有b的時(shí)候取整，單位的大小寫是不敏感的
網(wǎng)絡(luò)相關(guān)
2.bind 127.0.01 綁定IP地址的意思(能夠訪問服務(wù)端的地址) 當(dāng)前的redis服務(wù)只能被本機(jī)訪問
3.protect - mode yes 開啟保護(hù)模式
當(dāng)bind沒有配置且登錄不需要密碼時(shí)，啟動(dòng)保護(hù)模式（啟動(dòng)保護(hù)模式）
4.port 6379 端口號(hào)
5timeout 0 客戶端超過了 timeout的時(shí)間 0代表不斷掉連接 一直保持
6. tcp - keeplive 300 服務(wù)端對(duì)客戶端的健康檢查 單位是秒，每300s去檢查一次客戶端的健康情況，避免服務(wù)端一直阻塞
7.tcp - backlog 511 隊(duì)列數(shù)量(未完成3次握手和已完成三次握手的)
通用相關(guān)
8.daemonize no 后臺(tái)運(yùn)行開關(guān)
改為yes后重啟redis驗(yàn)證，
redis配置文件的方式為：redis - server /root /myredis /redis.conf
9.pidfile/var/run/redis_6379.pid 當(dāng)守護(hù)進(jìn)程開啟時(shí)，寫入進(jìn)程id的連接地址
10loglevel notice 四種級(jí)別，noctice生產(chǎn)環(huán)節(jié)
11logfile“”日熾存儲(chǔ)的位置
12.databases16初始化數(shù)據(jù)庫16個(gè)

Redis安全和淘汰策略

安全

config命令

是一種從客戶端查看配置項(xiàng)信息的方式，使用 config get，屬于危險(xiǎn)命令，可以限制使用
安全命令
1.config get requirepass 查看密碼
2.config set requirepass${password}操做密碼
3.auth ${password}再執(zhí)行命令前需要授權(quán)
4.config set requirepass “” 設(shè)置空串后恢復(fù)

限制配置

1.maxclients 最大客戶端連接數(shù)，默認(rèn)1w
2.maxmemory 最大內(nèi)存設(shè)置
3.maxmemory - policy 緩存清除策略

安全校驗(yàn)配置

requirepass 代表是否設(shè)置密碼，如果需要設(shè)置密碼 config set requirepass${password}操做密碼
此時(shí)輸入命令前，需要先校驗(yàn)auth ${password}再執(zhí)行命令前需要授權(quán)然后才能執(zhí)行其他操作

危險(xiǎn)命令限制

包含config/flushdb/flushall/keys
rename - command + 命令 +“”將此命令置為不可用

其他限制

1.maxclients 10000 最大并發(fā)數(shù)
2.maxmemory 最大內(nèi)存
3.maxmemory - policy 緩存淘汰策略默認(rèn)值 noeviction （不刪除只報(bào)錯(cuò)）
其他策略主要分兩種情況
allkeys（所有鍵值都可能刪除）
volatile（只刪除設(shè)置了過期時(shí)間的鍵值）

緩存有效期和過期策略

有效期叫做TTL（time to live）
設(shè)置有效期的作用：節(jié)省空間和數(shù)據(jù)弱一致性–有效期失效后保證數(shù)據(jù)的一致性

過期/淘汰策略：

當(dāng)內(nèi)存使用達(dá)到最大值時(shí)，需要使用某種算法來決定清理掉那些數(shù)據(jù)，以保證新數(shù)據(jù)的存入
FIFO
First In First Out 先進(jìn)先出。判斷被存儲(chǔ)的時(shí)間，離目前最遠(yuǎn)的數(shù)據(jù)優(yōu)先被淘汰。
LRU
Least Recently Used
最近最少使用，判斷最近被使用的時(shí)間，目前最遠(yuǎn)的數(shù)據(jù)優(yōu)先被淘汰
LFU
Least Frequently Used
最不經(jīng)常使用。在一段時(shí)間內(nèi)，數(shù)據(jù)被使用次數(shù)最少的，優(yōu)先被淘汰
Redis緩存淘汰策略
volatile(不穩(wěn)定的)，代表會(huì)過期的策略，等價(jià)于設(shè)置了exprire的數(shù)據(jù)

六種策略

1.noeviction：不刪除策略，達(dá)到最大內(nèi)存限制時(shí)，如果需要更多內(nèi)存，直接返回錯(cuò)誤信息。大多數(shù)寫命令都會(huì)導(dǎo)致占用更多的內(nèi)存（有極少數(shù)的會(huì)例外，如DEL）
2.allkeys-lru：所有key通用；優(yōu)先刪除最近最少使用（less recently used ，LRU）的key。
3.volatile-lru：優(yōu)先刪除最近最少使用（less recently used，LRU）的key（限于會(huì)過期的key）
4.allkeys-random：所有key通信；隨機(jī)刪除一部分key
5.volatile-random：隨機(jī)刪除一部分key（限于會(huì)過期的key）
6.volatile-ttl：優(yōu)先刪除剩余時(shí)間（time to live，TTL）短的key（限于會(huì)過期的key）
如果分為熱數(shù)據(jù)，冷數(shù)據(jù)，推薦使用allkeys-lru策略

近似LRU算法

因?yàn)長RU算法需要消耗大量的內(nèi)存，所采用近似LRU算法，并且是懶處理
算法原理：（使用隨機(jī)采樣法淘汰元素）
首先給每一個(gè)key增加一個(gè)額外24bit 的字段，記錄最后被訪問的時(shí)間戳。然后當(dāng)內(nèi)存超出maxmemor時(shí)，隨機(jī)采樣出5個(gè)key（通過maxmemory——samples設(shè)置），采樣范圍取決于時(shí)allkeys還是volatile，淘汰掉醉酒的key，如果仍然超出，繼續(xù)采樣淘汰
算法分析
采樣范圍越大，月接近嚴(yán)格LRU，redis3.0中增加了淘汰池，進(jìn)一步提升了效果。淘汰池是一個(gè)大小為maxmemory_samples數(shù)組，每一次淘汰循環(huán)中，新隨機(jī)出的key會(huì)和淘汰池中的key列表融合，淘汰掉最舊的key，剩余較舊的key列表放在淘汰池中等待下一次循環(huán)

Redis持久化

持久化–將數(shù)據(jù)（如內(nèi)存中的對(duì)象）保存到可永久保存的存儲(chǔ)設(shè)備中
方式一RDB：在指定的時(shí)間間隔內(nèi)對(duì)數(shù)據(jù)進(jìn)行快照存儲(chǔ)，先將數(shù)據(jù)集心如臨時(shí)文件，寫入成功后，再替換之前的文件，用二進(jìn)制壓縮存儲(chǔ)，是一次全量的備份
方式二AOF：以日志文本的形式記錄服務(wù)器所處理的每一個(gè)數(shù)據(jù)更改指令，然后通過重放來恢復(fù)數(shù)據(jù)，是連續(xù)的增量備份

RDB

1.RDB觸發(fā)和恢復(fù)（Redis DataBase）

命令觸發(fā)

1）save，會(huì)阻塞當(dāng)前Redis服務(wù)器，直到持久化完成，線上應(yīng)該禁止使用
2）bgsave，該觸發(fā)方式會(huì)fork一個(gè)人紫禁城，由子進(jìn)程負(fù)責(zé)持久化過程，因此阻塞只會(huì)發(fā)生在fork子進(jìn)程的時(shí)候

自動(dòng)觸發(fā)

1）根據(jù)我們的save m n 配置規(guī)則自動(dòng)觸發(fā)；
2）從節(jié)點(diǎn)全量復(fù)制是，主節(jié)點(diǎn)發(fā)送rdb文件給從節(jié)點(diǎn)完成復(fù)制操作，主節(jié)點(diǎn)會(huì)觸發(fā)bgsave；
3）執(zhí)行debug reload 時(shí)；
4）執(zhí)行shutdown時(shí)，如果沒有開啟aof，也會(huì)觸發(fā)

恢復(fù)方式

將備份文件移動(dòng)到redis安裝牡蠣并啟動(dòng)服務(wù)即可

RDB-Fork原理

執(zhí)行RDB時(shí)，服務(wù)器執(zhí)行以下操作
1.redis調(diào)用系統(tǒng)函數(shù)（），創(chuàng)建一個(gè)子進(jìn)程
2.子進(jìn)程將數(shù)據(jù)集寫入到一個(gè)臨時(shí)RDB文件中
3.當(dāng)子進(jìn)程完成對(duì)臨時(shí)RDB文件的寫入時(shí)，redis用新的臨時(shí)RDB文件替換原來的RDB文件，并刪除舊的RDB文件
執(zhí)行fork時(shí)，操作系統(tǒng)會(huì)使用寫時(shí)復(fù)制（copy-on-write）策略，即fork函數(shù)發(fā)生的一顆父子進(jìn)程共享同一內(nèi)存數(shù)據(jù)，當(dāng)父進(jìn)程要更改其中某片數(shù)據(jù)時(shí)（如執(zhí)行一個(gè)寫命令），操作系統(tǒng)會(huì)將該片數(shù)據(jù)復(fù)制一份以保證子進(jìn)程的數(shù)據(jù)不受影響。新的RDB文件存儲(chǔ)的時(shí)執(zhí)行fork那一刻的內(nèi)存數(shù)據(jù)在進(jìn)行快照的過程中不會(huì)修改RDB文件，只有快照結(jié)束后才會(huì)將舊的文件替換成新的。任何時(shí)候RDB文件都是完整的

RDB性能分析

優(yōu)點(diǎn)
1.通過RDB文件恢復(fù)數(shù)據(jù)比較快
2.RDB文件非常緊湊，適合于數(shù)據(jù)備份
3.通過RDB進(jìn)行數(shù)據(jù)備份，由于使用子進(jìn)程生成，所以對(duì)Redis服務(wù)器性能影響較小
缺點(diǎn)
1.采用RDB的方式可能會(huì)造成某個(gè)時(shí)間內(nèi)數(shù)據(jù)的丟失，比如還沒達(dá)到觸發(fā)條件時(shí)服務(wù)器就死機(jī)了，那么這個(gè)時(shí)間段的數(shù)據(jù)就會(huì)丟失
2.使用save命令會(huì)造成服務(wù)器阻塞，直接數(shù)據(jù)同步完成才能接受后續(xù)請(qǐng)求
3.使用bgsave命令在forks子進(jìn)程時(shí)，如果數(shù)據(jù)量太大，forks的過程也會(huì)發(fā)生阻塞，另外forks子進(jìn)程會(huì)耗費(fèi)內(nèi)存

AOF（Append Only File）

以日志的形式記錄服務(wù)器所處理的每一個(gè)更改操作，但操作過多，aof文件過大時(shí)，加載文件回復(fù)數(shù)據(jù)會(huì)非常慢，為解決這個(gè)問題，Redis支持aof文件重寫，通過重寫aof，可以生成一個(gè)恢復(fù)當(dāng)前數(shù)據(jù)的最少命令集。整個(gè)流程大體分兩步，一是命令的實(shí)時(shí)寫入。二是aof文件的重寫
命令寫入流程：命令寫入—>追加到aof磁盤—>同步到aof磁盤

觸發(fā)

命令觸發(fā)：bgrewriteaof
自動(dòng)觸發(fā)：根據(jù)配置規(guī)則來觸發(fā)
在寫入aof日志文件時(shí)，如果redis服務(wù)宕機(jī)，則日志文件回出格式錯(cuò)位u，重啟服務(wù)器時(shí)，服務(wù)器會(huì)拒絕載入這個(gè)aof文件，此時(shí)可以通過以下命令修復(fù)aof并恢復(fù)數(shù)據(jù)
redis-check-aof-fix.file.aof

AOF原理

再重寫期間，由于主進(jìn)程依然在相應(yīng)命令，為了保證最終備份的完整性；因此他依然會(huì)寫入舊的AOF file中，如果重寫失敗，能夠保證數(shù)據(jù)不丟失。
為了把重寫期間相應(yīng)的寫入信息也寫道新的文件中，因此也會(huì)為子進(jìn)程保留一個(gè)buf，防止新寫的file丟失數(shù)據(jù)，重寫時(shí)直接把當(dāng)前內(nèi)存的數(shù)據(jù)生成對(duì)應(yīng)命令，并不需要讀取老的AOF文件進(jìn)行分析、命令的合并AOF文件直接采用文本協(xié)議，主要是兼容性好、追加方便、可讀性高。

AOF性能分析

優(yōu)點(diǎn)
1.AOf只是追加日志文件，因此對(duì)服務(wù)器性能影響較小，速度比RDB要快，消耗的內(nèi)存較少，
2.數(shù)據(jù)安全性高
缺點(diǎn)
1.AOF方式生成的日志文件太大，即使通過AFo重寫，文件體積依然很大
2.數(shù)據(jù)恢復(fù)的速度比RDB慢

當(dāng)RDB與AOF兩種方式都開啟時(shí)，Redis啟動(dòng)時(shí)會(huì)優(yōu)先使用AOF日志來恢復(fù)數(shù)據(jù)，因?yàn)锳OF保存的文件比RDB文件更完整
Redis4.0提供了一個(gè)混合持久化的選擇，將rdb文件的內(nèi)容和增量的aof日志存在一起，重啟時(shí)先加載rdb，在重放aof，以達(dá)到最大效率

Redis管道與事務(wù)

管道

首先管道技術(shù)時(shí)客戶端提供的，與服務(wù)器無關(guān)，服務(wù)器始終使用，收到-執(zhí)行-回復(fù)的順序處理消息。而客戶扼斷通過對(duì)管道中的治領(lǐng)列表改變讀寫順序，而節(jié)省答復(fù)IO時(shí)間，指令越多，效果越好。
管道測(cè)試：redis - benchmark（-p）
管道可以將多個(gè)命令打包，一次性的發(fā)送給服務(wù)器端處理

事務(wù)

一個(gè)成熟的數(shù)據(jù)庫當(dāng)然一定要支持事務(wù)，以保障多個(gè)操作的原子性。同時(shí)，事務(wù)還能保證一個(gè)事務(wù)中的命令依次執(zhí)行而不會(huì)被其他命令插入
所有事務(wù)的基本用法，都是begin，commit，rollback
redis事務(wù)指令時(shí)，multl，exec，discard，雖然可以使用DISCARD取消事務(wù)，但是不支持回滾
當(dāng)輸入MULTL命令后，服務(wù)器返回ok表示事務(wù)開始成功，，然后依次輸入需要在本次事務(wù)中執(zhí)行的命令，每次輸入一個(gè)命令，服務(wù)器并不會(huì)馬上執(zhí)行，而是返回“QUEUED”，這表示命令已經(jīng)被服務(wù)器接受并且暫時(shí)保存起來，最后輸入EXEC命令后，本次事務(wù)中的所有命令才會(huì)被依次執(zhí)行
事務(wù)錯(cuò)誤處理
1.語法錯(cuò)誤，全不執(zhí)行
2.運(yùn)行草屋，出錯(cuò)后仍然繼續(xù)執(zhí)行
事務(wù)監(jiān)測(cè)
將其中一條命令的執(zhí)行結(jié)果作為另一條命令的執(zhí)行參數(shù)，如i++，需要使用watch命令
WATCH命令可以監(jiān)控一個(gè)或多個(gè)鍵，一旦其中有一個(gè)鍵被修改（或刪除），之后的事務(wù)就不會(huì)執(zhí)行，監(jiān)控一直持續(xù)到EXEC命令
執(zhí)行EXEC命令之后會(huì)取消監(jiān)控使用WATCH命令監(jiān)控的鍵，如果不想執(zhí)行事務(wù)中的命令，也可以使用UNWATCH命令來取消監(jiān)控
使用方式 watch -> multi-> command->exec
注意：由于WATCH命令的作用只是當(dāng)被監(jiān)控的鍵被修改后取消之后的事務(wù)，并不能保證其他客戶端不修改監(jiān)控的值，所以當(dāng)EXEC命令執(zhí)行失敗后需要手動(dòng)重新執(zhí)行整個(gè)事務(wù)
本質(zhì)上時(shí)一種樂觀鎖

Redis分布式鎖

樂觀鎖與悲觀鎖

悲觀鎖（Pessimistic Lock）：滅磁去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人會(huì)修改，所以每次在拿數(shù)據(jù)的時(shí)候都會(huì)上鎖。這樣別人想拿數(shù)據(jù)就會(huì)被擋住，直到悲觀鎖被釋放。
樂觀鎖（Optimistic Lock）：每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改。所以不會(huì)上鎖，但是如果想要更新數(shù)據(jù)，則會(huì)在更新前檢查在讀取至更新這段時(shí)間別人有沒有修改過這個(gè)數(shù)據(jù)。如果修改過，則重新讀取，再次嘗試更新，循環(huán)上述步驟直到更新成功
悲觀鎖VS樂觀鎖
1.悲觀鎖阻塞事務(wù)，了所灌輸回滾重試
2.樂觀鎖適用于寫比較少的情況下，即沖突很少發(fā)生時(shí)，可以省區(qū)鎖的開銷，加大了系統(tǒng)吞吐量
3.悲觀鎖適用于寫比較多的情況下，因?yàn)槿绻麡酚^鎖經(jīng)常沖突，應(yīng)用要不斷進(jìn)行重試，反倒降低性能

CAS算法

1.比較：讀取到了一個(gè)值A(chǔ)，在將其更新為B之前，檢查原址是否為A（未被其他線程改動(dòng)）
2.設(shè)置：如果是，將A更新為B，結(jié)束，如果不是，則什么都不做
允許多個(gè)線程同時(shí)讀取（因?yàn)楦緵]有加鎖操作），但是只有一個(gè)線程可以成功更新數(shù)據(jù)，并導(dǎo)致其他要更新數(shù)據(jù)的線程回滾重試。也叫非阻塞同步（Non-blocking Synchronization）
樂觀鎖策略也被稱為無鎖編程。換句話說，樂觀鎖其實(shí)不是鎖，它僅僅是一個(gè)循環(huán)重試的算法

樂觀鎖的缺點(diǎn) – ABA問題

如果一個(gè)變量V初次讀取的時(shí)候時(shí)A值，并且準(zhǔn)備賦值的時(shí)候檢查到它仍然是A值，那我們就能說明它的值沒有被其他線程修改過了嗎？不能，因?yàn)槟阍谶@段時(shí)間它的值可能被改為其他值，然后又改回A，那CAS操作就會(huì)誤認(rèn)為它從來沒有被修改過。這個(gè)問題被稱為CAS操作的ABA問題

分布式鎖

在很多場(chǎng)景中，我們?yōu)榱吮ＷC數(shù)據(jù)的最終一致性，需要很多的計(jì)數(shù)方案支持。有時(shí)我們需要一個(gè)方法在同一時(shí)間內(nèi)只能被同一個(gè)線程執(zhí)行。再單擊環(huán)境中，java中有很多處理并發(fā)的API,但是這個(gè)API在分布式場(chǎng)景中無能為力。單純的java API 并不能提供分布式鎖的能力。
分布式鎖時(shí)控制分布式系系統(tǒng)之間同步訪問共享資源的一種方式。分布式鎖一般有三種實(shí)現(xiàn)方式
1.數(shù)據(jù)庫樂觀鎖
2.基于Redis的分布式鎖
3.基于Zookeeper的分布式鎖
分布式鎖的可靠性需滿足以下四個(gè)條件
1.互斥性。在任意時(shí)刻，只有一個(gè)客戶端能持有鎖
2.不會(huì)發(fā)生死鎖。即使有一個(gè)客戶端在持有鎖的期間崩潰而沒有主動(dòng)解鎖，也能保證后序其他客戶端能加鎖
3.具有容錯(cuò)性。只要大部分的Redis節(jié)點(diǎn)正常運(yùn)行，客戶端就可以加鎖和解鎖
4.加鎖和解鎖必須是同一個(gè)客戶端，客戶端自己不能把別人加的鎖解掉。

Setnx + Lua

使用Redis實(shí)現(xiàn)分布式鎖原理：
Redis為單進(jìn)程單線程模式，采用隊(duì)列模式將并發(fā)訪問編程串行訪問，且多客戶端對(duì)Redis的連接并不存在競(jìng)爭關(guān)系，基于此，Redis中可以使用SETNX命令實(shí)現(xiàn)分布式鎖
SETNX–SET if Not exists(如果不存在，則設(shè)置)
若給定的key已經(jīng)存在，則SETNX不做任何動(dòng)作；如果需要解鎖，使用key命令就能解鎖

Redis集群

主從模式

為了保證高可用，redis - cluster集群引入了主從模式，一個(gè)主節(jié)點(diǎn)對(duì)應(yīng)一個(gè)或者多個(gè)從節(jié)點(diǎn)，當(dāng)主節(jié)點(diǎn)宕機(jī)時(shí)，就會(huì)啟用從節(jié)點(diǎn)。。當(dāng)其他主節(jié)點(diǎn)ping一個(gè)主節(jié)點(diǎn)A時(shí)，如果或半數(shù)以上的主節(jié)點(diǎn)與A通信超時(shí)，那么認(rèn)為主節(jié)點(diǎn)A宕機(jī)了。如果主節(jié)點(diǎn)A和他的從節(jié)點(diǎn)A1都宕機(jī)了，那么該集群就無法提供服務(wù)了
優(yōu)點(diǎn)
1.支持主從復(fù)制，主機(jī)會(huì)自動(dòng)將數(shù)據(jù)同步到從機(jī)，可以進(jìn)行讀寫分離
2.為了分在Master的讀操作壓力，Slave服務(wù)器可以為客戶端提供只讀操作的服務(wù)，寫服務(wù)仍然必須由Master來完成
3.Slave同樣可以接受其他Slaves的連接和同步請(qǐng)求，這樣可以有效的分載Master的同步壓力
缺點(diǎn)
1.Redis不具備自動(dòng)容錯(cuò)和恢復(fù)功能，主機(jī)從機(jī)的宕機(jī)都會(huì)導(dǎo)致前端部分讀寫請(qǐng)求失敗，需要等待機(jī)器重啟或者手動(dòng)切換前端IP才能恢復(fù)
2.主機(jī)宕機(jī)，宕機(jī)前有部分?jǐn)?shù)據(jù)未能及時(shí)同步到從機(jī)，切換IP后還會(huì)引入數(shù)據(jù)不一致的問題，降低了系統(tǒng)的可用性
3.Redis較難支持在線擴(kuò)容，在集群容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜

主從復(fù)制

在Redis中，用戶可以通過執(zhí)行SlAVEOF命令或者設(shè)置slaveof選項(xiàng)，讓一個(gè)服務(wù)器去復(fù)制另一個(gè)服務(wù)器，我們稱呼被復(fù)制的服務(wù)器為主服務(wù)器，而對(duì)主服務(wù)器進(jìn)行復(fù)制的服務(wù)器被稱為從服務(wù)器。

哨兵模式

當(dāng)主服務(wù)器中斷服務(wù)后，可以將一個(gè)從服務(wù)器升級(jí)為主服務(wù)器，以便繼續(xù)提供給服務(wù)，但這個(gè)過程需要人工手動(dòng)來操作。為此，Redis2.8中提供了哨兵工具來實(shí)現(xiàn)自動(dòng)化的系統(tǒng)監(jiān)控和故障恢復(fù)功能
哨兵的作用就是監(jiān)控Redis系統(tǒng)的運(yùn)行情況，它的功能包括兩個(gè)
1.監(jiān)控主服務(wù)器和從服務(wù)器是否正常運(yùn)行
2.主服務(wù)器出現(xiàn)故障時(shí)自動(dòng)將從服務(wù)器轉(zhuǎn)換為主服務(wù)器
優(yōu)點(diǎn)
哨兵模式時(shí)基于主從模式的，所有主從模式的優(yōu)點(diǎn)，哨兵模式都具有，主從可以自動(dòng)切換，系統(tǒng)更健壯，可用性更高
缺點(diǎn)
Redis較難支持在線擴(kuò)容，在集群容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜

總結(jié)

Redis vs Memcached

總的來說，可以把Redis理解為是對(duì)Memcached的拓展。
1.性能上
性能上都和出色，具體到細(xì)節(jié)，由 于Redis只使用單核，而Memcached可以使用 多核，所以平均每一個(gè)核上Redis在存儲(chǔ)小數(shù) 據(jù)時(shí)比Memcached性能更高。而在100k以上 的數(shù)據(jù)中，Memcached的性能要高于Redis。
2.內(nèi)存空間和數(shù)據(jù)量大小
Memcached可以修改最大內(nèi)存。 采用LRU算法。Redis增加了VM的特性，突破 了物理內(nèi)存的限制
3.操作便利上
Memcached數(shù)據(jù)結(jié)構(gòu)單一，僅用 來緩存數(shù)據(jù)，而Redis支持更加豐富的數(shù)據(jù)類 型，也可以在服務(wù)器直接對(duì)數(shù)據(jù)進(jìn)行豐富的操 作，這樣可以減少網(wǎng)絡(luò)IO次數(shù)和數(shù)據(jù)體積
4.可靠性上
Memcached不支持?jǐn)?shù)據(jù)持久化， 斷電或重啟后數(shù)據(jù)消失，但其穩(wěn)定性是有保證的。Redis支持?jǐn)?shù)據(jù)持久化和數(shù)據(jù)恢復(fù)，允許單點(diǎn)故障，但是同時(shí)也會(huì)付出性能的代價(jià)

Redis支持的數(shù)據(jù)類型

詳見上

Redis有哪幾種數(shù)據(jù)淘汰策略

6種淘汰策略
1.noeviction：不刪除策略，達(dá)到最大內(nèi)存限制時(shí)，如果需要更多內(nèi)存，直接返回錯(cuò)誤信息。大多數(shù)寫命令都會(huì)導(dǎo)致占用更多的內(nèi)存（有極少數(shù)的會(huì)例外，如DEL）
2.allkeys-lru：所有key通用；優(yōu)先刪除最近最少使用（less recently used ，LRU）的key。
3.volatile-lru：優(yōu)先刪除最近最少使用（less recently used，LRU）的key（限于會(huì)過期的key）
4.allkeys-random：所有key通信；隨機(jī)刪除一部分key
5.volatile-random：隨機(jī)刪除一部分key（限于會(huì)過期的key）
6.volatile-ttl：優(yōu)先刪除剩余時(shí)間（time to live，TTL）短的key（限于會(huì)過期的key）
如果分為熱數(shù)據(jù)，冷數(shù)據(jù)，推薦使用allkeys-lru策略

什么是Redis持久化?Redis哪幾種持久化方法？優(yōu)缺點(diǎn)是什么

RBD和AOF

Redis有哪些架構(gòu)模式？各自特點(diǎn)？

主從
哨兵

什么是緩存穿透？如何避免？什么是緩存雪崩？如何避免？

緩存穿透
訪問一個(gè)不存在的key，緩存不起作用，請(qǐng)求會(huì)穿透到DB，流量大時(shí)DB會(huì)掛掉
解決方案：采用布隆過濾器，使用一個(gè)足夠大的bitmap,用于存儲(chǔ)可能訪問key，不存在的key直接被過濾
緩存雪崩
大量的key設(shè)置了相同的過期時(shí)間，導(dǎo)致在緩存在同一時(shí)刻全部失效，造成瞬間DB請(qǐng)求量大、壓力驟增，引起雪崩
解決方案：給緩存設(shè)置過期時(shí)間時(shí)加上一個(gè)隨機(jī)值時(shí)間，是的每個(gè)key的過期時(shí)間分不開來，不會(huì)集中在同一時(shí)刻失效
緩存擊穿：
一個(gè)存在的key，再換粗過期的一刻，同時(shí)又大量的請(qǐng)求，這些請(qǐng)求都會(huì)擊穿到DB，造成瞬間DB請(qǐng)求量過大，壓力驟增
解決方案：在訪問key之前，采用SETNX來設(shè)置一個(gè)短期key來所著當(dāng)前key的訪問，訪問結(jié)束再刪除該短期key

Redis基礎(chǔ)筆記（上）

總結(jié)

以上是生活随笔為你收集整理的Redis基础笔记（下）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。