一、高可用相關(guān) 1,、Redis 常用高可用架構(gòu)有哪些,? Redis 高可用架構(gòu)如下:
2,、Redis 高可用架構(gòu)優(yōu)劣對比,?—Redis Sentinel 集群 內(nèi)網(wǎng) DNS 自定義腳本 優(yōu)點(diǎn):
缺點(diǎn):
—Redis Sentinel 集群 VIP 自定義腳本 優(yōu)點(diǎn):
缺點(diǎn):
—封裝客戶端直連 Redis Sentinel 端口 優(yōu)點(diǎn):
缺點(diǎn):
—Redis Sentinel 集群 Keepalived/Haproxy 優(yōu)點(diǎn):
缺點(diǎn):
—Redis M/S Keepalived 優(yōu)點(diǎn):
缺點(diǎn):
(Redis Cluster,、Twemproxy、Codis 優(yōu)劣對比見下個問題) 3,、常見的 Redis 集群方案有哪些優(yōu)缺點(diǎn),?Twemproxy: 多個同構(gòu) Twemproxy(配置相同)同時工作,接受客戶端的請求,,根據(jù) hash 算法,,轉(zhuǎn)發(fā)給對應(yīng)的 Redis。 優(yōu)點(diǎn):
缺點(diǎn):
Codis:
優(yōu)點(diǎn):
缺點(diǎn):
Redis Cluster: P2P模式,,無中心化,。把 key 分成 16384 個 slot,,每個實(shí)例負(fù)責(zé)一部分 slot??蛻舳苏埱笕舨辉谶B接的實(shí)例,,該實(shí)例會轉(zhuǎn)發(fā)給對應(yīng)的實(shí)例。通過Gossip協(xié)議同步節(jié)點(diǎn)信息,。 優(yōu)點(diǎn):
缺點(diǎn):
二、Redis 通用 1,、Redis 相對 MySQL,、PostgreSQL 這些關(guān)系型數(shù)據(jù)庫,有什么優(yōu)缺點(diǎn),? 觀點(diǎn)一: Redis 主要是用來做緩存,,它有持久化,但也只是為了緩存的可靠而已,。優(yōu)點(diǎn)是數(shù)據(jù)全放內(nèi)存,,速度快。缺點(diǎn)就是,,數(shù)據(jù)大小不能超過內(nèi)存大小,。兩個用在不同業(yè)務(wù)場景,Redis 無法取代傳統(tǒng)關(guān)系型數(shù)據(jù)庫,。 觀點(diǎn)二: Redis 首先它是一種內(nèi)存數(shù)據(jù)庫,,最大的優(yōu)勢在于效率高。尤其在某些特定場合下,,例如熱點(diǎn)數(shù)據(jù)量非常大,,而數(shù)據(jù)從內(nèi)存和磁盤之間的換入換出代價比較高的情況下,Redis 就會體現(xiàn)它的價值,。 傳統(tǒng)關(guān)系型數(shù)據(jù)庫在于它對數(shù)據(jù)的一致性保障,,它的數(shù)據(jù)模型范式是遵循嚴(yán)格事務(wù)規(guī)則的結(jié)構(gòu)化數(shù)據(jù),由于其數(shù)據(jù)的高度抽象化,,它調(diào)度到內(nèi)存的數(shù)據(jù)一般場合下不會占用很大的內(nèi)存空間,。 總的來說,兩種數(shù)據(jù)庫各有各的優(yōu)點(diǎn)和缺點(diǎn),。不同的業(yè)務(wù)場合有特定的追求目標(biāo),,redis 首要的是效率,,適用的是一些單純二維結(jié)構(gòu)化數(shù)據(jù)無法表達(dá)的數(shù)據(jù)模型,而關(guān)系型數(shù)據(jù)庫處理的是可以用范式模型表達(dá)的二維數(shù)據(jù),,追求的是數(shù)據(jù)的高度一致性,。隨著 IT 的發(fā)展,每一類型的數(shù)據(jù)庫都會在其特定的場合內(nèi)發(fā)揮出無可比擬的優(yōu)勢,,最終的趨勢是大家趨于平衡,,沒有最好,只有最適合,。 觀點(diǎn)三: 記住一句話:任何數(shù)據(jù)庫都有自己的應(yīng)用場景,,應(yīng)該關(guān)注數(shù)據(jù)流、數(shù)據(jù)屬性,。 個人的經(jīng)驗(yàn)來說,,Redis 不可能取代 MySQL 或者 PG。 2,、Redis 有哪些應(yīng)用場景,?Redis 是一個高性能的緩存,一般應(yīng)用在 Session 緩存,、隊(duì)列,、排行榜、計數(shù)器,、最近最熱文章、最近最熱評論,、發(fā)布訂閱等,。 更多應(yīng)用場景,可以參考此處,。 可以這樣講,,Redis 適用于 數(shù)據(jù)實(shí)時性要求高、數(shù)據(jù)存儲有過期和淘汰特征的,、不需要持久化或者只需要保證弱一致性,、邏輯簡單的場景。 3,、新接手一個復(fù)雜的 Redis 集群(Sentinel 模式),,如何了解它剛剛接手一套 Redis 集群,想要了解這套集群的相關(guān)配置,。應(yīng)該如何入手,。難道只能通過 info 命令去查看各個配置嗎? 這是筆者的建議:
三,、Redis 故障排查 1,、Redis 實(shí)例中,存在大量的 FIN_WAIT2 連接 客戶端 TCP 狀態(tài)遷移: CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED 服務(wù)器 TCP 狀態(tài)遷移: CLOSED->LISTEN->SYN 收到 ->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED 這個狀態(tài)存在于主動發(fā)起斷開請求的一端,,如果服務(wù)器存在大量的這個狀態(tài),,那么這個服務(wù)器就充當(dāng)客戶端的角色,如網(wǎng)絡(luò)爬蟲,,出現(xiàn)的原因是由于客戶端發(fā)起 FIN 請求結(jié)束連接之后,,收到了服務(wù)端的應(yīng)答之后進(jìn)入 FIN_WAIT2,之后就沒收到服務(wù)端發(fā)送的 FIN 信號導(dǎo)致,。 PS:線上 Web 客戶端用的什么語言,? 此問題的評論值得一看:http://www./Question/231035-1406575 2、如何知道當(dāng)前 Redis 實(shí)例是處于阻塞狀態(tài),?解答一: 隨便 get 一個 key,,然后卡著不動就行,簡單粗暴,。優(yōu)雅一點(diǎn)是看 latency 的延遲,,blocked_clients 的數(shù)量,rejected_connections 的數(shù)量等,。 解答二:
3,、Redis 運(yùn)維的故障有哪些,?回答一: 常見的運(yùn)維故障
回答二: 我簡單說下 Redis 故障的排查方法吧,。
更多的排查需要對線上系統(tǒng)的分析,。 四,、Redis 性能優(yōu)化 1、提高 Redis 內(nèi)存數(shù)據(jù)庫的性能,,有哪些措施,?這個問題有點(diǎn)偏題了,還是回答下吧,。整理下工作中積累的經(jīng)驗(yàn):
|
|