Q：
Redis集群最大節(jié)點個數(shù)是多少?
16384個

Q：
Redis集群的主從復(fù)制模型是怎樣的?
為了使在部分節(jié)點失敗或者大部分節(jié)點無法通信的情況下集群仍然可用，所以集群使用了主從復(fù)制模型，每個點都會有N-1個復(fù)制品

Q：
Redis和 Redisson有什么關(guān)系?
Redisson是一個高級的分布式協(xié)調(diào)redis客服端，能幫助用戶在分布式環(huán)境中輕松實現(xiàn)一些java的對象(Bloom filter，BitSet，set， SetMultimap， ScoredSortedSet，SortedSet， Map，ConcurrentMap， List， List Multimap， Queue， BlockingQueue， Deque， Blocking Deque， Semaphore， Lock， ReadWriteLock， Atomi cLong， CountDownLa， Publish/ Subscribe， HyperLogLog)

Q：
MySQL里有2000w數(shù)據(jù)， redis中只存20w的數(shù)據(jù)，如何保證 redis中的數(shù)據(jù)都是熱點數(shù)據(jù)?
redis內(nèi)存數(shù)據(jù)集大小上升到一定大小的時候，就會實行數(shù)據(jù)淘汰策略。

Q：
Redis集群方案應(yīng)該怎么做?都有哪些方案?
1.codis
目前用的最多的集群方案，基本和 twemproxy一致的效果，但它支持在節(jié)點數(shù)量改變情況下，舊節(jié)點數(shù)據(jù)可恢復(fù)到新hash節(jié)點。

2.redis cluster3.0
自帶的集群，特點在于他的分布式算法不是一致性hash，而是hash槽的概念，以及自身支持節(jié)點設(shè)置從節(jié)點。

3.在業(yè)務(wù)代碼層實現(xiàn)
起幾個毫無關(guān)聯(lián)的 redis實例，在代碼層對key進(jìn)行hash計算，然后去對應(yīng)的 redis實例操作數(shù)據(jù)。這種方式對hash層代碼要求比較高，考慮部分包括，節(jié)點失效后的替代算法方案，數(shù)據(jù)震蕩后的自動腳本恢復(fù)，實例的監(jiān)控等等。

Q：
Redis集群方案什么情況下會導(dǎo)致整個集群不可用?
有A，B，C三個節(jié)點的集群，在沒有復(fù)制模型的情況下，如果節(jié)點B失敗了，那么整個集群就會因為缺少5501-11000這個范圍的槽而不可用。

Q：
假如 Redis里面有1億個key，其中有10w個key是以某個固定的已知的前綴開頭的，如果將它們?nèi)空页鰜?
使用keys指令可以掃出指定模式的key列表。

對方接著追問如果這個 redis正在給線上的業(yè)務(wù)提供服務(wù)，那使用keys指令會有什么問題?這個時候你要回答 redis關(guān)鍵的一個特性redis的單線程的。keys指令會導(dǎo)致線程阻塞一段時間，線上服務(wù)會停頓，直到指令執(zhí)行完畢，服務(wù)才能恢復(fù)。這個時候可以使用scan指令，scan指令可以無阻塞的提取出指定模式的key列表，但是會有一定的重復(fù)概率，在客戶端做一次去重就可以了，但是整體所花費的時間會比直接用keys指令長。

Q：
主從數(shù)據(jù)庫不一致如何解決？
對于主從庫，讀寫分離，如果主從庫更新同步有時差，就會導(dǎo)致主從庫數(shù)據(jù)的不一致
1、忽略這個數(shù)據(jù)不一致，在數(shù)據(jù)一致性要求不高的業(yè)務(wù)下，未必需要時時一致性
2、強制讀主庫，使用一個高可用的主庫，數(shù)據(jù)庫讀寫都在主庫，添加一個緩存，提升數(shù)據(jù)讀取的性能。
3、選擇性讀主庫，添加一個緩存，用來記錄必須讀主庫的數(shù)據(jù)，將哪個庫，哪個表，哪個主鍵，作為緩存的key，設(shè)置緩存失效的時間為主從庫同步的時間，如果緩存當(dāng)中有這個數(shù)據(jù)，直接讀取主庫；如果緩存當(dāng)中沒有這個主鍵，就到對應(yīng)的從庫中讀取。

Q：
緩存與數(shù)據(jù)庫不一致怎么辦？
假設(shè)采用的主存分離，讀寫分離的數(shù)據(jù)庫，如果一個線程A先刪除緩存數(shù)據(jù)，然后將數(shù)據(jù)寫入到主庫當(dāng)中，這個時候，主庫和從庫同步?jīng)]有完成，線程B從緩存當(dāng)中讀取數(shù)據(jù)失敗，從從庫當(dāng)中讀取到舊數(shù)據(jù)，然后更新至緩存，這個時候，緩存當(dāng)中的就是舊的數(shù)據(jù)。
發(fā)生上述不一致的原因在于，主從庫數(shù)據(jù)不一致問題，加入了緩存之后，主從不一致的時間被拉長了；
處理：在從庫有數(shù)據(jù)更新之后，將緩存當(dāng)中的數(shù)據(jù)也同時進(jìn)行更新，即當(dāng)從庫發(fā)生了數(shù)據(jù)更新之后，向緩存發(fā)出刪除，淘汰這段時間寫入的舊數(shù)據(jù)。

總結(jié)

以上是生活随笔為你收集整理的分布式面试题（二）：分布式Redis的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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