小林當(dāng)面試官，面你 Redis ！
時(shí)間：2021-08-19 16:30:42
手機(jī)看文章
掃描二維碼
隨時(shí)隨地手機(jī)看文章
[導(dǎo)讀]我從業(yè)多年，有參加過面試，有面試過別人，經(jīng)歷過的面試不下百場。在字節(jié)跳動(dòng)的時(shí)候，作為資深面試官，深度參與校招和社招。很多人問我，面試到底考察什么？面試官究竟想聽到怎樣的回答？針對(duì)這類疑惑，我覺得最好的解答，無疑是帶著大家，以面試官視角，去進(jìn)行面試，知己知彼，百戰(zhàn)不殆，這就是我寫這...
我從業(yè)多年，有參加過面試，有面試過別人，經(jīng)歷過的面試不下百場。在字節(jié)跳動(dòng)的時(shí)候，作為資深面試官，深度參與校招和社招。
很多人問我，面試到底考察什么？面試官究竟想聽到怎樣的回答？針對(duì)這類疑惑，我覺得最好的解答，無疑是帶著大家，以面試官視角，去進(jìn)行面試，知己知彼，百戰(zhàn)不殆，這就是我寫這個(gè)系列的初衷。
話不多說，接下來就來看看我們面試官系列的第一彈吧！
這次我們的面試主題是Redis，我一般要考察的知識(shí)點(diǎn)都在下圖，根據(jù)候選人的情況，會(huì)選擇不同的知識(shí)點(diǎn)進(jìn)行提問。
通過上圖，大家對(duì)Redis面試問題也心里有數(shù)了吧？
現(xiàn)在，就讓我們來體驗(yàn)一場沉浸式面試，我擔(dān)任惡魔面試官，友情請(qǐng)來阿柴擔(dān)任面試者。
本文分為六個(gè)部分進(jìn)行：
準(zhǔn)備好了么？Let's go！
PART1 基礎(chǔ)摸底一般情況下，面試官不會(huì)上來就問難度頗高的問題，都是隨著知識(shí)點(diǎn)循序漸進(jìn)，校招更是遵從這樣的引導(dǎo)思路。所以，考察面試者都是從基礎(chǔ)知識(shí)入手，Redis當(dāng)然也不例外。
你知道Redis是什么嗎？Redis是一個(gè)數(shù)據(jù)庫，不過與傳統(tǒng)RDBM不同，Redis屬于NoSQL，也就是非關(guān)系型數(shù)據(jù)庫，它的存儲(chǔ)結(jié)構(gòu)是Key-Value。Redis的數(shù)據(jù)直接存在內(nèi)存中，讀寫速度非常快，因此 Redis被廣泛應(yīng)用于緩存方向。
那NoSQL的BASE理論是什么？可以說BASE理論是CAP中一致性的妥協(xié)。和傳統(tǒng)事務(wù)的ACID截然不同，BASE不追求強(qiáng)一致性，而是允許數(shù)據(jù)在一段時(shí)間內(nèi)是不一致的，但最終達(dá)到一致狀態(tài)，從而獲得更高的可用性和性能。
先說說你最常用的Redis命令吧？我最常用的讀操作是get a，表示獲取a對(duì)應(yīng)的數(shù)據(jù)；最常用的寫操作是setex a t b，表示將a的數(shù)據(jù)設(shè)置為b，并且在t秒后過期。
你提到了過期時(shí)間，那你知道Redis的過期鍵清除策略嗎？
過期鍵清除策略有三種，分別是定時(shí)刪除、定期刪除和惰性刪除。
定時(shí)刪除，是在設(shè)置鍵的過期時(shí)間的同時(shí)，創(chuàng)建一個(gè)定時(shí)器，讓定時(shí)器在鍵的過期時(shí)間來臨時(shí)，立即執(zhí)行對(duì)鍵的刪除操作；
定期刪除，每隔一段時(shí)間，程序就對(duì)數(shù)據(jù)庫進(jìn)行一次檢查，刪除里面的過期鍵；
惰性刪除，是指使用的時(shí)候，發(fā)現(xiàn)Key過期了，此時(shí)再進(jìn)行刪除。
Redis過期鍵采用的是定期刪除 惰性刪除二者結(jié)合的方式進(jìn)行刪除的。
如果過期鍵沒有被訪問，而周期性刪除又跟不上新鍵產(chǎn)生的速度，內(nèi)存不就慢慢耗盡了嗎？
Redis支持內(nèi)存淘汰，配置參數(shù)maxmemory_policy決定了內(nèi)存淘汰策略的策略。這個(gè)參數(shù)一共有8個(gè)枚舉值。
內(nèi)存淘汰用到的是LRU算法嗎？嗯...Redis用的是近似LRU算法，LRU算法需要一個(gè)雙向鏈表來記錄數(shù)據(jù)的最近被訪問順序，但是出于節(jié)省內(nèi)存的考慮，Redis的LRU算法并非完整的實(shí)現(xiàn)。
Redis通過對(duì)少量鍵進(jìn)行取樣，然后和目前維持的淘汰池綜合比較，回收其中的最久未被訪問的鍵。通過調(diào)整每次回收時(shí)的采樣數(shù)量maxmemory-samples，可以實(shí)現(xiàn)調(diào)整算法的精度。
顯然，面試官開門見山，摸了下阿柴的基礎(chǔ)，并進(jìn)行了一定程度的發(fā)散。看得出來，阿柴基礎(chǔ)扎實(shí)，有備而來，是時(shí)候探探他的真本事了。
PART2 數(shù)據(jù)結(jié)構(gòu)
你知道Redis有多少數(shù)據(jù)結(jié)構(gòu)嗎?？對(duì)外暴露5種Redis對(duì)象，分別是String、List、Hash、Set、Zset。底層實(shí)現(xiàn)依托于sds、ziplist、skiplist、dict等更基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)。
不錯(cuò)，知道得很清楚，能區(qū)分對(duì)外結(jié)構(gòu)和底層實(shí)現(xiàn)。那么下面就針對(duì)幾個(gè)結(jié)構(gòu)，來重點(diǎn)追問下。
那Redis字符串有什么特點(diǎn)？Redis的字符串如果保存的對(duì)象是整數(shù)類型，那么就用int存儲(chǔ)。如果不能用整數(shù)表示，就用SDS來表示，SDS通過記錄長度，和預(yù)分配空間，可以高效計(jì)算長度，進(jìn)行append操作。
嗯，能說清楚SDS就達(dá)到了面試官的預(yù)期，如果能根據(jù)不同數(shù)據(jù)類型講清楚，加分！
Hash擴(kuò)容過程是怎樣的？兩張Hash表，平常起作用的都是0號(hào)表，當(dāng)裝載因子超過閾值時(shí)就會(huì)進(jìn)行Rehash，將0號(hào)每上每一個(gè)bucket慢慢移動(dòng)到1號(hào)表，所以叫漸進(jìn)式Rehash，這種方式可以減少遷移系統(tǒng)的影響。
慢慢移動(dòng)？能詳細(xì)說下Rehash過程嗎？
當(dāng)周期函數(shù)發(fā)現(xiàn)為裝載因子超過閾值時(shí)就會(huì)進(jìn)行Rehash。Rehash的流程大概分成三步。
首先，生成新Hash表ht[1]，為 ht[1] 分配空間。此時(shí)字典同時(shí)持有ht[0]和ht[1]兩個(gè)哈希表。字典的偏移索引從靜默狀態(tài)-1，設(shè)置為0，表示Rehash 工作正式開始。
然后，遷移ht[0]數(shù)據(jù)到ht[1]。在 Rehash進(jìn)行期間，每次對(duì)字典執(zhí)行增刪查改操作，程序會(huì)順帶遷移一個(gè)ht[0]上的數(shù)據(jù)，并更新偏移索引。與此同時(shí)，周期函數(shù)也會(huì)定時(shí)遷移一批。
最后，ht[1]和ht[0]指針對(duì)象交換。隨著字典操作的不斷執(zhí)行， 最終在某個(gè)時(shí)間點(diǎn)上，ht[0]的所有鍵值對(duì)都會(huì)被Rehash至 ht[1]，此時(shí)再將ht[1]和ht[0]指針對(duì)象互換，同時(shí)把偏移索引的值設(shè)為-1，表示Rehash操作已完成。
如果字典正在Rehash，此時(shí)有請(qǐng)求過來，Redis會(huì)怎么處理？
針對(duì)新增Key，是往ht[1]里面插入。針對(duì)讀請(qǐng)求，先從ht[0]讀，沒找到再去ht[1]找。至于刪除和更新，其實(shí)本質(zhì)是先找到位置，再進(jìn)行操作，所以和讀請(qǐng)求一樣，先找ht[0]，再找ht[1]，找到之后再進(jìn)行操作。
接下來講講跳表的實(shí)現(xiàn)吧。跳表本質(zhì)上是對(duì)鏈表的一種優(yōu)化，通過逐層跳步采樣的方式構(gòu)建索引，以加快查找速度。如果只用普通鏈表，只能一個(gè)一個(gè)往后找。跳表就不一樣了，可以高層索引，一次跳躍多個(gè)節(jié)點(diǎn)，如果找過頭了，就用更下層的索引。
圖片來自維基百科
那每個(gè)節(jié)點(diǎn)有多少層呢？使用概率均衡的思路，確定新插入節(jié)點(diǎn)的層數(shù)。Redis使用隨機(jī)函數(shù)決定層數(shù)。直觀上來說，默認(rèn)1層，和丟硬幣一樣，如果是正面就繼續(xù)往上，這樣持續(xù)迭代，最大層數(shù)32層。
可以看到，50%的概率被分配到第一層，25%的概率被分配到第二層，12.5%的概率被分配到第三層。這種方式保證了越上層數(shù)量越少，自然跨越起來越方便。
跳表原理說清楚就達(dá)標(biāo)，說出層次算法加分。
Redis的Zset為什么同時(shí)需要字典和跳表來實(shí)現(xiàn)？
Zset是一個(gè)有序列表，字典和跳表分別對(duì)應(yīng)兩種查詢場景，字典用來支持按成員查詢數(shù)據(jù)，跳表則用以實(shí)現(xiàn)高效的范圍查詢，這樣兩個(gè)場景，性能都做到了極致。
Redis的數(shù)據(jù)結(jié)構(gòu)包含了很多干貨，在細(xì)節(jié)處見功夫，阿柴對(duì)答如流。面試官不由地更加期待他接下來的表現(xiàn)了。
PART3 系統(tǒng)容災(zāi)
Redis是基于內(nèi)存的存儲(chǔ)，如果服務(wù)重啟，數(shù)據(jù)不就丟失了嗎？
可以通過持久化機(jī)制，備份數(shù)據(jù)。有兩種方式，一種是開啟RDB，RDB是Redis的二進(jìn)制快照文件，優(yōu)點(diǎn)是文件緊湊，占用空間小，恢復(fù)速度比較快。同時(shí)，由于是子進(jìn)程Fork的模式，對(duì)Redis本身讀寫性能的影響很小。
另一種方式是AOF，AOF中記錄了Redis的操作命令，可以重放請(qǐng)求恢復(fù)現(xiàn)場，AOF的文件會(huì)比RDB大很多。
出于性能考慮，如果開啟了AOF，會(huì)將命令先記錄在AOF緩沖，之后再刷入磁盤。數(shù)據(jù)刷入磁盤的時(shí)機(jī)根據(jù)參數(shù)決定，有三種模式：1.關(guān)閉時(shí)刷入；2.每秒定期刷入；3.執(zhí)行命令后立刻觸發(fā)。
AOF的優(yōu)點(diǎn)是故障情況下，丟失的數(shù)據(jù)會(huì)比RDB更少。如果是執(zhí)行命令后立馬刷入，AOF會(huì)拖累執(zhí)行速度，所以一般都是配置為每秒定期刷入，這樣對(duì)性能影響不會(huì)很大。
AOF運(yùn)行原理-創(chuàng)建
這樣看起來，AOF文件會(huì)越來越大，最后磁盤都裝不下？
不會(huì)的，Redis可以在AOF文件體積變得過大時(shí)，自動(dòng)地在后臺(tái)Fork一個(gè)子進(jìn)程，專門對(duì)AOF進(jìn)行重寫。說白了，就是針對(duì)相同Key的操作，進(jìn)行合并，比如同一個(gè)Key的set操作，那就是后面覆蓋前面。
在重寫過程中，Redis不但將新的操作記錄在原有的AOF緩沖區(qū)，而且還會(huì)記錄在AOF重寫緩沖區(qū)。一旦新AOF文件創(chuàng)建完畢，Redis 就會(huì)將重寫緩沖區(qū)內(nèi)容，追加到新的AOF文件，再用新AOF文件替換原來的AOF文件。
Redis機(jī)器掛掉怎么辦？可以用主從模式部署，即有一個(gè)或多個(gè)備用機(jī)器，備用機(jī)會(huì)作為Slave同步Master的數(shù)據(jù)，在Redis出現(xiàn)問題的時(shí)候，把Slave升級(jí)為Master。
主從可以自動(dòng)切換嗎？本身是不能，但可以寫腳本實(shí)現(xiàn)，只是需要考慮的問題比較多。Redis已經(jīng)有了現(xiàn)成的解決方案：哨兵模式。哨兵來監(jiān)測Redis服務(wù)是否正常，異常情況下，由哨兵代理切換。為避免哨兵成為單點(diǎn)，哨兵也需要多機(jī)部署。
如果Master掛掉，會(huì)選擇哪個(gè)Slave呢？
當(dāng)哨兵集群選舉出哨兵Leader后，由哨兵Leader從Redis從節(jié)點(diǎn)中選擇一個(gè)Redis節(jié)點(diǎn)作為主節(jié)點(diǎn)：
1.過濾故障的節(jié)點(diǎn)；2.選擇優(yōu)先級(jí)slave-priority最大的從節(jié)點(diǎn)作為主節(jié)點(diǎn)，如不存在，則繼續(xù)；
3.選擇復(fù)制偏移量最大的從節(jié)點(diǎn)作為主節(jié)點(diǎn)，如果都一樣，則繼續(xù)。這里解釋下，數(shù)據(jù)偏移量記錄寫了多少數(shù)據(jù)，主服務(wù)器會(huì)把偏移量同步給從服務(wù)器，當(dāng)主從的偏移量一致，則數(shù)據(jù)是完全同步；
4.選擇runid最小的從節(jié)點(diǎn)作為主節(jié)點(diǎn)。Redis每次啟動(dòng)的時(shí)候生成隨機(jī)的runid作為Redis的標(biāo)識(shí)。
前面你提到了哨兵Leader，那它是怎么來的呢？
每一個(gè)哨兵節(jié)點(diǎn)都可以成為Leader，當(dāng)一個(gè)哨兵節(jié)點(diǎn)確認(rèn)Redis集群的主節(jié)點(diǎn)主觀下線后，會(huì)請(qǐng)求其他哨兵節(jié)點(diǎn)要求將自己選舉為Leader。被請(qǐng)求的哨兵節(jié)點(diǎn)如果沒有同意過其他哨兵節(jié)點(diǎn)的選舉請(qǐng)求，則同意該請(qǐng)求，也就是選舉票數(shù) 1，否則不同意。
如果一個(gè)哨兵節(jié)點(diǎn)獲得的選舉票數(shù)超過節(jié)點(diǎn)數(shù)的一半，且大于quorum配置的值，則該哨兵節(jié)點(diǎn)選舉為Leader；否則重新進(jìn)行選舉。
PART4 性能優(yōu)化
Redis性能怎么樣？只能說在十萬級(jí)。使用之前，要跑BenchMark，實(shí)際情況下會(huì)受帶寬、負(fù)載、單個(gè)數(shù)據(jù)大小、是否開啟多線程等因素影響，脫開具體場景談性能，就沒有意義。
Redis性能這么高，那它是協(xié)程模型，還是多線程模型？
Redis是單線程Reactor模型，通過高效的IO復(fù)用以及內(nèi)存處理實(shí)現(xiàn)高性能。如果是6.0之前我會(huì)毫不猶豫說是單線程，6.0之后，我還是會(huì)說單線程，但會(huì)補(bǔ)充一句，IO解包通過多線程進(jìn)行了優(yōu)化，而處理邏輯，還是單線程。
另外，如果考慮到RDB的Fork，一些定時(shí)任務(wù)的處理，那么Redis也可以說多進(jìn)程，這沒有問題。但是Redis對(duì)數(shù)據(jù)的處理，至始至終，都是單線程。
可以詳細(xì)說下6.0版本發(fā)布的多線程功能嗎？
多線程功能，主要用于提高解包的效率。和傳統(tǒng)的Multi Reactor多線程模型不同，Redis的多線程只負(fù)責(zé)處理網(wǎng)絡(luò)IO的解包和協(xié)議轉(zhuǎn)換，一方面是因?yàn)镽edis的單線程處理足夠快，另一方面也是為了兼容性做考慮。
如果數(shù)據(jù)太大，Redis存不下了怎么辦？
使用集群模式。也就是將數(shù)據(jù)分片，不同的Key根據(jù)Hash路由到不同的節(jié)點(diǎn)。集群索引是通過一致性Hash算法來完成，這種算法可以解決服務(wù)器數(shù)量發(fā)生改變時(shí)，所有的服務(wù)器緩存在同一時(shí)間失效的問題。
同時(shí)，基于Gossip協(xié)議，集群狀態(tài)變化時(shí)，如新節(jié)點(diǎn)加入、節(jié)點(diǎn)宕機(jī)、Slave提升為新Master，這些變化都能傳播到整個(gè)集群的所有節(jié)點(diǎn)并達(dá)成一致。
一致性Hash能詳細(xì)講一下嗎？好的，傳統(tǒng)的Hash分片，可以將某個(gè)Key，落到某個(gè)節(jié)點(diǎn)。但有一個(gè)問題，當(dāng)節(jié)點(diǎn)擴(kuò)容或者縮容，路由會(huì)被完全打亂。如果是緩存場景，很容易造成緩存雪崩問題。
為了優(yōu)化這種情況，一致性Hash就應(yīng)運(yùn)而生了。一致性Hash是說將數(shù)據(jù)和服務(wù)器，以相同的Hash函數(shù)，映射到同一個(gè)Hash環(huán)上，針對(duì)一個(gè)對(duì)象，在哈希環(huán)上順時(shí)針查找距其最近的機(jī)器，這個(gè)機(jī)器就負(fù)責(zé)處理該對(duì)象的相關(guān)請(qǐng)求。
這種情況下，增加節(jié)點(diǎn)，只會(huì)分流后面一個(gè)節(jié)點(diǎn)的數(shù)據(jù)。減少節(jié)點(diǎn)，那么請(qǐng)求會(huì)由后一個(gè)節(jié)點(diǎn)繼承。也就是說，節(jié)點(diǎn)變化操作，最多只會(huì)影響后面一個(gè)節(jié)點(diǎn)的數(shù)據(jù)。
好了，看你對(duì)Redis掌握還不錯(cuò)，下面我們來聊聊場景相關(guān)的應(yīng)用吧。
PART5 場景應(yīng)用
Redis經(jīng)常用作緩存，那數(shù)據(jù)一致性怎么保證？
從設(shè)計(jì)思路來說，有Cache Aside和Read/Write Through兩種模式，前者是把緩存責(zé)任交給應(yīng)用層，后者是將緩存的責(zé)任，放置到服務(wù)提供方。
你說到兩種模式，那么哪種模式更好呢？
兩種模式各有優(yōu)缺點(diǎn)，從透明性考慮，服務(wù)方比較合適；如果從性能極致來說，業(yè)務(wù)方會(huì)更有優(yōu)勢，畢竟可以減去服務(wù)RPC的損耗。
嗯，如果數(shù)據(jù)發(fā)生變化，你會(huì)怎樣去更新緩存？
更新方式的話，大概有四種：
1.數(shù)據(jù)存到數(shù)據(jù)庫中，成功后，再讓緩存失效，等到讀緩存不命中的時(shí)候，再加載進(jìn)去；
2.通過消息隊(duì)列更新緩存；3.先更新緩存，再更新服務(wù)，這種情況相當(dāng)于把Cache也做Buffer用；
4.起一個(gè)同步服務(wù)，作為MySQL一個(gè)從節(jié)點(diǎn)，通過解析binlog同步重要緩存。
那我們來談?wù)凴edis緩存雪崩。緩存雪崩表示在某一時(shí)間段，緩存集中失效，導(dǎo)致請(qǐng)求全部走數(shù)據(jù)庫，有可能搞垮數(shù)據(jù)庫，使整個(gè)服務(wù)癱瘓。雪崩原因一般是由于緩存過期時(shí)間設(shè)置得相同造成的。
針對(duì)這種情況，可以借鑒ETCD中Raft選舉的優(yōu)化，讓過期時(shí)間隨機(jī)化，避免同一批請(qǐng)求，在同一時(shí)間過期。另一方面，還可以業(yè)務(wù)層面容災(zāi)，為熱點(diǎn)數(shù)據(jù)使用雙緩存。
那Redis緩存穿透又是什么？緩存穿透指請(qǐng)求數(shù)據(jù)庫里面根本沒有的數(shù)據(jù)，高頻請(qǐng)求不存在的Key，有可能是正常的業(yè)務(wù)邏輯，但更可能的，是黑客的攻擊。
可以用布隆過濾器來應(yīng)對(duì)，布隆過濾器是一種比較巧妙的概率型數(shù)據(jù)結(jié)構(gòu)，特點(diǎn)是高效地插入和查詢，可以用來告訴我們?“某樣?xùn)|西一定不存在或者可能存在”。
那你說一下布隆過濾器的實(shí)現(xiàn)吧。布隆過濾器底層是一個(gè)64位的整型，將字符串用多個(gè)Hash函數(shù)映射不同的二進(jìn)制位置，將整型中對(duì)應(yīng)位置設(shè)置為1。
在查詢的時(shí)候，如果一個(gè)字符串所有Hash函數(shù)映射的值都存在，那么數(shù)據(jù)可能存在。為什么說可能呢，就是因?yàn)槠渌址赡苷紦?jù)該值，提前點(diǎn)亮。
可以看到，布隆過濾器優(yōu)缺點(diǎn)都很明顯，優(yōu)點(diǎn)是空間、時(shí)間消耗都很小，缺點(diǎn)是結(jié)果不是完全準(zhǔn)確。
還有個(gè)概念叫緩存擊穿，你能講講看嗎？
嗯...緩存擊穿，是指某一熱鍵，被超高的并發(fā)訪問，在失效的一瞬間，還沒來得及重新產(chǎn)生，就有海量數(shù)據(jù)，直達(dá)數(shù)據(jù)庫，可謂是兵臨城下。
這種情況和緩存雪崩的不同之處，在于雪崩是大量緩存趕巧兒一起過期，擊穿只是單個(gè)超熱鍵失效。
這種超高頻Key，我們要提高待遇，可以讓它不過期，再單獨(dú)實(shí)現(xiàn)數(shù)據(jù)同步邏輯，來維護(hù)數(shù)據(jù)的一致性。當(dāng)然，無論如何，對(duì)后端肯定是需要限頻的，不然如果Redis數(shù)據(jù)丟失，數(shù)據(jù)庫還是會(huì)被打崩。限頻方式可以是分布式鎖或分布式令牌桶。
那Redis可以做消息隊(duì)列嗎？
嗯...可以是可以，但我覺得用它來做消息隊(duì)列不合適。Redis本身沒有支持AMQP規(guī)范，消息隊(duì)列該有的能力缺胳膊少腿，消息可靠性不強(qiáng)。
因?yàn)榭傆腥四肦edis做消息隊(duì)列。Redis的作者都看不下去了，趕緊出了個(gè)Disque來專事專做，雖然沒大紅大紫，但至少明確告訴了我們，Redis，別拿來做消息隊(duì)列！
那你能談?wù)凴edis在秒殺場景的應(yīng)用嗎？
Redis主要是起到選拔流量的作用，記錄商品總數(shù)，還有就是已下單數(shù)，等達(dá)到總數(shù)之后攔截所有請(qǐng)求?？梢远喾判┱?qǐng)求進(jìn)來，然后塞入消息隊(duì)列。
螞蟻金服的云Redis提到消息隊(duì)列可以用Redis來實(shí)現(xiàn)，但我覺得更好的方式是用Kafka這種標(biāo)準(zhǔn)消息隊(duì)列組件。
你能繼續(xù)說說Redis在分布式鎖中的應(yīng)用嗎？
鎖是計(jì)算機(jī)領(lǐng)域一個(gè)非常常見的概念，分布式鎖也依賴存儲(chǔ)組件，針對(duì)請(qǐng)求量的不同，可以選擇Etcd、MySQL、Redis等。前兩者可靠性更強(qiáng)，Redis性能更高。
那我們?cè)倭牧腞edis在限流場景的應(yīng)用吧。
在微服務(wù)架構(gòu)下，限頻器也需要分布式化。無論是哪種算法，都可以結(jié)合Redis來實(shí)現(xiàn)。這里我比較熟悉的是基于Redis的分布式令牌桶。
很顯然，Redis負(fù)責(zé)管理令牌，微服務(wù)需要進(jìn)行函數(shù)操作，就向Redis申請(qǐng)令牌，如果Redis當(dāng)前還有令牌，就發(fā)放給它。拿到令牌，才能進(jìn)行下一步操作。
另一方面，令牌不光要消耗，還需要補(bǔ)充，出于性能考慮，可以使用懶生成的方式：使用令牌時(shí)，順便生成令牌。這樣子還有個(gè)好處：令牌的獲取，和令牌的生成，都可以在一個(gè)Lua腳本中，保證了原子性。
可以了，你就是我們想要的仔。
PART6 面試點(diǎn)評(píng)
Redis是后臺(tái)開發(fā)中非常重要的領(lǐng)域，更是面試環(huán)節(jié)的高頻考點(diǎn)，希望通過這種形式，讓大家切身體會(huì)到面試的要點(diǎn)在哪里，并針對(duì)這些做專門的準(zhǔn)備。
本次阿柴憑借著極高的修為，擊退了惡魔面試官牛牛，但這不是結(jié)束，僅僅是個(gè)開端。
下載文檔
