1弹谁、Redis的的用途和場(chǎng)景
高性能與高并發(fā)
各種業(yè)務(wù)場(chǎng)景如何利用Redis秀操作，可以參考《Redis數(shù)據(jù)說(shuō)明》
2句喜、使用不當(dāng)?shù)暮蠊?/h3>
- 緩存與數(shù)據(jù)庫(kù)的數(shù)據(jù)一致性
- 緩存雪崩
- 緩存穿透
- 緩存并發(fā)競(jìng)爭(zhēng)
3预愤、redis為啥高性能
- 絕大部分請(qǐng)求是純粹的內(nèi)存操作（非常快速）咳胃，數(shù)據(jù)存在內(nèi)存中植康，類似于HashMap，HashMap的優(yōu)勢(shì)就是查找和操作的時(shí)間復(fù)雜度都是O(1)展懈；
- 數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單销睁，對(duì)數(shù)據(jù)操作也簡(jiǎn)單
- 采用單線程，避免了不必要的上下文切換和競(jìng)爭(zhēng)條件存崖，也不存在多進(jìn)程或者多線程導(dǎo)致的切換而消耗 CPU冻记，不用去考慮各種鎖的問(wèn)題，不存在加鎖釋放鎖操作来惧，沒(méi)有因?yàn)榭赡艹霈F(xiàn)死鎖而導(dǎo)致的性能消耗冗栗；
- 非阻塞IO - IO多路復(fù)用，“多路”指的是多個(gè)網(wǎng)絡(luò)連接供搀，“復(fù)用”指的是復(fù)用同一個(gè)線程隅居。
https://www.cnblogs.com/hujingnb/p/12439661.html
https://www.cnblogs.com/hujingnb/p/12439661.html
4、redis的數(shù)據(jù)類型
string（字符串）葛虐，hash（哈希）胎源，list（列表），set（集合）及zset(sorted set：有序集合)屿脐。
5涕蚤、redis的過(guò)期策略
兩種策略組合，保證過(guò)期的key一定能刪掉摄悯。
- 定期刪除赞季，每隔100ms隨機(jī)抽取設(shè)置過(guò)期時(shí)間的key，檢查是否過(guò)期奢驯。（避免過(guò)多數(shù)據(jù)的輪詢耗時(shí)）
- 惰性刪除申钩，key查詢時(shí)再判斷是否過(guò)期，過(guò)期了再進(jìn)行確認(rèn)瘪阁，過(guò)期則刪除撒遣。
LRU(最近使用最少的)內(nèi)存淘汰策略邮偎，進(jìn)行過(guò)期key（最近最少使用）的內(nèi)存釋放∫謇瑁可以用LinkedHashMap自己手寫一個(gè).
6.redis如何支持高并發(fā)
單機(jī)redis的并發(fā)在幾萬(wàn)(高性能的主機(jī)可以支撐到10w+)禾进，一般會(huì)采用主從架構(gòu)+讀寫分離，一般是一主多從廉涕，主負(fù)責(zé)寫并將數(shù)據(jù)同步復(fù)制到其他的slave節(jié)點(diǎn)上去泻云，從節(jié)點(diǎn)負(fù)責(zé)讀，所有的讀請(qǐng)求都要走從節(jié)點(diǎn)狐蜕，這樣可以支撐起一個(gè)水平擴(kuò)展的讀高并發(fā)架構(gòu)宠纯。
7、redis replication主從復(fù)制的核心原理
當(dāng)啟動(dòng)一個(gè)salve節(jié)點(diǎn)時(shí)层释，它首先會(huì)發(fā)送一個(gè)psync的命令給master節(jié)點(diǎn)婆瓜，如果是第一次連接，就會(huì)觸發(fā)全量同步贡羔，master會(huì)異步的生成一份rdb快照文件（無(wú)磁盤化復(fù)制廉白，內(nèi)存中創(chuàng)建不會(huì)落盤），同時(shí)還會(huì)將這段時(shí)間從客戶端收到的所有寫命令緩存在內(nèi)存中乖寒。rdb生辰后猴蹂，發(fā)送給slave節(jié)點(diǎn)，slave寫入磁盤再加載到內(nèi)存中宵统，然后master會(huì)講內(nèi)存中緩存的寫命令也同步給slave晕讲，slave也會(huì)去同步這部分增量數(shù)據(jù)覆获。
master和slave都會(huì)維護(hù)一個(gè)offset马澈，不僅僅用于全量復(fù)制，讓master和slave都知道相互之間一個(gè)數(shù)據(jù)一致性情況弄息。
8痊班、斷點(diǎn)續(xù)傳
全量主從復(fù)制支持?jǐn)帱c(diǎn)續(xù)傳，master節(jié)點(diǎn)在內(nèi)存中維護(hù)了backlog摹量，記錄了一個(gè)同步的偏移量涤伐，如果斷線重連以后，會(huì)從backlog中記錄的偏移量位置開(kāi)始進(jìn)行同步缨称，如果沒(méi)有找到offset就會(huì)觸發(fā)全量同步凝果。
9、redis的高可用機(jī)制
redis的高可用是通過(guò)哨兵機(jī)制來(lái)保障的睦尽。類似zk器净，可以實(shí)現(xiàn)集群監(jiān)控、消息通知当凡、故障轉(zhuǎn)移和配置中心的作用山害。哨兵本身也是分布式的：
- 故障轉(zhuǎn)移纠俭，判斷一個(gè)master掛了，需要多數(shù)哨兵同意才行浪慌，需要重新選舉冤荆。
- 哨兵本身也是集群模式，部分節(jié)點(diǎn)掛了权纤，還是能工作钓简，同時(shí)為了方便選舉哨兵的節(jié)點(diǎn)數(shù)最好設(shè)置成奇數(shù)個(gè)。
a.社區(qū)版本推出的原生高可用解決方案
當(dāng)故障轉(zhuǎn)移的工作流程就是汹想，當(dāng)Master宕機(jī)的時(shí)候涌庭，Sentinel會(huì)選舉出新的Master，并根據(jù)Sentinel中client-reconfig-script腳本配置的內(nèi)容欧宜，去動(dòng)態(tài)修改VIP(虛擬IP)坐榆，將VIP(虛擬IP)指向新的Master。我們的客戶端就連向指定的VIP即可冗茸！
缺陷:
(1)主從切換的過(guò)程中會(huì)丟數(shù)據(jù)
(2)Redis只能單點(diǎn)寫席镀，不能水平擴(kuò)容
b.開(kāi)源Proxy+Replication+Sentinel
前端使用Twemproxy+KeepAlived做代理，將其后端的多臺(tái)Redis實(shí)例分片進(jìn)行統(tǒng)一管理與分配
每一個(gè)分片節(jié)點(diǎn)的Slave都是Master的副本且只讀夏漱；Sentinel持續(xù)不斷的監(jiān)控每個(gè)分片節(jié)點(diǎn)的Master豪诲，當(dāng)Master出現(xiàn)故障且不可用狀態(tài)時(shí)，Sentinel會(huì)通知/啟動(dòng)自動(dòng)故障轉(zhuǎn)移等動(dòng)作挂绰；Sentinel 可以在發(fā)生故障轉(zhuǎn)移動(dòng)作后觸發(fā)相應(yīng)腳本（通過(guò) client-reconfig-script 參數(shù)配置 ）屎篱，腳本獲取到最新的Master來(lái)修改Twemproxy配置。
缺陷:
(1)部署結(jié)構(gòu)超級(jí)復(fù)雜
(2)可擴(kuò)展性差葵蒂，進(jìn)行擴(kuò)縮容需要手動(dòng)干預(yù)
(3)運(yùn)維不方便
10交播、redis哨兵的選舉算法
判斷master失敗的兩種狀態(tài)：
- sdown，主觀宕機(jī)践付，一個(gè)哨兵ping不同一個(gè)master秦士，超過(guò)一定時(shí)刻就主觀認(rèn)為sdown了。
- odown永高，客觀宕機(jī)隧土，如果有quorum數(shù)量的哨兵都認(rèn)為master宕機(jī)了，就客觀認(rèn)為master宕機(jī)了命爬。
如果一個(gè)master被認(rèn)為odown曹傀，且majority哨兵都允許了準(zhǔn)備切換，選舉一個(gè)slave為一個(gè)master饲宛。
- slave priority越低皆愉，選舉為master的優(yōu)先級(jí)越高
- slave priority相同，replica offset越靠后，優(yōu)先級(jí)越高（從master同步數(shù)據(jù)越多）
- 上面都相同亥啦，就選擇一個(gè)run id較小的slave炭剪。
source: 史上最全 Redis 高可用解決方案總結(jié)
11、redis掛掉以后的數(shù)據(jù)恢復(fù)（持久化機(jī)制）
redis持久化主要功能就是為了保證災(zāi)難恢復(fù)翔脱，數(shù)據(jù)恢復(fù)奴拦。可以歸類于高可用届吁。關(guān)于持久化的AOF和RDB错妖，二者區(qū)別介紹如下：
- RDB持久化是通過(guò)將某個(gè)時(shí)間點(diǎn)Redis服務(wù)器存儲(chǔ)的數(shù)據(jù)保存到RDB文件中來(lái)實(shí)現(xiàn)持久化的。AOF持久化是通過(guò)將Redis服務(wù)器執(zhí)行的所有寫命令保存到AOF文件中來(lái)實(shí)現(xiàn)持久化的疚沐。
- RDB持久化記錄的是結(jié)果暂氯，AOF持久化記錄的是過(guò)程，所以AOF持久化生成的AOF文件會(huì)有體積越來(lái)越大的問(wèn)題亮蛔，Redis提供了AOF重寫功能來(lái)減小AOF文件體積痴施。
- AOF持久化的安全性要比RDB持久化的安全性高，即如果發(fā)生機(jī)器故障究流，AOF持久化要比RDB持久化丟失的數(shù)據(jù)要少辣吃。
- 如果Redis服務(wù)器開(kāi)啟了AOF持久化功能（默認(rèn)是關(guān)閉的），Redis服務(wù)器在啟動(dòng)時(shí)會(huì)使用AOF文件來(lái)還原數(shù)據(jù)芬探，如果Redis服務(wù)器沒(méi)有開(kāi)啟AOF持久化功能神得，Redis服務(wù)器在啟動(dòng)時(shí)會(huì)使用RDB文件來(lái)還原數(shù)據(jù)，所以AOF文件的優(yōu)先級(jí)比RDB文件的優(yōu)先級(jí)高偷仿。
12哩簿、RDB中save和Bgsave的區(qū)別？
Redis提供了2個(gè)命令來(lái)創(chuàng)建RDB文件酝静，一個(gè)是SAVE节榜，另一個(gè)是BGSAVE。
- SAVE命令會(huì)阻塞Redis服務(wù)器進(jìn)程形入，直到RDB文件創(chuàng)建完畢為止全跨，在服務(wù)器進(jìn)程阻塞期間缝左，服務(wù)器不能處理任何命令請(qǐng)求亿遂。
- BGSAVE命令會(huì)派生出一個(gè)子進(jìn)程，然后由子進(jìn)程負(fù)責(zé)創(chuàng)建RDB文件渺杉，服務(wù)器進(jìn)程（父進(jìn)程）繼續(xù)處理命令請(qǐng)求
BGSAVE命令可以在不阻塞服務(wù)器進(jìn)程的情況下執(zhí)行蛇数，所以推薦使用BGSAVE命令。
13是越、RDB和AOF如何選擇耳舅？
可以綜合使用，用AOF來(lái)保證數(shù)據(jù)不丟失，作為恢復(fù)數(shù)據(jù)的第一選擇浦徊；用RDB來(lái)做冷備馏予，在AOF或者磁盤損壞不可用的情況下，還有RDB作為快速恢復(fù)的手段盔性。
14冕香、Redis的架構(gòu)選擇
- 如果數(shù)據(jù)量很少蛹尝，主要是承載高并發(fā)高性能的場(chǎng)景，比如你的緩存一般就幾個(gè)G悉尾，單機(jī)足夠了
- 主從+replication突那，數(shù)據(jù)量一般，滿足高并發(fā)构眯，一個(gè)mater愕难，多個(gè)slave，要幾個(gè)slave跟你的要求的讀吞吐量有關(guān)系惫霸，然后自己搭建一個(gè)sentinal集群务漩，去保證redis主從架構(gòu)的高可用性，就可以了
- redis cluster它褪，主要是針對(duì)海量數(shù)據(jù)+高并發(fā)+高可用的場(chǎng)景饵骨，海量數(shù)據(jù)，如果你的數(shù)據(jù)量很大茫打，那么建議就用redis cluster
15居触、Redis Cluster
客戶端與Redis節(jié)點(diǎn)直連,不需要中間Proxy層，直接連接任意一個(gè)Master節(jié)點(diǎn)老赤；根據(jù)公式HASH_SLOT=CRC16(key) mod 16384轮洋，計(jì)算出映射到哪個(gè)分片上，然后Redis會(huì)去相應(yīng)的節(jié)點(diǎn)進(jìn)行操作
具有如下優(yōu)點(diǎn):
(1)無(wú)需Sentinel哨兵監(jiān)控抬旺，如果Master掛了弊予，Redis Cluster內(nèi)部自動(dòng)將Slave切換Master
(2)可以進(jìn)行水平擴(kuò)容
(3)支持自動(dòng)化遷移，當(dāng)出現(xiàn)某個(gè)Slave宕機(jī)了开财，那么就只有Master了汉柒，這時(shí)候的高可用性就無(wú)法很好的保證了，萬(wàn)一Master也宕機(jī)了责鳍，咋辦呢碾褂？ 針對(duì)這種情況，如果說(shuō)其他Master有多余的Slave 历葛，集群自動(dòng)把多余的Slave遷移到?jīng)]有Slave的Master 中正塌。
缺點(diǎn):
(1)批量操作是個(gè)坑(mget)
(2)資源隔離性較差，容易出現(xiàn)相互影響的情況。
source: 那些年用過(guò)的Redis集群架構(gòu)（含面試解析）
16乓诽、Redis cluster的高可用性
整個(gè)流程跟哨兵相比帜羊，非常類似，所以說(shuō)鸠天，redis cluster功能強(qiáng)大逮壁，直接集成了replication和sentinal的功能。不過(guò)在通信協(xié)議上整個(gè)采用了gossip協(xié)議粮宛，跟集中式的哨兵協(xié)議不同窥淆，不是將集群元數(shù)據(jù)（節(jié)點(diǎn)信息，故障巍杈，等等）集中存儲(chǔ)在某個(gè)節(jié)點(diǎn)上忧饭，而是互相之間不斷通信，保持整個(gè)集群所有節(jié)點(diǎn)的數(shù)據(jù)是完整的筷畦。其他在判斷節(jié)點(diǎn)是否當(dāng)季词裤、節(jié)點(diǎn)過(guò)濾和選舉上的思路都是少數(shù)服從多少的思路，基本一致鳖宾。
集中式：好處在于吼砂，元數(shù)據(jù)的更新和讀取，時(shí)效性非常好鼎文，一旦元數(shù)據(jù)出現(xiàn)了變更渔肩，立即就更新到集中式的存儲(chǔ)中，其他節(jié)點(diǎn)讀取的時(shí)候立即就可以感知到; 不好在于拇惋，所有的元數(shù)據(jù)的跟新壓力全部集中在一個(gè)地方周偎，可能會(huì)導(dǎo)致元數(shù)據(jù)的節(jié)點(diǎn)有壓力。
gossip：好處在于撑帖，元數(shù)據(jù)的更新比較分散蓉坎，不是集中在一個(gè)地方，更新請(qǐng)求會(huì)陸陸續(xù)續(xù)胡嘿，打到所有節(jié)點(diǎn)上去更新蛉艾，有一定的延時(shí)，降低了壓力; 缺點(diǎn)衷敌，元數(shù)據(jù)更新有延時(shí)勿侯，可能導(dǎo)致集群的一些操作會(huì)有一些滯后。
17逢享、數(shù)據(jù)分區(qū)的選擇
a.哈希取余分區(qū)
哈希取余分區(qū)思路非常簡(jiǎn)單：計(jì)算 key 的 hash 值罐监，然后對(duì)節(jié)點(diǎn)數(shù)量進(jìn)行取余，從而決定數(shù)據(jù)映射到哪個(gè)節(jié)點(diǎn)上瞒爬。
該方案最大的問(wèn)題是，當(dāng)新增或刪減節(jié)點(diǎn)時(shí)，節(jié)點(diǎn)數(shù)量發(fā)生變化侧但，系統(tǒng)中所有的數(shù)據(jù)都需要重新計(jì)算映射關(guān)系矢空，引發(fā)大規(guī)模數(shù)據(jù)遷移。
b.一致性哈希分區(qū)
一致性哈希算法將整個(gè)哈希值空間組織成一個(gè)虛擬的圓環(huán)禀横，如下圖所示屁药，范圍為 0-2^32-1。對(duì)于每個(gè)數(shù)據(jù)柏锄，根據(jù) key 計(jì)算 hash 值酿箭，確定數(shù)據(jù)在環(huán)上的位置，然后從此位置沿環(huán)順時(shí)針行走趾娃，找到的第一臺(tái)服務(wù)器就是其應(yīng)該映射到的服務(wù)器缭嫡。
與哈希取余分區(qū)相比，一致性哈希分區(qū)將增減節(jié)點(diǎn)的影響限制在相鄰節(jié)點(diǎn)抬闷。一致性哈希分區(qū)的主要問(wèn)題在于妇蛀，當(dāng)節(jié)點(diǎn)數(shù)量較少時(shí)，增加或刪減節(jié)點(diǎn)笤成，對(duì)單個(gè)節(jié)點(diǎn)的影響可能很大评架，造成數(shù)據(jù)的嚴(yán)重不平衡；同時(shí)也需要保證節(jié)點(diǎn)能夠均勻分布在哈希環(huán)炕泳，使得緩存數(shù)據(jù)能夠均勻分布纵诞。
c.帶虛擬節(jié)點(diǎn)的一致性哈希分區(qū)(哈希槽)
該方案在一致性哈希分區(qū)的基礎(chǔ)上，引入了虛擬節(jié)點(diǎn)的概念培遵。Redis 集群使用的便是該方案挣磨，其中的虛擬節(jié)點(diǎn)稱為槽（slot）。槽是介于數(shù)據(jù)和實(shí)際節(jié)點(diǎn)之間的虛擬概念荤懂；每個(gè)實(shí)際節(jié)點(diǎn)包含一定數(shù)量的槽茁裙，每個(gè)槽包含哈希值在一定范圍內(nèi)的數(shù)據(jù)。引入槽以后节仿，數(shù)據(jù)的映射關(guān)系由數(shù)據(jù) hash->實(shí)際節(jié)點(diǎn)晤锥，變成了數(shù)據(jù) hash->槽->實(shí)際節(jié)點(diǎn)。在使用了槽的一致性哈希分區(qū)中廊宪，槽是數(shù)據(jù)管理和遷移的基本單位矾瘾。槽解耦了數(shù)據(jù)和實(shí)際節(jié)點(diǎn)之間的關(guān)系，增加或刪除節(jié)點(diǎn)對(duì)系統(tǒng)的影響很小箭启。槽的數(shù)量一般遠(yuǎn)小于 2^32壕翩，遠(yuǎn)大于實(shí)際節(jié)點(diǎn)的數(shù)量；在 Redis 集群中傅寡，槽的數(shù)量為 16384放妈。
Redis 集群將數(shù)據(jù)映射到實(shí)際節(jié)點(diǎn)的過(guò)程：
- Redis 對(duì)數(shù)據(jù)的特征值（一般是key）計(jì)算哈希值北救，使用的算法是 CRC16。
- 根據(jù)哈希值芜抒，計(jì)算數(shù)據(jù)屬于哪個(gè)槽珍策。
- 根據(jù)槽與節(jié)點(diǎn)的映射關(guān)系，計(jì)算數(shù)據(jù)屬于哪個(gè)節(jié)點(diǎn)宅倒。
18攘宙、緩存雪崩
故障原因：redis掛了
事前：redis高可用，主從+哨兵拐迁，redis cluster蹭劈，避免全盤崩潰
事中：本地cache緩存 + hystrix限流&降級(jí)，避免MySQL被打死
事后：redis持久化线召，快速恢復(fù)緩存數(shù)據(jù)
故障原因2：緩存時(shí)采用了相同的過(guò)期時(shí)間铺韧，導(dǎo)致緩存在某一時(shí)刻同時(shí)失效
將緩存失效時(shí)間分散開(kāi)，比如我們可以在原有的失效時(shí)間基礎(chǔ)上增加一個(gè)隨機(jī)值灶搜，比如1-5分鐘隨機(jī)祟蚀，這樣每一個(gè)緩存的過(guò)期時(shí)間的重復(fù)率就會(huì)降低，就很難引發(fā)集體失效的事件割卖。
19前酿、緩存穿透
緩存穿透是指緩存和數(shù)據(jù)庫(kù)中都沒(méi)有的數(shù)據(jù)，而用戶不斷發(fā)起請(qǐng)求鹏溯，如發(fā)起為id為“-1”的數(shù)據(jù)或id為特別大不存在的數(shù)據(jù)罢维。這時(shí)的用戶很可能是攻擊者，攻擊會(huì)導(dǎo)致數(shù)據(jù)庫(kù)壓力過(guò)大丙挽。解決辦法有兩個(gè)：
- 查詢數(shù)據(jù)庫(kù)不存在肺孵，則在redis中存一份Null值，避免訪問(wèn)Mysql
- 采用布隆過(guò)濾器颜阐，將List數(shù)據(jù)裝載入布隆過(guò)濾器中平窘，訪問(wèn)經(jīng)過(guò)布隆過(guò)濾器，存在才可以往db中查詢凳怨。于是在內(nèi)存中就可以攔截惡意請(qǐng)求瑰艘。
20、數(shù)據(jù)庫(kù)與緩存一致性
Cache Aside Pattern肤舞，基本都采用如下的緩存模式：
- 讀的時(shí)候紫新，先讀緩存，緩存沒(méi)有的話李剖，那么就讀數(shù)據(jù)庫(kù)芒率，然后取出數(shù)據(jù)后放入緩存，同時(shí)返回響應(yīng)
- 更新的時(shí)候篙顺，先刪除緩存偶芍，然后再更新數(shù)據(jù)庫(kù)
更新操作中為啥是直接刪除而不是更新充择？
更新緩存的代價(jià)是很高的，刪除緩存腋寨，而不是更新緩存聪铺，就是一個(gè)lazy計(jì)算的思想化焕，不要每次都重新做復(fù)雜的計(jì)算萄窜，不管它會(huì)不會(huì)用到，而是讓它到需要被使用的時(shí)候再重新計(jì)算撒桨。
21查刻、高并發(fā)情況下如何保證一致性
還是應(yīng)用上面的緩存模式來(lái)看：數(shù)據(jù)發(fā)生了變更，先刪除了緩存凤类，然后要去修改數(shù)據(jù)庫(kù)穗泵，此時(shí)還沒(méi)修改
一個(gè)請(qǐng)求過(guò)來(lái)，去讀緩存谜疤，發(fā)現(xiàn)緩存空了佃延，去查詢數(shù)據(jù)庫(kù)，查到了修改前的舊數(shù)據(jù)夷磕，放到了緩存中履肃，數(shù)據(jù)變更的程序完成了數(shù)據(jù)庫(kù)的修改，此時(shí)就會(huì)出現(xiàn)緩存和數(shù)據(jù)庫(kù)中數(shù)據(jù)不一致的情況坐桩！
數(shù)據(jù)庫(kù)與緩存更新與讀取操作進(jìn)行異步串行化
更新數(shù)據(jù)的時(shí)候尺棋，根據(jù)數(shù)據(jù)的唯一標(biāo)識(shí)，將操作路由之后绵跷，發(fā)送到一個(gè)jvm內(nèi)部的隊(duì)列中膘螟，讀取數(shù)據(jù)的時(shí)候，如果發(fā)現(xiàn)數(shù)據(jù)不在緩存中碾局，那么將重新讀取數(shù)據(jù)+更新緩存的操作荆残，根據(jù)唯一標(biāo)識(shí)路由之后，也發(fā)送同一個(gè)jvm內(nèi)部的隊(duì)列中净当，一個(gè)隊(duì)列對(duì)應(yīng)一個(gè)工作線程内斯，每個(gè)工作線程串行拿到對(duì)應(yīng)的操作，然后一條一條的執(zhí)行
這樣的話蚯瞧，一個(gè)數(shù)據(jù)變更的操作嘿期，先執(zhí)行，刪除緩存埋合，然后再去更新數(shù)據(jù)庫(kù)备徐，但是還沒(méi)完成更新。此時(shí)如果一個(gè)讀請(qǐng)求過(guò)來(lái)甚颂，讀到了空的緩存蜜猾，那么可以先將緩存更新的請(qǐng)求發(fā)送到隊(duì)列中秀菱，此時(shí)會(huì)在隊(duì)列中積壓，然后同步等待緩存更新完成蹭睡。
22衍菱、生產(chǎn)環(huán)境中的redis是怎么部署的？
redis-cluster模式肩豁，企業(yè)數(shù)據(jù)架構(gòu)組維護(hù)脊串，10臺(tái)機(jī)器，5主+5從清钥，每個(gè)主實(shí)例掛了一個(gè)從實(shí)例琼锋，5個(gè)節(jié)點(diǎn)對(duì)外提供讀寫服務(wù)，單節(jié)點(diǎn)qps峰值可能可以達(dá)到每秒2萬(wàn)祟昭，5臺(tái)機(jī)器并發(fā)峰值為10萬(wàn)讀寫請(qǐng)求/s缕坎。
機(jī)器是什么配置？（4c8g或者8c16g）篡悟，但是分配給redis進(jìn)程的是內(nèi)存谜叹，一般線上生產(chǎn)環(huán)境，redis的內(nèi)存盡量不要超過(guò)10g搬葬，超過(guò)10g可能會(huì)有問(wèn)題荷腊。給分配了一半4g。
高可用策略：因?yàn)槊總€(gè)主實(shí)例都掛了一個(gè)從實(shí)例踩萎，所以是高可用的停局，任何一個(gè)主實(shí)例宕機(jī)，都會(huì)自動(dòng)故障遷移香府，redis從實(shí)例會(huì)自動(dòng)變成主實(shí)例繼續(xù)提供讀寫服務(wù).
往內(nèi)存里寫的是什么數(shù)據(jù)日缨？每條數(shù)據(jù)的大小是多少恩急？用戶登陸忽洛，每條數(shù)據(jù)是2k涣楷。1000個(gè)用戶2m，50萬(wàn)條數(shù)據(jù)是1g勿璃。僅僅不到總內(nèi)存的1/4擒抛。
目前高峰期每秒就是3000左右的請(qǐng)求量。
