1. 使用Redis有哪些好處？
(1) 速度快，因?yàn)閿?shù)據(jù)存在內(nèi)存中，類似于HashMap，HashMap的優(yōu)勢就是查找和操作的時(shí)間復(fù)雜度都是O(1)
(2) 支持豐富數(shù)據(jù)類型，支持string，list，set，sorted set，hash
(3) 支持事務(wù)，操作都是原子性，所謂的原子性就是對(duì)數(shù)據(jù)的更改要么全部執(zhí)行，要么全部不執(zhí)行
(4) 豐富的特性：可用于緩存，消息，按key設(shè)置過期時(shí)間，過期后將會(huì)自動(dòng)刪除
2. redis相比memcached有哪些優(yōu)勢？
(1) memcached所有的值均是簡單的字符串，redis作為其替代者，支持更為豐富的數(shù)據(jù)類型
(2) redis的速度比memcached快很多
(3) redis可以持久化其數(shù)據(jù)
3. redis常見性能問題和解決方案：
(1) Master最好不要做任何持久化工作，如RDB內(nèi)存快照和AOF日志文件
(2) 如果數(shù)據(jù)比較重要，某個(gè)Slave開啟AOF備份數(shù)據(jù)，策略設(shè)置為每秒同步一次
(3) 為了主從復(fù)制的速度和連接的穩(wěn)定性，Master和Slave最好在同一個(gè)局域網(wǎng)內(nèi)
(4) 盡量避免在壓力很大的主庫上增加從庫
(5) 主從復(fù)制不要用圖狀結(jié)構(gòu)，用單向鏈表結(jié)構(gòu)更為穩(wěn)定，即：Master <- Slave1 <- Slave2 <- Slave3…
這樣的結(jié)構(gòu)方便解決單點(diǎn)故障問題，實(shí)現(xiàn)Slave對(duì)Master的替換。如果Master掛了，可以立刻啟用Slave1做Master，其他不變。
4. MySQL里有2000w數(shù)據(jù)，redis中只存20w的數(shù)據(jù)，如何保證redis中的數(shù)據(jù)都是熱點(diǎn)數(shù)據(jù)
相關(guān)知識(shí)：redis 內(nèi)存數(shù)據(jù)集大小上升到一定大小的時(shí)候，就會(huì)施行數(shù)據(jù)淘汰策略。redis 提供 6種數(shù)據(jù)淘汰策略：
voltile-lru：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中挑選最近最少使用的數(shù)據(jù)淘汰
volatile-ttl：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中挑選將要過期的數(shù)據(jù)淘汰
volatile-random：從已設(shè)置過期時(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ù)
5. Memcache與Redis的區(qū)別都有哪些？
1)、存儲(chǔ)方式
Memecache把數(shù)據(jù)全部存在內(nèi)存之中，斷電后會(huì)掛掉，數(shù)據(jù)不能超過內(nèi)存大小。
Redis有部份存在硬盤上，這樣能保證數(shù)據(jù)的持久性。
2)、數(shù)據(jù)支持類型
Memcache對(duì)數(shù)據(jù)類型支持相對(duì)簡單。
Redis有復(fù)雜的數(shù)據(jù)類型。
3)、使用底層模型不同
它們之間底層實(shí)現(xiàn)方式 以及與客戶端之間通信的應(yīng)用協(xié)議不一樣。
Redis直接自己構(gòu)建了VM 機(jī)制 ，因?yàn)橐话愕南到y(tǒng)調(diào)用系統(tǒng)函數(shù)的話，會(huì)浪費(fèi)一定的時(shí)間去移動(dòng)和請(qǐng)求。
4），value大小
redis最大可以達(dá)到1GB，而memcache只有1MB
6. Redis 常見的性能問題都有哪些？如何解決？
1).Master寫內(nèi)存快照，save命令調(diào)度rdbSave函數(shù)，會(huì)阻塞主線程的工作，當(dāng)快照比較大時(shí)對(duì)性能影響是非常大的，會(huì)間斷性暫停服務(wù)，所以Master最好不要寫內(nèi)存快照。
2).Master AOF持久化，如果不重寫AOF文件，這個(gè)持久化方式對(duì)性能的影響是最小的，但是AOF文件會(huì)不斷增大，AOF文件過大會(huì)影響Master重啟的恢復(fù)速度。Master最好不要做任何持久化工作，包括內(nèi)存快照和AOF日志文件，特別是不要啟用內(nèi)存快照做持久化,如果數(shù)據(jù)比較關(guān)鍵，某個(gè)Slave開啟AOF備份數(shù)據(jù)，策略為每秒同步一次。
3).Master調(diào)用BGREWRITEAOF重寫AOF文件，AOF在重寫的時(shí)候會(huì)占大量的CPU和內(nèi)存資源，導(dǎo)致服務(wù)load過高，出現(xiàn)短暫服務(wù)暫?，F(xiàn)象。
4). Redis主從復(fù)制的性能問題，為了主從復(fù)制的速度和連接的穩(wěn)定性，Slave和Master最好在同一個(gè)局域網(wǎng)內(nèi)
7, redis 最適合的場景
Redis最適合所有數(shù)據(jù)in-momory的場景，雖然Redis也提供持久化功能，但實(shí)際更多的是一個(gè)disk-backed的功能，跟傳統(tǒng)意義上的持久化有比較大的差別，那么可能大家就會(huì)有疑問，似乎Redis更像一個(gè)加強(qiáng)版的Memcached，那么何時(shí)使用Memcached,何時(shí)使用Redis呢?
如果簡單地比較Redis與Memcached的區(qū)別，大多數(shù)都會(huì)得到以下觀點(diǎn)：
1 、Redis不僅僅支持簡單的k/v類型的數(shù)據(jù)，同時(shí)還提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。
2 、Redis支持?jǐn)?shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。
3 、Redis支持?jǐn)?shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤中，重啟的時(shí)候可以再次加載進(jìn)行使用。
（1）、會(huì)話緩存（Session Cache）
最常用的一種使用Redis的情景是會(huì)話緩存（session cache）。用Redis緩存會(huì)話比其他存儲(chǔ)（如Memcached）的優(yōu)勢在于：Redis提供持久化。當(dāng)維護(hù)一個(gè)不是嚴(yán)格要求一致性的緩存時(shí)，如果用戶的購物車信息全部丟失，大部分人都會(huì)不高興的，現(xiàn)在，他們還會(huì)這樣嗎？
幸運(yùn)的是，隨著 Redis 這些年的改進(jìn)，很容易找到怎么恰當(dāng)?shù)氖褂肦edis來緩存會(huì)話的文檔。甚至廣為人知的商業(yè)平臺(tái)Magento也提供Redis的插件。
（2）、全頁緩存（FPC）
除基本的會(huì)話token之外，Redis還提供很簡便的FPC平臺(tái)。回到一致性問題，即使重啟了Redis實(shí)例，因?yàn)橛写疟P的持久化，用戶也不會(huì)看到頁面加載速度的下降，這是一個(gè)極大改進(jìn)，類似PHP本地FPC。
再次以Magento為例，Magento提供一個(gè)插件來使用Redis作為全頁緩存后端。
此外，對(duì)WordPress的用戶來說，Pantheon有一個(gè)非常好的插件 wp-redis，這個(gè)插件能幫助你以最快速度加載你曾瀏覽過的頁面。
（3）、隊(duì)列
Reids在內(nèi)存存儲(chǔ)引擎領(lǐng)域的一大優(yōu)點(diǎn)是提供 list 和 set 操作，這使得Redis能作為一個(gè)很好的消息隊(duì)列平臺(tái)來使用。Redis作為隊(duì)列使用的操作，就類似于本地程序語言（如Python）對(duì) list 的 push/pop 操作。
如果你快速的在Google中搜索“Redis queues”，你馬上就能找到大量的開源項(xiàng)目，這些項(xiàng)目的目的就是利用Redis創(chuàng)建非常好的后端工具，以滿足各種隊(duì)列需求。例如，Celery有一個(gè)后臺(tái)就是使用Redis作為broker，你可以從這里去查看。
（4），排行榜/計(jì)數(shù)器
Redis在內(nèi)存中對(duì)數(shù)字進(jìn)行遞增或遞減的操作實(shí)現(xiàn)的非常好。集合（Set）和有序集合（Sorted Set）也使得我們?cè)趫?zhí)行這些操作的時(shí)候變的非常簡單，Redis只是正好提供了這兩種數(shù)據(jù)結(jié)構(gòu)。所以，我們要從排序集合中獲取到排名最靠前的10個(gè)用戶–我們稱之為“user_scores”，我們只需要像下面一樣執(zhí)行即可：
當(dāng)然，這是假定你是根據(jù)你用戶的分?jǐn)?shù)做遞增的排序。如果你想返回用戶及用戶的分?jǐn)?shù)，你需要這樣執(zhí)行：
ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一個(gè)很好的例子，用Ruby實(shí)現(xiàn)的，它的排行榜就是使用Redis來存儲(chǔ)數(shù)據(jù)的，你可以在這里看到。
（5）、發(fā)布/訂閱
最后（但肯定不是最不重要的）是Redis的發(fā)布/訂閱功能。發(fā)布/訂閱的使用場景確實(shí)非常多。我已看見人們?cè)谏缃痪W(wǎng)絡(luò)連接中使用，還可作為基于發(fā)布/訂閱的腳本觸發(fā)器，甚至用Redis的發(fā)布/訂閱功能來建立聊天系統(tǒng)！（不，這是真的，你可以去核實(shí)）。
Redis提供的所有特性中，我感覺這個(gè)是喜歡的人最少的一個(gè)，雖然它為用戶提供如果此多功能。
高可用分布式集群
一，高可用
高可用（High Availability），是當(dāng)一臺(tái)服務(wù)器停止服務(wù)后，對(duì)于業(yè)務(wù)及用戶毫無影響。 停止服務(wù)的原因可能由于網(wǎng)卡、路由器、機(jī)房、CPU負(fù)載過高、內(nèi)存溢出、自然災(zāi)害等不可預(yù)期的原因?qū)е?，在很多時(shí)候也稱單點(diǎn)問題。
（1）解決單點(diǎn)問題主要有2種方式：
主備方式
這種通常是一臺(tái)主機(jī)、一臺(tái)或多臺(tái)備機(jī)，在正常情況下主機(jī)對(duì)外提供服務(wù)，并把數(shù)據(jù)同步到備機(jī)，當(dāng)主機(jī)宕機(jī)后，備機(jī)立刻開始服務(wù)。
Redis HA中使用比較多的是keepalived，它使主機(jī)備機(jī)對(duì)外提供同一個(gè)虛擬IP，客戶端通過虛擬IP進(jìn)行數(shù)據(jù)操作，正常期間主機(jī)一直對(duì)外提供服務(wù)，宕機(jī)后VIP自動(dòng)漂移到備機(jī)上。
優(yōu)點(diǎn)是對(duì)客戶端毫無影響，仍然通過VIP操作。
缺點(diǎn)也很明顯，在絕大多數(shù)時(shí)間內(nèi)備機(jī)是一直沒使用，被浪費(fèi)著的。
主從方式
這種采取一主多從的辦法，主從之間進(jìn)行數(shù)據(jù)同步。 當(dāng)Master宕機(jī)后，通過選舉算法(Paxos、Raft)從slave中選舉出新Master繼續(xù)對(duì)外提供服務(wù)，主機(jī)恢復(fù)后以slave的身份重新加入。
主從另一個(gè)目的是進(jìn)行讀寫分離，這是當(dāng)單機(jī)讀寫壓力過高的一種通用型解決方案。 其主機(jī)的角色只提供寫操作或少量的讀，把多余讀請(qǐng)求通過負(fù)載均衡算法分流到單個(gè)或多個(gè)slave服務(wù)器上。
缺點(diǎn)是主機(jī)宕機(jī)后，Slave雖然被選舉成新Master了，但對(duì)外提供的IP服務(wù)地址卻發(fā)生變化了，意味著會(huì)影響到客戶端。 解決這種情況需要一些額外的工作，在當(dāng)主機(jī)地址發(fā)生變化后及時(shí)通知到客戶端，客戶端收到新地址后，使用新地址繼續(xù)發(fā)送新請(qǐng)求。
（2）數(shù)據(jù)同步
無論是主備還是主從都牽扯到數(shù)據(jù)同步的問題，這也分2種情況：
同步方式：當(dāng)主機(jī)收到客戶端寫操作后，以同步方式把數(shù)據(jù)同步到從機(jī)上，當(dāng)從機(jī)也成功寫入后，主機(jī)才返回給客戶端成功，也稱數(shù)據(jù)強(qiáng)一致性。 很顯然這種方式性能會(huì)降低不少，當(dāng)從機(jī)很多時(shí)，可以不用每臺(tái)都同步，主機(jī)同步某一臺(tái)從機(jī)后，從機(jī)再把數(shù)據(jù)分發(fā)同步到其他從機(jī)上，這樣提高主機(jī)性能分擔(dān)同步壓力。 在redis中是支持這楊配置的，一臺(tái)master，一臺(tái)slave，同時(shí)這臺(tái)salve又作為其他slave的master。
異步方式：主機(jī)接收到寫操作后，直接返回成功，然后在后臺(tái)用異步方式把數(shù)據(jù)同步到從機(jī)上。 這種同步性能比較好，但無法保證數(shù)據(jù)的完整性，比如在異步同步過程中主機(jī)突然宕機(jī)了，也稱這種方式為數(shù)據(jù)弱一致性。
Redis主從同步采用的是異步方式，因此會(huì)有少量丟數(shù)據(jù)的危險(xiǎn)。還有種弱一致性的特例叫最終一致性，這塊詳細(xì)內(nèi)容可參見CAP原理及一致性模型。
（3）方案選擇
keepalived方案配置簡單、人力成本小，在數(shù)據(jù)量少、壓力小的情況下推薦使用。 如果數(shù)據(jù)量比較大，不希望過多浪費(fèi)機(jī)器，還希望在宕機(jī)后，做一些自定義的措施，比如報(bào)警、記日志、數(shù)據(jù)遷移等操作，推薦使用主從方式，因?yàn)楹椭鲝拇钆涞囊话氵€有個(gè)管理監(jiān)控中心。
宕機(jī)通知這塊，可以集成到客戶端組件上，也可單獨(dú)抽離出來。 Redis官方Sentinel支持故障自動(dòng)轉(zhuǎn)移、通知等，詳情見低成本高可用方案設(shè)計(jì)(四)。
邏輯圖：
二，分布式
分布式(distributed), 是當(dāng)業(yè)務(wù)量、數(shù)據(jù)量增加時(shí)，可以通過任意增加減少服務(wù)器數(shù)量來解決問題。
集群時(shí)代
至少部署兩臺(tái)Redis服務(wù)器構(gòu)成一個(gè)小的集群，主要有2個(gè)目的：
高可用性：在主機(jī)掛掉后，自動(dòng)故障轉(zhuǎn)移，使前端服務(wù)對(duì)用戶無影響。
讀寫分離：將主機(jī)讀壓力分流到從機(jī)上。
可在客戶端組件上實(shí)現(xiàn)負(fù)載均衡，根據(jù)不同服務(wù)器的運(yùn)行情況，分擔(dān)不同比例的讀請(qǐng)求壓力。
邏輯圖：
三，分布式集群時(shí)代
當(dāng)緩存數(shù)據(jù)量不斷增加時(shí)，單機(jī)內(nèi)存不夠使用，需要把數(shù)據(jù)切分不同部分，分布到多臺(tái)服務(wù)器上。
可在客戶端對(duì)數(shù)據(jù)進(jìn)行分片，數(shù)據(jù)分片算法詳見C#一致性Hash詳解、C#之虛擬桶分片。
邏輯圖：
大規(guī)模分布式集群時(shí)代
當(dāng)數(shù)據(jù)量持續(xù)增加時(shí)，應(yīng)用可根據(jù)不同場景下的業(yè)務(wù)申請(qǐng)對(duì)應(yīng)的分布式集群。 這塊最關(guān)鍵的是緩存治理這塊，其中最重要的部分是加入了代理服務(wù)。 應(yīng)用通過代理訪問真實(shí)的Redis服務(wù)器進(jìn)行讀寫，這樣做的好處是：
避免越來越多的客戶端直接訪問Redis服務(wù)器難以管理，而造成風(fēng)險(xiǎn)。
在代理這一層可以做對(duì)應(yīng)的安全措施，比如限流、授權(quán)、分片。
避免客戶端越來越多的邏輯代碼，不但臃腫升級(jí)還比較麻煩。
代理這層無狀態(tài)的，可任意擴(kuò)展節(jié)點(diǎn)，對(duì)于客戶端來說，訪問代理跟訪問單機(jī)Redis一樣。
目前樓主公司使用的是客戶端組件和代理兩種方案并存，因?yàn)橥ㄟ^代理會(huì)影響一定的性能。 代理這塊對(duì)應(yīng)的方案實(shí)現(xiàn)有Twitter的Twemproxy和豌豆莢的codis。
邏輯圖：
四，總結(jié)
分布式緩存再向后是云服務(wù)緩存，對(duì)使用端完全屏蔽細(xì)節(jié)，各應(yīng)用自行申請(qǐng)大小、流量方案即可，如淘寶OCS云服務(wù)緩存。
分布式緩存對(duì)應(yīng)需要的實(shí)現(xiàn)組件有：
一個(gè)緩存監(jiān)控、遷移、管理中心。
一個(gè)自定義的客戶端組件，上圖中的SmartClient。
一個(gè)無狀態(tài)的代理服務(wù)。
N臺(tái)服務(wù)器。
