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ù)悴能，操作都是原子性，所謂的原子性就是對數(shù)據(jù)的更改要么全部執(zhí)行雳灾，要么全部不執(zhí)行

(4) 豐富的特性：可用于緩存漠酿，消息，按key設(shè)置過期時(shí)間谎亩，過期后將會自動刪除

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ù)比較重要夭拌，某個Slave開啟AOF備份數(shù)據(jù)魔熏，策略設(shè)置為每秒同步一次

(3) 為了主從復(fù)制的速度和連接的穩(wěn)定性，Master和Slave最好在同一個局域網(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對Master的替換桶现。如果Master掛了躲雅，可以立刻啟用Slave1做Master，其他不變巩那。

4吏夯、MySQL 里有2000w數(shù)據(jù)，redis中只存20w的數(shù)據(jù)即横，如何保證redis中的數(shù)據(jù)都是熱點(diǎn)數(shù)據(jù)

相關(guān)知識：redis 內(nèi)存數(shù)據(jù)集大小上升到一定大小的時(shí)候，就會施行數(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)战授、存儲方式

Memecache把數(shù)據(jù)全部存在內(nèi)存之中页藻，斷電后會掛掉，數(shù)據(jù)不能超過內(nèi)存大小植兰。

Redis有部份存在硬盤上份帐，這樣能保證數(shù)據(jù)的持久性。

2)楣导、數(shù)據(jù)支持類型

Memcache對數(shù)據(jù)類型支持相對簡單废境。

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ù)的話毡咏，會浪費(fèi)一定的時(shí)間去移動和請求驮宴。

4）、value大小

redis最大可以達(dá)到1GB呕缭，而memcache只有1MB

6堵泽、redis 最適合的場景

Redis最適合所有數(shù)據(jù)in-momory的場景修己，雖然Redis也提供持久化功能，但實(shí)際更多的是一個disk-backed的功能迎罗，跟傳統(tǒng)意義上的持久化有比較大的差別睬愤，那么可能大家就會有疑問，似乎Redis更像一個加強(qiáng)版的Memcached佳谦，那么何時(shí)使用Memcached,何時(shí)使用Redis呢?

如果簡單地比較Redis與Memcached的區(qū)別戴涝，大多數(shù)都會得到以下觀點(diǎn)：

1. Redis不僅僅支持簡單的k/v類型的數(shù)據(jù)，同時(shí)還提供list钻蔑，set啥刻，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲咪笑。

2. Redis支持?jǐn)?shù)據(jù)的備份可帽，即master-slave模式的數(shù)據(jù)備份。

3. Redis支持?jǐn)?shù)據(jù)的持久化窗怒，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤中映跟，重啟的時(shí)候可以再次加載進(jìn)行使用。

（1）會話緩存（Session Cache）

最常用的一種使用Redis的情景是會話緩存（session cache）扬虚。用Redis緩存會話比其他存儲（如Memcached）的優(yōu)勢在于：Redis提供持久化努隙。當(dāng)維護(hù)一個不是嚴(yán)格要求一致性的緩存時(shí)，如果用戶的購物車信息全部丟失辜昵，大部分人都會不高興的荸镊，現(xiàn)在，他們還會這樣嗎堪置？

幸運(yùn)的是躬存，隨著 Redis 這些年的改進(jìn)，很容易找到怎么恰當(dāng)?shù)氖褂肦edis來緩存會話的文檔舀锨。甚至廣為人知的商業(yè)平臺Magento也提供Redis的插件岭洲。

（2）全頁緩存（FPC）

除基本的會話token之外，Redis還提供很簡便的FPC平臺坎匿《苁＃回到一致性問題，即使重啟了Redis實(shí)例碑诉，因?yàn)橛写疟P的持久化彪腔，用戶也不會看到頁面加載速度的下降，這是一個極大改進(jìn)进栽，類似PHP本地FPC德挣。

再次以Magento為例，Magento提供一個插件來使用Redis作為全頁緩存后端快毛。

此外格嗅，對WordPress的用戶來說番挺，Pantheon有一個非常好的插件 wp-redis，這個插件能幫助你以最快速度加載你曾瀏覽過的頁面屯掖。

（3）隊(duì)列

Reids在內(nèi)存存儲引擎領(lǐng)域的一大優(yōu)點(diǎn)是提供 list 和 set 操作玄柏，這使得Redis能作為一個很好的消息隊(duì)列平臺來使用。Redis作為隊(duì)列使用的操作贴铜，就類似于本地程序語言（如Python）對 list 的 push/pop 操作粪摘。

如果你快速的在Google中搜索“Redis queues”，你馬上就能找到大量的開源項(xiàng)目绍坝，這些項(xiàng)目的目的就是利用Redis創(chuàng)建非常好的后端工具徘意，以滿足各種隊(duì)列需求。例如轩褐，Celery有一個后臺就是使用Redis作為broker椎咧，你可以從這里去查看。

（4）排行榜/計(jì)數(shù)器

Redis在內(nèi)存中對數(shù)字進(jìn)行遞增或遞減的操作實(shí)現(xiàn)的非常好把介。集合（Set）和有序集合（Sorted Set）也使得我們在執(zhí)行這些操作的時(shí)候變的非常簡單勤讽，Redis只是正好提供了這兩種數(shù)據(jù)結(jié)構(gòu)。所以拗踢，我們要從排序集合中獲取到排名最靠前的10個用戶–我們稱之為“user_scores”脚牍，我們只需要像下面一樣執(zhí)行即可：

當(dāng)然，這是假定你是根據(jù)你用戶的分?jǐn)?shù)做遞增的排序巢墅。如果你想返回用戶及用戶的分?jǐn)?shù)莫矗，你需要這樣執(zhí)行：

ZRANGE user_scores 0 10 WITHSCORES

Agora Games就是一個很好的例子，用Ruby實(shí)現(xiàn)的砂缩，它的排行榜就是使用Redis來存儲數(shù)據(jù)的，你可以在這里看到三娩。

（5）發(fā)布/訂閱

最后（但肯定不是最不重要的）是Redis的發(fā)布/訂閱功能庵芭。發(fā)布/訂閱的使用場景確實(shí)非常多。我已看見人們在社交網(wǎng)絡(luò)連接中使用雀监，還可作為基于發(fā)布/訂閱的腳本觸發(fā)器双吆，甚至用Redis的發(fā)布/訂閱功能來建立聊天系統(tǒng)！（不会前，這是真的好乐，你可以去核實(shí)）。

Redis提供的所有特性中瓦宜，我感覺這個是喜歡的人最少的一個蔚万，雖然它為用戶提供如果此多功能。

高可用分布式集群

一临庇、高可用

高可用（High Availability）反璃，是當(dāng)一臺服務(wù)器停止服務(wù)后昵慌，對于業(yè)務(wù)及用戶毫無影響。 停止服務(wù)的原因可能由于網(wǎng)卡淮蜈、路由器斋攀、機(jī)房、CPU負(fù)載過高梧田、內(nèi)存溢出淳蔼、自然災(zāi)害等不可預(yù)期的原因?qū)е拢诤芏鄷r(shí)候也稱單點(diǎn)問題裁眯。

（1）解決單點(diǎn)問題主要有2種方式：

主備方式

這種通常是一臺主機(jī)鹉梨、一臺或多臺備機(jī)，在正常情況下主機(jī)對外提供服務(wù)未状，并把數(shù)據(jù)同步到備機(jī)俯画，當(dāng)主機(jī)宕機(jī)后，備機(jī)立刻開始服務(wù)司草。

Redis HA中使用比較多的是keepalived艰垂，它使主機(jī)備機(jī)對外提供同一個虛擬IP，客戶端通過虛擬IP進(jìn)行數(shù)據(jù)操作埋虹，正常期間主機(jī)一直對外提供服務(wù)猜憎，宕機(jī)后VIP自動漂移到備機(jī)上。

優(yōu)點(diǎn)是對客戶端毫無影響搔课，仍然通過VIP操作胰柑。

缺點(diǎn)也很明顯，在絕大多數(shù)時(shí)間內(nèi)備機(jī)是一直沒使用爬泥，被浪費(fèi)著的柬讨。

主從方式

這種采取一主多從的辦法，主從之間進(jìn)行數(shù)據(jù)同步袍啡。 當(dāng)Master宕機(jī)后踩官，通過選舉算法(Paxos、Raft)從slave中選舉出新Master繼續(xù)對外提供服務(wù)境输，主機(jī)恢復(fù)后以slave的身份重新加入蔗牡。

主從另一個目的是進(jìn)行讀寫分離，這是當(dāng)單機(jī)讀寫壓力過高的一種通用型解決方案嗅剖。 其主機(jī)的角色只提供寫操作或少量的讀辩越，把多余讀請求通過負(fù)載均衡算法分流到單個或多個slave服務(wù)器上。

缺點(diǎn)是主機(jī)宕機(jī)后信粮，Slave雖然被選舉成新Master了黔攒，但對外提供的IP服務(wù)地址卻發(fā)生變化了，意味著會影響到客戶端。 解決這種情況需要一些額外的工作亏钩，在當(dāng)主機(jī)地址發(fā)生變化后及時(shí)通知到客戶端莲绰，客戶端收到新地址后，使用新地址繼續(xù)發(fā)送新請求姑丑。

（2）數(shù)據(jù)同步

無論是主備還是主從都牽扯到數(shù)據(jù)同步的問題蛤签，這也分2種情況：

同步方式：當(dāng)主機(jī)收到客戶端寫操作后，以同步方式把數(shù)據(jù)同步到從機(jī)上栅哀，當(dāng)從機(jī)也成功寫入后震肮，主機(jī)才返回給客戶端成功，也稱數(shù)據(jù)強(qiáng)一致性留拾。 很顯然這種方式性能會降低不少戳晌，當(dāng)從機(jī)很多時(shí)，可以不用每臺都同步痴柔，主機(jī)同步某一臺從機(jī)后沦偎，從機(jī)再把數(shù)據(jù)分發(fā)同步到其他從機(jī)上，這樣提高主機(jī)性能分擔(dān)同步壓力咳蔚。 在redis中是支持這楊配置的豪嚎，一臺master，一臺slave谈火，同時(shí)這臺salve又作為其他slave的master侈询。

異步方式：主機(jī)接收到寫操作后，直接返回成功糯耍，然后在后臺用異步方式把數(shù)據(jù)同步到從機(jī)上扔字。 這種同步性能比較好，但無法保證數(shù)據(jù)的完整性温技，比如在異步同步過程中主機(jī)突然宕機(jī)了革为，也稱這種方式為數(shù)據(jù)弱一致性。

Redis主從同步采用的是異步方式舵鳞，因此會有少量丟數(shù)據(jù)的危險(xiǎn)篷角。還有種弱一致性的特例叫最終一致性，這塊詳細(xì)內(nèi)容可參見CAP原理及一致性模型系任。

（3）方案選擇

keepalived方案配置簡單、人力成本小虐块，在數(shù)據(jù)量少俩滥、壓力小的情況下推薦使用。 如果數(shù)據(jù)量比較大贺奠，不希望過多浪費(fèi)機(jī)器霜旧，還希望在宕機(jī)后，做一些自定義的措施，比如報(bào)警挂据、記日志以清、數(shù)據(jù)遷移等操作，推薦使用主從方式崎逃，因?yàn)楹椭鲝拇钆涞囊话氵€有個管理監(jiān)控中心掷倔。

宕機(jī)通知這塊，可以集成到客戶端組件上个绍，也可單獨(dú)抽離出來勒葱。 Redis官方Sentinel支持故障自動轉(zhuǎn)移、通知等巴柿，詳情見低成本高可用方案設(shè)計(jì)(四)凛虽。

邏輯圖：

image.png

二、分布式

分布式(distributed), 是當(dāng)業(yè)務(wù)量广恢、數(shù)據(jù)量增加時(shí)凯旋，可以通過任意增加減少服務(wù)器數(shù)量來解決問題。

集群時(shí)代

至少部署兩臺Redis服務(wù)器構(gòu)成一個小的集群钉迷，主要有2個目的：

高可用性：在主機(jī)掛掉后至非，自動故障轉(zhuǎn)移，使前端服務(wù)對用戶無影響篷牌。

讀寫分離：將主機(jī)讀壓力分流到從機(jī)上睡蟋。

可在客戶端組件上實(shí)現(xiàn)負(fù)載均衡，根據(jù)不同服務(wù)器的運(yùn)行情況枷颊，分擔(dān)不同比例的讀請求壓力戳杀。

邏輯圖：

image.png

三、分布式集群時(shí)代

當(dāng)緩存數(shù)據(jù)量不斷增加時(shí)夭苗，單機(jī)內(nèi)存不夠使用信卡，需要把數(shù)據(jù)切分不同部分，分布到多臺服務(wù)器上题造。

可在客戶端對數(shù)據(jù)進(jìn)行分片傍菇，數(shù)據(jù)分片算法詳見C#一致性Hash詳解、C#之虛擬桶分片界赔。

邏輯圖：

image.png

大規(guī)模分布式集群時(shí)代

當(dāng)數(shù)據(jù)量持續(xù)增加時(shí)丢习，應(yīng)用可根據(jù)不同場景下的業(yè)務(wù)申請對應(yīng)的分布式集群。 這塊最關(guān)鍵的是緩存治理這塊淮悼，其中最重要的部分是加入了代理服務(wù)咐低。 應(yīng)用通過代理訪問真實(shí)的Redis服務(wù)器進(jìn)行讀寫，這樣做的好處是：

避免越來越多的客戶端直接訪問Redis服務(wù)器難以管理袜腥，而造成風(fēng)險(xiǎn)见擦。

在代理這一層可以做對應(yīng)的安全措施，比如限流、授權(quán)鲤屡、分片损痰。

避免客戶端越來越多的邏輯代碼，不但臃腫升級還比較麻煩酒来。

代理這層無狀態(tài)的卢未，可任意擴(kuò)展節(jié)點(diǎn)，對于客戶端來說役首，訪問代理跟訪問單機(jī)Redis一樣尝丐。

目前樓主公司使用的是客戶端組件和代理兩種方案并存，因?yàn)橥ㄟ^代理會影響一定的性能衡奥。 代理這塊對應(yīng)的方案實(shí)現(xiàn)有Twitter的Twemproxy和豌豆莢的codis爹袁。

邏輯圖：

image.png

四、總結(jié)

分布式緩存再向后是云服務(wù)緩存矮固，對使用端完全屏蔽細(xì)節(jié)失息，各應(yīng)用自行申請大小、流量方案即可档址，如淘寶OCS云服務(wù)緩存盹兢。

分布式緩存對應(yīng)需要的實(shí)現(xiàn)組件有：

一個緩存監(jiān)控、遷移守伸、管理中心绎秒。

一個自定義的客戶端組件，上圖中的SmartClient尼摹。

一個無狀態(tài)的代理服務(wù)见芹。

N臺服務(wù)器。