本文的面試題如下：
- Redis 持久化機(jī)制
- 緩存雪崩臭埋、緩存穿透瓢阴、緩存預(yù)熱荣恐、緩存更新叠穆、緩存降級(jí)等問(wèn)題
- 熱點(diǎn)數(shù)據(jù)和冷數(shù)據(jù)是什么
- Memcache與Redis的區(qū)別都有哪些硼被？
- 單線(xiàn)程的redis為什么這么快
- redis的數(shù)據(jù)類(lèi)型嚷硫，以及每種數(shù)據(jù)類(lèi)型的使用場(chǎng)景仔掸，Redis 內(nèi)部結(jié)構(gòu)
- redis的過(guò)期策略以及內(nèi)存淘汰機(jī)制【～】
- Redis 為什么是單線(xiàn)程的起暮，優(yōu)點(diǎn)
- 如何解決redis的并發(fā)競(jìng)爭(zhēng)key問(wèn)題
- Redis 集群方案應(yīng)該怎么做负懦？都有哪些方案密似？
- 有沒(méi)有嘗試進(jìn)行多機(jī)redis 的部署？如何保證數(shù)據(jù)一致的抛猫？
- 對(duì)于大量的請(qǐng)求怎么樣處理
- Redis 常見(jiàn)性能問(wèn)題和解決方案闺金？
- 講解下Redis線(xiàn)程模型
- 為什么Redis的操作是原子性的败匹，怎么保證原子性的掀亩？
- Redis事務(wù)
- Redis實(shí)現(xiàn)分布式鎖
Redis 持久化機(jī)制
Redis是一個(gè)支持持久化的內(nèi)存數(shù)據(jù)庫(kù)槽棍，通過(guò)持久化機(jī)制把內(nèi)存中的數(shù)據(jù)同步到硬盤(pán)文件來(lái)保證數(shù)據(jù)持久化缆巧。當(dāng)Redis重啟后通過(guò)把硬盤(pán)文件重新加載到內(nèi)存陕悬，就能達(dá)到恢復(fù)數(shù)據(jù)的目的墩莫。
實(shí)現(xiàn)：?jiǎn)为?dú)創(chuàng)建fork()一個(gè)子進(jìn)程狂秦，將當(dāng)前父進(jìn)程的數(shù)據(jù)庫(kù)數(shù)據(jù)復(fù)制到子進(jìn)程的內(nèi)存中裂问，然后由子進(jìn)程寫(xiě)入到臨時(shí)文件中，持久化的過(guò)程結(jié)束了皮壁，再用這個(gè)臨時(shí)文件替換上次的快照文件虑瀑，然后子進(jìn)程退出舌狗，內(nèi)存釋放痛侍。
RDB是Redis默認(rèn)的持久化方式主届。按照一定的時(shí)間周期策略把內(nèi)存的數(shù)據(jù)以快照的形式保存到硬盤(pán)的二進(jìn)制文件誓竿。即Snapshot快照存儲(chǔ)，對(duì)應(yīng)產(chǎn)生的數(shù)據(jù)文件為dump.rdb簸喂，通過(guò)配置文件中的save參數(shù)來(lái)定義快照的周期喻鳄。（ 快照可以是其所表示的數(shù)據(jù)的一個(gè)副本，也可以是數(shù)據(jù)的一個(gè)復(fù)制品颜曾。）
AOF：Redis會(huì)將每一個(gè)收到的寫(xiě)命令都通過(guò)Write函數(shù)追加到文件最后泛豪，類(lèi)似于MySQL的binlog诡曙。當(dāng)Redis重啟是會(huì)通過(guò)重新執(zhí)行文件中保存的寫(xiě)命令來(lái)在內(nèi)存中重建整個(gè)數(shù)據(jù)庫(kù)的內(nèi)容。
當(dāng)兩種方式同時(shí)開(kāi)啟時(shí)慎璧，數(shù)據(jù)恢復(fù)Redis會(huì)優(yōu)先選擇AOF恢復(fù)炸卑。
對(duì)了盖文，我把發(fā)布過(guò)的 Redis 相關(guān)的文章整理成了 PDF洒敏，關(guān)注微信公眾號(hào) Java后端凶伙，回復(fù) 666 下載這本 Java技術(shù)棧手冊(cè)函荣。
緩存雪崩傻挂、緩存穿透金拒、緩存預(yù)熱绪抛、緩存更新、緩存降級(jí)等問(wèn)題
緩存雪崩
緩存雪崩我們可以簡(jiǎn)單的理解為：由于原有緩存失效蛤育，新緩存未到期間
(例如：我們?cè)O(shè)置緩存時(shí)采用了相同的過(guò)期時(shí)間瓦糕，在同一時(shí)刻出現(xiàn)大面積的緩存過(guò)期)咕娄，所有原本應(yīng)該訪(fǎng)問(wèn)緩存的請(qǐng)求都去查詢(xún)數(shù)據(jù)庫(kù)了，而對(duì)數(shù)據(jù)庫(kù)CPU和內(nèi)存造成巨大壓力圣贸，嚴(yán)重的會(huì)造成數(shù)據(jù)庫(kù)宕機(jī)吁峻。從而形成一系列連鎖反應(yīng)矮慕，造成整個(gè)系統(tǒng)崩潰啄骇。
解決辦法：
大多數(shù)系統(tǒng)設(shè)計(jì)者考慮用加鎖（ 最多的解決方案）或者隊(duì)列的方式保證來(lái)保證不會(huì)有大量的線(xiàn)程對(duì)數(shù)據(jù)庫(kù)一次性進(jìn)行讀寫(xiě)痴鳄，從而避免失效時(shí)大量的并發(fā)請(qǐng)求落到底層存儲(chǔ)系統(tǒng)上。還有一個(gè)簡(jiǎn)單方案就時(shí)講緩存失效時(shí)間分散開(kāi)缸夹。
緩存穿透
緩存穿透是指用戶(hù)查詢(xún)數(shù)據(jù)痪寻，在數(shù)據(jù)庫(kù)沒(méi)有，自然在緩存中也不會(huì)有虽惭。這樣就導(dǎo)致用戶(hù)查詢(xún)的時(shí)候橡类，在緩存中找不到趟妥，每次都要去數(shù)據(jù)庫(kù)再查詢(xún)一遍，然后返回空（相當(dāng)于進(jìn)行了兩次無(wú)用的查詢(xún)）佣蓉。這樣請(qǐng)求就繞過(guò)緩存直接查數(shù)據(jù)庫(kù)披摄，這也是經(jīng)常提的緩存命中率問(wèn)題。
解決辦法：
最常見(jiàn)的則是采用布隆過(guò)濾器勇凭，將所有可能存在的數(shù)據(jù)哈希到一個(gè)足夠大的bitmap中疚膊，一個(gè)一定不存在的數(shù)據(jù)會(huì)被這個(gè)bitmap攔截掉，從而避免了對(duì)底層存儲(chǔ)系統(tǒng)的查詢(xún)壓力虾标。
另外也有一個(gè)更為簡(jiǎn)單粗暴的方法寓盗，如果一個(gè)查詢(xún)返回的數(shù)據(jù)為空（不管是數(shù)據(jù)不存在，還是系統(tǒng)故障）璧函，我們?nèi)匀话堰@個(gè)空結(jié)果進(jìn)行緩存傀蚌，但它的過(guò)期時(shí)間會(huì)很短，最長(zhǎng)不超過(guò)五分鐘蘸吓。通過(guò)這個(gè)直接設(shè)置的默認(rèn)值存放到緩存善炫，這樣第二次到緩沖中獲取就有值了，而不會(huì)繼續(xù)訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)库继，這種辦法最簡(jiǎn)單粗暴箩艺。
5TB的硬盤(pán)上放滿(mǎn)了數(shù)據(jù)，請(qǐng)寫(xiě)一個(gè)算法將這些數(shù)據(jù)進(jìn)行排重宪萄。如果這些數(shù)據(jù)是一些32bit大小的數(shù)據(jù)該如何解決艺谆？如果是64bit的呢？
對(duì)于空間的利用到達(dá)了一種極致拜英，那就是Bitmap和布隆過(guò)濾器(Bloom Filter)静汤。
Bitmap：典型的就是哈希表
缺點(diǎn)是，Bitmap對(duì)于每個(gè)元素只能記錄1bit信息，如果還想完成額外的功能撒妈，恐怕只能靠犧牲更多的空間恢暖、時(shí)間來(lái)完成了。
布隆過(guò)濾器（推薦）
就是引入了k(k>1)k(k>1)個(gè)相互獨(dú)立的哈希函數(shù)狰右，保證在給定的空間杰捂、誤判率下，完成元素判重的過(guò)程棋蚌。
它的優(yōu)點(diǎn)是空間效率和查詢(xún)時(shí)間都遠(yuǎn)遠(yuǎn)超過(guò)一般的算法嫁佳，缺點(diǎn)是有一定的誤識(shí)別率和刪除困難。
Bloom-Filter算法的核心思想就是利用多個(gè)不同的Hash函數(shù)來(lái)解決“沖突”谷暮。
Hash存在一個(gè)沖突（碰撞）的問(wèn)題蒿往，用同一個(gè)Hash得到的兩個(gè)URL的值有可能相同。為了減少?zèng)_突湿弦，我們可以多引入幾個(gè)Hash瓤漏，如果通過(guò)其中的一個(gè)Hash值我們得出某元素不在集合中，那么該元素肯定不在集合中颊埃。只有在所有的Hash函數(shù)告訴我們?cè)撛卦诩现袝r(shí)蔬充，才能確定該元素存在于集合中。這便是Bloom-Filter的基本思想班利。
Bloom-Filter一般用于在大數(shù)據(jù)量的集合中判定某元素是否存在饥漫。
緩存穿透與緩存擊穿的區(qū)別
緩存擊穿：是指一個(gè)key非常熱點(diǎn)，在不停的扛著大并發(fā)罗标，大并發(fā)集中對(duì)這一個(gè)點(diǎn)進(jìn)行訪(fǎng)問(wèn)庸队，當(dāng)這個(gè)key在失效的瞬間，持續(xù)的大并發(fā)就穿破緩存闯割，直接請(qǐng)求數(shù)據(jù)彻消。
解決方案：在訪(fǎng)問(wèn)key之前，采用SETNX（set if not exists）來(lái)設(shè)置另一個(gè)短期key來(lái)鎖住當(dāng)前key的訪(fǎng)問(wèn)宙拉，訪(fǎng)問(wèn)結(jié)束再刪除該短期key证膨。
給一個(gè)我公司處理的案例：背景雙機(jī)拿token，token在存一份到redis鼓黔，保證系統(tǒng)在token過(guò)期時(shí)都只有一個(gè)線(xiàn)程去獲取token;線(xiàn)上環(huán)境有兩臺(tái)機(jī)器央勒，故使用分布式鎖實(shí)現(xiàn)。
三澳化、緩存預(yù)熱
緩存預(yù)熱這個(gè)應(yīng)該是一個(gè)比較常見(jiàn)的概念崔步，相信很多小伙伴都應(yīng)該可以很容易的理解，緩存預(yù)熱就是系統(tǒng)上線(xiàn)后缎谷，將相關(guān)的緩存數(shù)據(jù)直接加載到緩存系統(tǒng)井濒。這樣就可以避免在用戶(hù)請(qǐng)求的時(shí)候灶似，先查詢(xún)數(shù)據(jù)庫(kù)，然后再將數(shù)據(jù)緩存的問(wèn)題瑞你！用戶(hù)直接查詢(xún)事先被預(yù)熱的緩存數(shù)據(jù)酪惭！
解決思路：
- 直接寫(xiě)個(gè)緩存刷新頁(yè)面，上線(xiàn)時(shí)手工操作下者甲；
- 數(shù)據(jù)量不大春感，可以在項(xiàng)目啟動(dòng)的時(shí)候自動(dòng)進(jìn)行加載；
- 定時(shí)刷新緩存虏缸；
四鲫懒、緩存更新
除了緩存服務(wù)器自帶的緩存失效策略之外（Redis默認(rèn)的有6中策略可供選擇），我們還可以根據(jù)具體的業(yè)務(wù)需求進(jìn)行自定義的緩存淘汰刽辙，常見(jiàn)的策略有兩種：
- 定時(shí)去清理過(guò)期的緩存窥岩；
- 當(dāng)有用戶(hù)請(qǐng)求過(guò)來(lái)時(shí)，再判斷這個(gè)請(qǐng)求所用到的緩存是否過(guò)期宰缤，過(guò)期的話(huà)就去底層系統(tǒng)得到新數(shù)據(jù)并更新緩存颂翼。
兩者各有優(yōu)劣，第一種的缺點(diǎn)是維護(hù)大量緩存的key是比較麻煩的慨灭，第二種的缺點(diǎn)就是每次用戶(hù)請(qǐng)求過(guò)來(lái)都要判斷緩存失效朦乏，邏輯相對(duì)比較復(fù)雜！具體用哪種方案缘挑，大家可以根據(jù)自己的應(yīng)用場(chǎng)景來(lái)權(quán)衡集歇。
五桶略、緩存降級(jí)
當(dāng)訪(fǎng)問(wèn)量劇增语淘、服務(wù)出現(xiàn)問(wèn)題（如響應(yīng)時(shí)間慢或不響應(yīng)）或非核心服務(wù)影響到核心流程的性能時(shí)，仍然需要保證服務(wù)還是可用的际歼，即使是有損服務(wù)惶翻。系統(tǒng)可以根據(jù)一些關(guān)鍵數(shù)據(jù)進(jìn)行自動(dòng)降級(jí)，也可以配置開(kāi)關(guān)實(shí)現(xiàn)人工降級(jí)鹅心。
降級(jí)的最終目的是保證核心服務(wù)可用吕粗，即使是有損的。而且有些服務(wù)是無(wú)法降級(jí)的（如加入購(gòu)物車(chē)旭愧、結(jié)算）颅筋。
以參考日志級(jí)別設(shè)置預(yù)案：
- 一般：比如有些服務(wù)偶爾因?yàn)榫W(wǎng)絡(luò)抖動(dòng)或者服務(wù)正在上線(xiàn)而超時(shí)，可以自動(dòng)降級(jí)输枯；
- 警告：有些服務(wù)在一段時(shí)間內(nèi)成功率有波動(dòng)（如在95~100%之間）议泵，可以自動(dòng)降級(jí)或人工降級(jí)，并發(fā)送告警桃熄；
- 錯(cuò)誤：比如可用率低于90%先口，或者數(shù)據(jù)庫(kù)連接池被打爆了，或者訪(fǎng)問(wèn)量突然猛增到系統(tǒng)能承受的最大閥值，此時(shí)可以根據(jù)情況自動(dòng)降級(jí)或者人工降級(jí)碉京；
- 嚴(yán)重錯(cuò)誤：比如因?yàn)樘厥庠驍?shù)據(jù)錯(cuò)誤了厢汹，此時(shí)需要緊急人工降級(jí)。
服務(wù)降級(jí)的目的谐宙，是為了防止Redis服務(wù)故障烫葬，導(dǎo)致數(shù)據(jù)庫(kù)跟著一起發(fā)生雪崩問(wèn)題。因此卧惜，對(duì)于不重要的緩存數(shù)據(jù)厘灼，可以采取服務(wù)降級(jí)策略，例如一個(gè)比較常見(jiàn)的做法就是咽瓷，Redis出現(xiàn)問(wèn)題设凹，不去數(shù)據(jù)庫(kù)查詢(xún)，而是直接返回默認(rèn)值給用戶(hù)茅姜。
熱點(diǎn)數(shù)據(jù)和冷數(shù)據(jù)是什么
熱點(diǎn)數(shù)據(jù)闪朱，緩存才有價(jià)值
對(duì)于冷數(shù)據(jù)而言，大部分?jǐn)?shù)據(jù)可能還沒(méi)有再次訪(fǎng)問(wèn)到就已經(jīng)被擠出內(nèi)存钻洒，不僅占用內(nèi)存奋姿，而且價(jià)值不大。頻繁修改的數(shù)據(jù)素标，看情況考慮使用緩存
對(duì)于上面兩個(gè)例子称诗，壽星列表、導(dǎo)航信息都存在一個(gè)特點(diǎn)头遭，就是信息修改頻率不高寓免，讀取通常非常高的場(chǎng)景。
對(duì)于熱點(diǎn)數(shù)據(jù)计维，比如我們的某IM產(chǎn)品袜香，生日祝福模塊，當(dāng)天的壽星列表鲫惶，緩存以后可能讀取數(shù)十萬(wàn)次蜈首。再舉個(gè)例子，某導(dǎo)航產(chǎn)品欠母，我們將導(dǎo)航信息欢策，緩存以后可能讀取數(shù)百萬(wàn)次。
數(shù)據(jù)更新前至少讀取兩次赏淌， 緩存才有意義踩寇。這個(gè)是最基本的策略，如果緩存還沒(méi)有起作用就失效了猜敢，那就沒(méi)有太大價(jià)值了姑荷。
那存不存在盒延，修改頻率很高，但是又不得不考慮緩存的場(chǎng)景呢鼠冕？有添寺！比如，這個(gè)讀取接口對(duì)數(shù)據(jù)庫(kù)的壓力很大懈费，但是又是熱點(diǎn)數(shù)據(jù)计露，這個(gè)時(shí)候就需要考慮通過(guò)緩存手段，減少數(shù)據(jù)庫(kù)的壓力憎乙，比如我們的某助手產(chǎn)品的票罐，點(diǎn)贊數(shù)，收藏?cái)?shù)泞边，分享數(shù)等是非常典型的熱點(diǎn)數(shù)據(jù)该押，但是又不斷變化，此時(shí)就需要將數(shù)據(jù)同步保存到Redis緩存阵谚，減少數(shù)據(jù)庫(kù)壓力蚕礼。
Memcache與Redis的區(qū)別都有哪些？
1)梢什、存儲(chǔ)方式 Memecache把數(shù)據(jù)全部存在內(nèi)存之中奠蹬，斷電后會(huì)掛掉，數(shù)據(jù)不能超過(guò)內(nèi)存大小嗡午。Redis有部份存在硬盤(pán)上囤躁，redis可以持久化其數(shù)據(jù)
2)、數(shù)據(jù)支持類(lèi)型 memcached所有的值均是簡(jiǎn)單的字符串荔睹，redis作為其替代者狸演，支持更為豐富的數(shù)據(jù)類(lèi)型 ，提供list应媚，set严沥，zset猜极，hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)
3)中姜、使用底層模型不同 它們之間底層實(shí)現(xiàn)方式 以及與客戶(hù)端之間通信的應(yīng)用協(xié)議不一樣。Redis直接自己構(gòu)建了VM 機(jī)制 跟伏，因?yàn)橐话愕南到y(tǒng)調(diào)用系統(tǒng)函數(shù)的話(huà)丢胚，會(huì)浪費(fèi)一定的時(shí)間去移動(dòng)和請(qǐng)求。
4). value 值大小不同：Redis 最大可以達(dá)到 512M受扳；memcache 只有 1mb携龟。
5）redis的速度比memcached快很多
6）Redis支持?jǐn)?shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份勘高。
單線(xiàn)程的redis為什么這么快
(一)純內(nèi)存操作
(二)單線(xiàn)程操作峡蟋，避免了頻繁的上下文切換
(三)采用了非阻塞I/O多路復(fù)用機(jī)制
redis的數(shù)據(jù)類(lèi)型坟桅，以及每種數(shù)據(jù)類(lèi)型的使用場(chǎng)景
回答：一共五種
(一) String
這個(gè)其實(shí)沒(méi)啥好說(shuō)的，最常規(guī)的set/get操作蕊蝗，value可以是String也可以是數(shù)字仅乓。一般做一些復(fù)雜的計(jì)數(shù)功能的緩存。
(二) hash
這里value存放的是結(jié)構(gòu)化的對(duì)象蓬戚，比較方便的就是操作其中的某個(gè)字段夸楣。博主在做單點(diǎn)登錄的時(shí)候，就是用這種數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)用戶(hù)信息子漩，以cookieId作為key豫喧，設(shè)置30分鐘為緩存過(guò)期時(shí)間，能很好的模擬出類(lèi)似session的效果幢泼。
(三) list
使用List的數(shù)據(jù)結(jié)構(gòu)紧显，可以做簡(jiǎn)單的消息隊(duì)列的功能。另外還有一個(gè)就是缕棵，可以利用lrange命令鸟妙，做基于redis的分頁(yè)功能，性能極佳挥吵，用戶(hù)體驗(yàn)好重父。本人還用一個(gè)場(chǎng)景，很合適—取行情信息忽匈。就也是個(gè)生產(chǎn)者和消費(fèi)者的場(chǎng)景房午。LIST可以很好的完成排隊(duì)，先進(jìn)先出的原則丹允。
(四) set
因?yàn)閟et堆放的是一堆不重復(fù)值的集合郭厌。所以可以做全局去重的功能。為什么不用JVM自帶的Set進(jìn)行去重雕蔽？因?yàn)槲覀兊南到y(tǒng)一般都是集群部署折柠，使用JVM自帶的Set，比較麻煩批狐，難道為了一個(gè)做一個(gè)全局去重扇售，再起一個(gè)公共服務(wù)，太麻煩了嚣艇。
另外承冰，就是利用交集、并集食零、差集等操作困乒，可以計(jì)算共同喜好，全部的喜好贰谣，自己獨(dú)有的喜好等功能娜搂。
(五) sorted set
sorted set多了一個(gè)權(quán)重參數(shù)score,集合中的元素能夠按score進(jìn)行排列迁霎。可以做排行榜應(yīng)用百宇，取TOP N操作欧引。
Redis 內(nèi)部結(jié)構(gòu)
- dict 本質(zhì)上是為了解決算法中的查找問(wèn)題（Searching）是一個(gè)用于維護(hù)key和value映射關(guān)系的數(shù)據(jù)結(jié)構(gòu)，與很多語(yǔ)言中的Map或dictionary類(lèi)似恳谎。本質(zhì)上是為了解決算法中的查找問(wèn)題（Searching）
- sds sds就等同于char * 它可以存儲(chǔ)任意二進(jìn)制數(shù)據(jù)芝此，不能像C語(yǔ)言字符串那樣以字符’\0’來(lái)標(biāo)識(shí)字符串的結(jié) 束，因此它必然有個(gè)長(zhǎng)度字段因痛。
- skiplist （跳躍表） 跳表是一種實(shí)現(xiàn)起來(lái)很簡(jiǎn)單婚苹，單層多指針的鏈表，它查找效率很高鸵膏，堪比優(yōu)化過(guò)的二叉平衡樹(shù)膊升，且比平衡樹(shù)的實(shí)現(xiàn)，
- quicklist
- ziplist 壓縮表 ziplist是一個(gè)編碼后的列表谭企，是由一系列特殊編碼的連續(xù)內(nèi)存塊組成的順序型數(shù)據(jù)結(jié)構(gòu)廓译，
redis的過(guò)期策略以及內(nèi)存淘汰機(jī)制
redis采用的是定期刪除+惰性刪除策略。
為什么不用定時(shí)刪除策略?
定時(shí)刪除,用一個(gè)定時(shí)器來(lái)負(fù)責(zé)監(jiān)視key,過(guò)期則自動(dòng)刪除债查。雖然內(nèi)存及時(shí)釋放非区，但是十分消耗CPU資源。在大并發(fā)請(qǐng)求下盹廷，CPU要將時(shí)間應(yīng)用在處理請(qǐng)求征绸，而不是刪除key,因此沒(méi)有采用這一策略.
定期刪除+惰性刪除是如何工作的呢?
定期刪除，redis默認(rèn)每個(gè)100ms檢查俄占，是否有過(guò)期的key,有過(guò)期key則刪除管怠。需要說(shuō)明的是，redis不是每個(gè)100ms將所有的key檢查一次缸榄，而是隨機(jī)抽取進(jìn)行檢查(如果每隔100ms,全部key進(jìn)行檢查渤弛，redis豈不是卡死)。因此甚带，如果只采用定期刪除策略她肯，會(huì)導(dǎo)致很多key到時(shí)間沒(méi)有刪除。
于是欲低，惰性刪除派上用場(chǎng)辕宏。也就是說(shuō)在你獲取某個(gè)key的時(shí)候畜晰，redis會(huì)檢查一下砾莱，這個(gè)key如果設(shè)置了過(guò)期時(shí)間那么是否過(guò)期了？如果過(guò)期了此時(shí)就會(huì)刪除凄鼻。
采用定期刪除+惰性刪除就沒(méi)其他問(wèn)題了么?
不是的腊瑟，如果定期刪除沒(méi)刪除key聚假。然后你也沒(méi)即時(shí)去請(qǐng)求key，也就是說(shuō)惰性刪除也沒(méi)生效闰非。這樣膘格，redis的內(nèi)存會(huì)越來(lái)越高。那么就應(yīng)該采用內(nèi)存淘汰機(jī)制财松。
在redis.conf中有一行配置
maxmemory-policy volatile-lru1
該配置就是配內(nèi)存淘汰策略的(什么瘪贱，你沒(méi)配過(guò)？好好反省一下自己)
- volatile-lru：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中挑選最近最少使用的數(shù)據(jù)淘汰
- volatile-ttl：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中挑選將要過(guò)期的數(shù)據(jù)淘汰
- volatile-random：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中任意選擇數(shù)據(jù)淘汰
- allkeys-lru：從數(shù)據(jù)集（server.db[i].dict）中挑選最近最少使用的數(shù)據(jù)淘汰
- allkeys-random：從數(shù)據(jù)集（server.db[i].dict）中任意選擇數(shù)據(jù)淘汰
- no-enviction（驅(qū)逐）：禁止驅(qū)逐數(shù)據(jù)辆毡，新寫(xiě)入操作會(huì)報(bào)錯(cuò)
ps：如果沒(méi)有設(shè)置 expire 的key, 不滿(mǎn)足先決條件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行為, 和 noeviction(不刪除) 基本上一致菜秦。
Redis 為什么是單線(xiàn)程的
官方FAQ表示，因?yàn)镽edis是基于內(nèi)存的操作舶掖，CPU不是Redis的瓶頸球昨，Redis的瓶頸最有可能是機(jī)器內(nèi)存的大小或者網(wǎng)絡(luò)帶寬。
既然單線(xiàn)程容易實(shí)現(xiàn)眨攘，而且CPU不會(huì)成為瓶頸主慰，那就順理成章地采用單線(xiàn)程的方案了（畢竟采用多線(xiàn)程會(huì)有很多麻煩！）Redis利用隊(duì)列技術(shù)將并發(fā)訪(fǎng)問(wèn)變?yōu)榇性L(fǎng)問(wèn)
1）絕大部分請(qǐng)求是純粹的內(nèi)存操作（非出晔郏快速）
2）采用單線(xiàn)程,避免了不必要的上下文切換和競(jìng)爭(zhēng)條件
3）非阻塞IO優(yōu)點(diǎn)：
- 速度快共螺，因?yàn)閿?shù)據(jù)存在內(nèi)存中，類(lèi)似于HashMap情竹，HashMap的優(yōu)勢(shì)就是查找和操作的時(shí)間復(fù)雜度都是O(1)
- 支持豐富數(shù)據(jù)類(lèi)型璃谨，支持string，list鲤妥，set佳吞，sorted set，hash
- 支持事務(wù)棉安，操作都是原子性底扳，所謂的原子性就是對(duì)數(shù)據(jù)的更改要么全部執(zhí)行，要么全部不執(zhí)行
- 豐富的特性：可用于緩存贡耽，消息衷模，按key設(shè)置過(guò)期時(shí)間，過(guò)期后將會(huì)自動(dòng)刪除如何解決redis的并發(fā)競(jìng)爭(zhēng)key問(wèn)題
同時(shí)有多個(gè)子系統(tǒng)去set一個(gè)key蒲赂。這個(gè)時(shí)候要注意什么呢阱冶？
不推薦使用redis的事務(wù)機(jī)制。因?yàn)槲覀兊纳a(chǎn)環(huán)境滥嘴，基本都是redis集群環(huán)境木蹬，做了數(shù)據(jù)分片操作。你一個(gè)事務(wù)中有涉及到多個(gè)key操作的時(shí)候若皱，這多個(gè)key不一定都存儲(chǔ)在同一個(gè)redis-server上镊叁。因此尘颓，redis的事務(wù)機(jī)制，十分雞肋晦譬。
- 如果對(duì)這個(gè)key操作疤苹，不要求順序：準(zhǔn)備一個(gè)分布式鎖，大家去搶鎖敛腌，搶到鎖就做set操作即可
- 如果對(duì)這個(gè)key操作卧土，要求順序：分布式鎖+時(shí)間戳。假設(shè)這會(huì)系統(tǒng)B先搶到鎖像樊，將key1設(shè)置為{valueB 3:05}夸溶。接下來(lái)系統(tǒng)A搶到鎖，發(fā)現(xiàn)自己的valueA的時(shí)間戳早于緩存中的時(shí)間戳凶硅，那就不做set操作了缝裁。以此類(lèi)推。
- 利用隊(duì)列足绅，將set方法變成串行訪(fǎng)問(wèn)也可以redis遇到高并發(fā)捷绑，如果保證讀寫(xiě)key的一致性
對(duì)redis的操作都是具有原子性的,是線(xiàn)程安全的操作,你不用考慮并發(fā)問(wèn)題,redis內(nèi)部已經(jīng)幫你處理好并發(fā)的問(wèn)題了。
Redis 集群方案應(yīng)該怎么做氢妈？都有哪些方案粹污？
1.twemproxy，大概概念是首量，它類(lèi)似于一個(gè)代理方式壮吩， 使用時(shí)在本需要連接 redis 的地方改為連接 twemproxy， 它會(huì)以一個(gè)代理的身份接收請(qǐng)求并使用一致性 hash 算法加缘，將請(qǐng)求轉(zhuǎn)接到具體 redis鸭叙，將結(jié)果再返回 twemproxy。
缺點(diǎn)：twemproxy 自身單端口實(shí)例的壓力拣宏，使用一致性 hash 后沈贝，對(duì) redis 節(jié)點(diǎn)數(shù)量改變時(shí)候的計(jì)算值的改變，數(shù)據(jù)無(wú)法自動(dòng)移動(dòng)到新的節(jié)點(diǎn)勋乾。
2.codis宋下，目前用的最多的集群方案，基本和 twemproxy 一致的效果辑莫，但它支持在 節(jié)點(diǎn)數(shù)量改變情況下学歧，舊節(jié)點(diǎn)數(shù)據(jù)可恢復(fù)到新 hash 節(jié)點(diǎn)
3.redis cluster3.0 自帶的集群，特點(diǎn)在于他的分布式算法不是一致性 hash各吨，而是 hash 槽的概念枝笨，以及自身支持節(jié)點(diǎn)設(shè)置從節(jié)點(diǎn)盾碗。具體看官方文檔介紹荣刑。
有沒(méi)有嘗試進(jìn)行多機(jī)redis 的部署毁欣？如何保證數(shù)據(jù)一致的则果？
主從復(fù)制忌锯，讀寫(xiě)分離
一類(lèi)是主數(shù)據(jù)庫(kù)（master）一類(lèi)是從數(shù)據(jù)庫(kù)（slave）伪嫁，主數(shù)據(jù)庫(kù)可以進(jìn)行讀寫(xiě)操作，當(dāng)發(fā)生寫(xiě)操作的時(shí)候自動(dòng)將數(shù)據(jù)同步到從數(shù)據(jù)庫(kù)偶垮，而從數(shù)據(jù)庫(kù)一般是只讀的张咳，并接收主數(shù)據(jù)庫(kù)同步過(guò)來(lái)的數(shù)據(jù)，一個(gè)主數(shù)據(jù)庫(kù)可以有多個(gè)從數(shù)據(jù)庫(kù)似舵，而一個(gè)從數(shù)據(jù)庫(kù)只能有一個(gè)主數(shù)據(jù)庫(kù)脚猾。
對(duì)于大量的請(qǐng)求怎么樣處理
redis是一個(gè)單線(xiàn)程程序，也就說(shuō)同一時(shí)刻它只能處理一個(gè)客戶(hù)端請(qǐng)求砚哗；
redis是通過(guò)IO多路復(fù)用（select龙助，epoll, kqueue，依據(jù)不同的平臺(tái)蛛芥，采取不同的實(shí)現(xiàn)）來(lái)處理多個(gè)客戶(hù)端請(qǐng)求的
Redis 常見(jiàn)性能問(wèn)題和解決方案提鸟？
(1) Master 最好不要做任何持久化工作，如 RDB 內(nèi)存快照和 AOF 日志文件
(2) 如果數(shù)據(jù)比較重要仅淑，某個(gè) Slave 開(kāi)啟 AOF 備份數(shù)據(jù)称勋，策略設(shè)置為每秒同步一次
(3) 為了主從復(fù)制的速度和連接的穩(wěn)定性， Master 和 Slave 最好在同一個(gè)局域網(wǎng)內(nèi)
(4) 盡量避免在壓力很大的主庫(kù)上增加從庫(kù)
(5) 主從復(fù)制不要用圖狀結(jié)構(gòu)涯竟，用單向鏈表結(jié)構(gòu)更為穩(wěn)定赡鲜，即：Master <- Slave1 <- Slave2 <-Slave3…
講解下Redis線(xiàn)程模型
文件事件處理器包括分別是套接字、 I/O 多路復(fù)用程序庐船、 文件事件分派器（dispatcher）银酬、 以及事件處理器。使用 I/O 多路復(fù)用程序來(lái)同時(shí)監(jiān)聽(tīng)多個(gè)套接字筐钟， 并根據(jù)套接字目前執(zhí)行的任務(wù)來(lái)為套接字關(guān)聯(lián)不同的事件處理器捡硅。
當(dāng)被監(jiān)聽(tīng)的套接字準(zhǔn)備好執(zhí)行連接應(yīng)答（accept）、讀鹊量谩（read）壮韭、寫(xiě)入（write）、關(guān)閉（close）等操作時(shí)纹因， 與操作相對(duì)應(yīng)的文件事件就會(huì)產(chǎn)生喷屋， 這時(shí)文件事件處理器就會(huì)調(diào)用套接字之前關(guān)聯(lián)好的事件處理器來(lái)處理這些事件。
I/O 多路復(fù)用程序負(fù)責(zé)監(jiān)聽(tīng)多個(gè)套接字瞭恰， 并向文件事件分派器傳送那些產(chǎn)生了事件的套接字屯曹。
工作原理：
I/O 多路復(fù)用程序負(fù)責(zé)監(jiān)聽(tīng)多個(gè)套接字， 并向文件事件分派器傳送那些產(chǎn)生了事件的套接字。
盡管多個(gè)文件事件可能會(huì)并發(fā)地出現(xiàn)恶耽， 但 I/O 多路復(fù)用程序總是會(huì)將所有產(chǎn)生事件的套接字都入隊(duì)到一個(gè)隊(duì)列里面密任， 然后通過(guò)這個(gè)隊(duì)列， 以有序（sequentially）偷俭、同步（synchronously）浪讳、每次一個(gè)套接字的方式向文件事件分派器傳送套接字：
當(dāng)上一個(gè)套接字產(chǎn)生的事件被處理完畢之后（該套接字為事件所關(guān)聯(lián)的事件處理器執(zhí)行完畢）， I/O 多路復(fù)用程序才會(huì)繼續(xù)向文件事件分派器傳送下一個(gè)套接字涌萤。如果一個(gè)套接字又可讀又可寫(xiě)的話(huà)淹遵， 那么服務(wù)器將先讀套接字， 后寫(xiě)套接字.
為什么Redis的操作是原子性的负溪，怎么保證原子性的透揣？
對(duì)于Redis而言，命令的原子性指的是：一個(gè)操作的不可以再分川抡，操作要么執(zhí)行辐真，要么不執(zhí)行。
Redis的操作之所以是原子性的崖堤，是因?yàn)镽edis是單線(xiàn)程的侍咱。（Redis新版本已經(jīng)引入多線(xiàn)程，這里基于舊版本的Redis）
Redis本身提供的所有API都是原子操作倘感，Redis中的事務(wù)其實(shí)是要保證批量操作的原子性放坏。
多個(gè)命令在并發(fā)中也是原子性的嗎？
不一定老玛， 將get和set改成單命令操作淤年，incr 。使用Redis的事務(wù)蜡豹，或者使用Redis+Lua==的方式實(shí)現(xiàn).
Redis事務(wù)
Redis事務(wù)功能是通過(guò)MULTI麸粮、EXEC、DISCARD和WATCH 四個(gè)原語(yǔ)實(shí)現(xiàn)的
Redis會(huì)將一個(gè)事務(wù)中的所有命令序列化镜廉，然后按順序執(zhí)行弄诲。
1.redis 不支持回滾“Redis 在事務(wù)失敗時(shí)不進(jìn)行回滾，而是繼續(xù)執(zhí)行余下的命令”娇唯， 所以 Redis 的內(nèi)部可以保持簡(jiǎn)單且快速齐遵。
2.如果在一個(gè)事務(wù)中的命令出現(xiàn)錯(cuò)誤，那么所有的命令都不會(huì)執(zhí)行塔插；
3.如果在一個(gè)事務(wù)中出現(xiàn)運(yùn)行錯(cuò)誤梗摇，那么正確的命令會(huì)被執(zhí)行。
注：redis的discard只是結(jié)束本次事務(wù),正確命令造成的影響仍然存在.
1）MULTI命令用于開(kāi)啟一個(gè)事務(wù)想许，它總是返回OK伶授。MULTI執(zhí)行之后断序，客戶(hù)端可以繼續(xù)向服務(wù)器發(fā)送任意多條命令，這些命令不會(huì)立即被執(zhí)行糜烹，而是被放到一個(gè)隊(duì)列中违诗，當(dāng)EXEC命令被調(diào)用時(shí)，所有隊(duì)列中的命令才會(huì)被執(zhí)行疮蹦。
2）EXEC：執(zhí)行所有事務(wù)塊內(nèi)的命令诸迟。返回事務(wù)塊內(nèi)所有命令的返回值，按命令執(zhí)行的先后順序排列挚币。當(dāng)操作被打斷時(shí)亮蒋，返回空值 nil 扣典。
3）通過(guò)調(diào)用DISCARD妆毕，客戶(hù)端可以清空事務(wù)隊(duì)列，并放棄執(zhí)行事務(wù)贮尖， 并且客戶(hù)端會(huì)從事務(wù)狀態(tài)中退出笛粘。
4）WATCH 命令可以為 Redis 事務(wù)提供 check-and-set （CAS）行為湿硝∈纠ǎ可以監(jiān)控一個(gè)或多個(gè)鍵垛膝，一旦其中有一個(gè)鍵被修改（或刪除）线衫，之后的事務(wù)就不會(huì)執(zhí)行，監(jiān)控一直持續(xù)到EXEC命令。
Redis實(shí)現(xiàn)分布式鎖
Redis為單進(jìn)程單線(xiàn)程模式休建，采用隊(duì)列模式將并發(fā)訪(fǎng)問(wèn)變成串行訪(fǎng)問(wèn)百匆，且多客戶(hù)端對(duì)Redis的連接并不存在競(jìng)爭(zhēng)關(guān)系Redis中可以使用SETNX命令實(shí)現(xiàn)分布式鎖。
將 key 的值設(shè)為 value ，當(dāng)且僅當(dāng) key 不存在。若給定的 key 已經(jīng)存在，則 SETNX 不做任何動(dòng)作
解鎖：使用 del key 命令就能釋放鎖
解決死鎖：
- 通過(guò)Redis中expire()給鎖設(shè)定最大持有時(shí)間邓线，如果超過(guò)缩歪，則Redis來(lái)幫我們釋放鎖逛球。
- 使用 setnx key “當(dāng)前系統(tǒng)時(shí)間+鎖持有的時(shí)間”和getset key “當(dāng)前系統(tǒng)時(shí)間+鎖持有的時(shí)間”組合的命令就可以實(shí)現(xiàn)。
作者：白楠楠
鏈接：cnblogs.com/bainannan/p/14105761.html
