什么是 Redis茫叭？
Redis（REmote DIctionary Service）是一個開源的鍵值對數(shù)據(jù)庫服務器。
Redis 更準確的描述是一個數(shù)據(jù)結構服務器半等。Redis 的這種特殊性質讓它在開發(fā)人員中很受歡迎揍愁。
Redis不是通過迭代或者排序方式處理數(shù)據(jù)，而是一開始就按照數(shù)據(jù)結構方式組織杀饵。早期莽囤，它的使用很像 Memcached，但隨著 Redis 的改進切距，它在許多其他用例中變得可行朽缎，包括發(fā)布-訂閱機制、流（streaming）和隊列谜悟。
主要來說话肖，Redis 是一個內存數(shù)據(jù)庫，用作另一個“真實”數(shù)據(jù)庫（如 MySQL 或 PostgreSQL）前面的緩存葡幸，以幫助提高應用程序性能最筒。它通過利用內存的高速訪問速度，從而減輕核心應用程序數(shù)據(jù)庫的負載蔚叨，例如：
不經常更改且經常被請求的數(shù)據(jù)
任務關鍵性較低且經常變動的數(shù)據(jù)
上述數(shù)據(jù)的示例可以包括會話或數(shù)據(jù)緩存以及儀表板的排行榜或匯總分析床蜘。
但是辙培，對于許多用例場景，Redis 都可以提供足夠的保證邢锯，可以將其用作成熟的主數(shù)據(jù)庫扬蕊。再加上 Redis 插件及其各種高可用性（HA）設置，Redis 作為數(shù)據(jù)庫對于某些場景和工作負載變得非常有用丹擎。
另一個重要方面是 Redis 模糊了緩存和數(shù)據(jù)存儲之間的界限尾抑。這里要理解的重要一點是，相比于使用 SSD 或 HDD 作為存儲的傳統(tǒng)數(shù)據(jù)庫鸥鹉，讀取和操作內存中數(shù)據(jù)的速度要快得多蛮穿。
最初，Redis 最常被比作 Memcached毁渗，后者當時缺乏任何非易失性持久化。
這是當前兩個緩存之間的功能細分单刁。
雖然現(xiàn)在擁有多種配置方式將數(shù)據(jù)持久化到磁盤灸异，但當時首次引入持久化時，Redis 是使用快照方式羔飞，通過異步拷貝內存中的數(shù)據(jù)方式來做持久化肺樟。不幸的是，這種機制的缺點是可能會在快照之間丟失數(shù)據(jù)逻淌。
Redis 自 2009 年成立到現(xiàn)在已經變的很成熟么伯。我們將介紹它的大部分架構和拓撲，以便你可以將 Redis 添加到你的數(shù)據(jù)存儲系統(tǒng)庫中卡儒。
Redis 架構
在開始討論 Redis 內部結構之前田柔，讓我們先討論一下各種 Redis 部署及其權衡取舍。
我們將主要關注以下這些設置：
單個 Redis 實例
Redis 高可用性
Redis 哨兵
Redis 集群
根據(jù)你的用例和規(guī)模骨望，決定使用哪一種設置硬爆。
單個 Redis 實例
單個 Redis 實例是最直接的 Redis 部署方式。它允許用戶設置和運行小型實例擎鸠，從而幫助他們快速發(fā)展和加速服務缀磕。但是，這種部署并非沒有缺點劣光。例如袜蚕，如果此實例失敗或不可用，則所有客戶端對 Redis 的調用都將失敗绢涡，從而降低系統(tǒng)的整體性能和速度牲剃。
如果有足夠的內存和服務器資源，這個實例可以很強大垂寥。主要用于緩存的場景可能會以最少的設置獲得顯著的性能提升颠黎。給定足夠的系統(tǒng)資源另锋，你可以在應用程序運行的同一機器上部署此 Redis 服務。
在管理系統(tǒng)內的數(shù)據(jù)方面狭归，了解一些 Redis 概念是必不可少的夭坪。發(fā)送到 Redis 的命令首先在內存中處理。然后过椎，如果在這些實例上設置了持久性室梅，則在某個時間間隔上會有一個fork進程，來生成數(shù)據(jù)持久化 RDB（Redis 數(shù)據(jù)的非常緊湊的時間點表示）快照或 AOF（僅附加文件）疚宇。
這兩個流程可以讓 Redis 擁有長期存儲亡鼠，支持各種復制策略，并啟用更復雜的拓撲敷待。如果 Redis 未設置為持久化數(shù)據(jù)间涵，則在重新啟動或故障轉移時數(shù)據(jù)會丟失。如果在重啟時啟用了持久化榜揖，它會將 RDB 快照或 AOF 中的所有數(shù)據(jù)加載回內存勾哩，然后實例可以支持新的客戶端請求。
話雖如此举哟，讓我們看看你可能會用到的更多分布式 Redis 設置思劳。
Redis 高可用性
Redis 的另一個流行設置是主從部署方式焊切，從部署保持與主部署之間數(shù)據(jù)同步态辛。當數(shù)據(jù)寫入主實例時，它會將這些命令的副本發(fā)送到從部署客戶端輸出緩沖區(qū)坝冕，從而達到數(shù)據(jù)同步的效果壶硅。從部署可以有一個或多個實例威兜。這些實例可以幫助擴展 Redis 的讀取操作或提供故障轉移，以防 main 丟失森瘪。
我們現(xiàn)在已經進入了一個分布式系統(tǒng)牡属，因此需要在此拓撲中考慮許多新事物。以前簡單的事情現(xiàn)在變得復雜了扼睬。
Redis 復制
Redis 的每個主實例都有一個復制 ID 和一個偏移量逮栅。這兩條數(shù)據(jù)對于確定副本可以繼續(xù)其復制過程的時間點或確定它是否需要進行完整同步至關重要。對于主 Redis 部署上發(fā)生的每個操作窗宇，此偏移量都會增加措伐。
更明確地說，當 Redis 副本實例僅落后于主實例幾個偏移量時军俊，它會從主實例接收剩余的命令侥加，然后在其數(shù)據(jù)集上重放，直到同步完成粪躬。如果兩個實例無法就復制 ID 達成一致担败，或者主實例不知道偏移量昔穴，則副本將請求全量同步。這時主實例會創(chuàng)建一個新的 RDB 快照并將其發(fā)送到副本提前。
在此傳輸之間吗货，主實例會緩沖快照截止和當前偏移之間的所有中間更新指令，這樣在快照同步完后狈网，再將這些指令發(fā)送到副本實例宙搬。這樣完成后，復制就可以正常繼續(xù)拓哺。
如果一個實例具有相同的復制 ID 和偏移量勇垛，則它們具有完全相同的數(shù)據(jù)。現(xiàn)在你可能想知道為什么需要復制 ID士鸥。當 Redis 實例被提升為主實例或作為主實例從頭開始重新啟動時闲孤，它會被賦予一個新的復制 ID。
這用于推斷此新提升的副本實例是從先前哪個主實例復制出來的烤礁。這允許它能夠執(zhí)行部分同步（與其他副本節(jié)點）崭放，因為新的主實例會記住其舊的復制 ID。
例如鸽凶，兩個實例（主實例和從實例）具有相同的復制 ID，但偏移量相差幾百個命令建峭，這意味著如果在實例上重放這些偏移量后面的命令玻侥，它們將具有相同的數(shù)據(jù)集。現(xiàn)在亿蒸，如果復制 ID 完全不同凑兰，并且我們不知道新降級（或重新加入）從節(jié)點的先前復制 ID（沒有共同祖先）。我們將需要執(zhí)行昂貴的全量同步边锁。
相反姑食，如果我們知道以前的復制 ID，我們就可以推斷如何使數(shù)據(jù)同步茅坛，因為我們能夠推斷出它們共享的共同祖先音半，并且偏移量對于部分同步再次有意義。
Redis 哨兵（Sentinel）
Sentinel 是一個分布式系統(tǒng)贡蓖。與所有分布式系統(tǒng)一樣曹鸠，Sentinel 有幾個優(yōu)點和缺點。Sentinel 的設計方式是斥铺，一組哨兵進程協(xié)同工作以協(xié)調狀態(tài)彻桃，從而為 Redis 提供高可用性。畢竟晾蜘，你不希望保護你免受故障影響的系統(tǒng)有自己的單點故障邻眷。
Sentinel 負責一些事情眠屎。首先，它確保當前的主實例和從實例正常運行并做出響應肆饶。這是必要的改衩，因為哨兵（與其他哨兵進程）可以在主節(jié)點和/或從節(jié)點丟失的情況下發(fā)出警報并采取行動。其次抖拴，它在服務發(fā)現(xiàn)中發(fā)揮作用燎字，就像其他系統(tǒng)中的 Zookeeper 和 Consul 一樣。所以當一個新的客戶端嘗試向 Redis 寫東西時阿宅，Sentinel 會告訴客戶端當前的主實例是什么候衍。
因此，哨兵不斷監(jiān)控可用性并將該信息發(fā)送給客戶端洒放，以便他們能夠在他們確實進行故障轉移時對其做出反應蛉鹿。
以下是它的職責：
監(jiān)控——確保主從實例按預期工作。
通知——通知系統(tǒng)管理員 Redis 實例中的事件往湿。
故障轉移管理——如果主實例不可用并且足夠多的（法定數(shù)量）節(jié)點同意這是真的妖异，Sentinel 節(jié)點可以啟動故障轉移。
配置管理——Sentinel 節(jié)點還充當當前主 Redis 實例的發(fā)現(xiàn)服務领追。
以這種方式使用 Redis Sentinel 可以進行故障檢測他膳。此檢測涉及多個哨兵進程同意當前主實例不再可用。這個協(xié)議過程稱為 Quorum绒窑。這可以提高魯棒性并防止一臺機器行為異常導致無法訪問主 Redis 節(jié)點棕孙。
此設置并非沒有缺點，因此我們將在使用 Redis Sentinel 時介紹一些建議和最佳實踐些膨。
你可以通過多種方式部署 Redis Sentinel蟀俊。老實說，要提出任何明智的建議订雾，我需要有關你的系統(tǒng)的更多背景信息肢预。作為一般指導，我建議在每個應用程序服務器旁邊運行一個哨兵節(jié)點（如果可能的話）洼哎，這樣你也不需要考慮哨兵節(jié)點和實際使用 Redis 的客戶端之間的網絡可達性差異烫映。
你可以將 Sentinel 與 Redis 實例一起運行，甚至可以在獨立節(jié)點上運行谱净，只不過它會按照別的方式處理窑邦，從而會讓事情變得更復雜。我建議至少運行三個節(jié)點壕探，并且至少具有兩個法定人數(shù)（quorum）冈钦。這是一個簡單的圖表，分解了集群中的服務器數(shù)量以及相關的法定人數(shù)和可容忍的可持續(xù)故障李请。
這會因系統(tǒng)而異瞧筛，但總體思路是不變的厉熟。
讓我們花點時間思考一下這樣的設置會出現(xiàn)什么問題。如果你運行這個系統(tǒng)足夠長的時間较幌，你會遇到所有這些揍瑟。
如果哨兵節(jié)點超出法定人數(shù)怎么辦？
如果網絡分裂將舊的主實例置于少數(shù)群體中怎么辦乍炉？這些寫入會發(fā)生什么绢片？（劇透：當系統(tǒng)完全恢復時它們會丟失）
如果哨兵節(jié)點和客戶端節(jié)點（應用程序節(jié)點）的網絡拓撲錯位會發(fā)生什么？
沒有持久性保證岛琼，特別是持久化到磁盤的操作（見下文）是異步的底循。還有一個麻煩的問題槐瑞，當客戶發(fā)現(xiàn)新的 primary 時，我們失去了多少寫給一個不知道的 primary困檩？Redis 建議在建立新連接時查詢新的主節(jié)點。根據(jù)系統(tǒng)配置悼沿，這可能意味著大量數(shù)據(jù)丟失等舔。
如果你強制主實例將寫入復制到至少一個副本實例糟趾，有幾種方法可以減輕損失程度软瞎。請記住拉讯，所有 Redis 復制都是異步的，這是有其權衡的考慮鳖藕。因此魔慷，它需要獨立跟蹤確認著恩，如果至少有一個副本實例沒有確認它們，主實例將停止接受寫入喉誊。
Redis 集群
我相信很多人都想過當你無法將所有數(shù)據(jù)存儲在一臺機器上的內存中時會發(fā)生什么伍茄。目前，單個服務器中可用的最大 RAM 為 24TIB敷矫，這是目前 AWS 線上列出來的汉额。當然榨汤，這很多，但對于某些系統(tǒng)來說妓灌，這還不夠蜜宪，即使對于緩存層也是如此。
Redis Cluster 允許 Redis 的水平擴展端壳。
首先，讓我們擺脫一些術語約束岖免；一旦我們決定使用 Redis 集群照捡，我們就決定將我們存儲的數(shù)據(jù)分散到多臺機器上，這稱為分片闯参。所以集群中的每個 Redis 實例都被認為是整個數(shù)據(jù)的一個分片悲立。
這帶來了一個新的問題。如果我們向集群推送一個key薪夕，我們如何知道哪個 Redis 實例（分片）保存了該數(shù)據(jù)？有幾種方法可以做到這一點馏慨，但 Redis Cluster 使用算法分片姑隅。
為了找到給定 key 的分片，我們對 key 進行哈希處理慕趴，并通過對總分片數(shù)量取模。然后秩贰，使用確定性哈希函數(shù)，這意味著給定的 key 將始終映射到同一個分片丙唧，我們可以推斷將來讀取特定 key 的位置觅玻。
當我們之后想在系統(tǒng)中添加一個新的分片時會發(fā)生什么？這個過程稱為重新分片溪厘。
假設鍵 'foo' 之前映射到分片 0， 在引入新分片后它可能會映射到分片 5侧甫。但是蹋宦，如果我們需要快速擴展系統(tǒng)，移動數(shù)據(jù)來達到新的分片映射守屉，這將是緩慢且不切實際的蒿辙。它還對 Redis 集群的可用性產生不利影響。
Redis Cluster 為這個問題設計了一種解決方案思灌，稱為 Hashslot，所有數(shù)據(jù)都映射到它绪颖。有 16K 哈希槽甜奄。這為我們提供了一種在集群中傳播數(shù)據(jù)的合理方式窃款，當我們添加新的分片時，我們只需在系統(tǒng)之間移動哈希槽烟阐。通過這樣做，我們只需要將 hashlot 從一個分片移動到另一個分片蜒茄，并簡化將新的主實例添加到集群中的過程。
這可以在沒有任何停機時間和最小的性能影響的情況下實現(xiàn)玩祟。讓我們通過一個例子來談談屿聋。
M1 包含從 0 到 8191 的哈希槽。
M2 包含從 8192 到 16383 的哈希槽润讥。
因此，為了映射 “foo”撮慨，我們采用一個確定性的鍵（foo）散列脆粥，并通過散列槽的數(shù)量（16K）對其進行修改，從而得到 M2 的映射「Х停現(xiàn)在假設我們添加了一個新實例 M3弟胀。新的映射將是：
M1 包含從 0 到 5460 的哈希槽。
M2 包含從 5461 到 10922 的哈希槽萧朝。
M3 包含從 10923 到 16383 的哈希槽夏哭。
現(xiàn)在映射到 M2 的 M1 中映射哈希槽的所有鍵都需要移動。但是散列槽的各個鍵的散列不需要移動何址，因為它們已經被劃分到散列槽中进胯。因此，這一級別的誤導（misdirection）解決了算法分片的重新分片問題偎血。
Gossiping 協(xié)議
Redis Cluster 使用 gossiping 來確定整個集群的健康狀況。在上圖中笨农，我們有 3 個 M 個節(jié)點和 3 個 S 節(jié)點帖渠。所有這些節(jié)點不斷地進行通信以了解哪些分片可用并準備好為請求提供服務。
如果足夠多的分片同意 M1 沒有響應诊霹，他們可以決定將 M1 的副本 S1 提升為主節(jié)點以保持集群健康渣淳。觸發(fā)此操作所需的節(jié)點數(shù)量是可配置的，并且必須正確執(zhí)行此操作鄙漏。如果操作不當并且在分區(qū)的兩邊相等時無法打破平局棺蛛，則可能會導致集群被拆分。這種現(xiàn)象稱為裂腦桦踊。作為一般規(guī)則终畅，必須擁有奇數(shù)個主節(jié)點和兩個副本，以實現(xiàn)最穩(wěn)健的設置杖狼。
Redis 持久化模型
如果我們要使用 Redis 存儲任何類型的數(shù)據(jù)同時要求安全保存妖爷，了解 Redis 是如何做到這一點很重要。在許多用例中绿聘，如果你丟失了 Redis 存儲的數(shù)據(jù)次舌，這并不是世界末日。將其用作緩存或在其支持實時分析的情況下，如果發(fā)生數(shù)據(jù)丟失，則并非世界末日洛史。
在其他場景中酱吝，我們希望圍繞數(shù)據(jù)持久性和恢復有一些保證。
無持久化
無持久化：如果你愿意忆嗜，可以完全禁用持久化崎岂。這是運行 Redis 的最快方式冲甘，并且沒有持久性保證。
RDB文件
RDB（Redis 數(shù)據(jù)庫）：RDB 持久化以指定的時間間隔執(zhí)行數(shù)據(jù)集的時間點快照江醇。
這種機制的主要缺點是快照之間的數(shù)據(jù)會丟失陶夜。此外，這種存儲機制還依賴于主進程的 fork条辟，在更大的數(shù)據(jù)集中捂贿，這可能會導致服務請求的瞬間延遲。話雖如此厂僧，RDB 文件在內存中的加載速度要比 AOF 快得多颜屠。
AOF
AOF（Append Only File）：AOF 持久化記錄服務器接收到的每個寫入操作，這些操作將在服務器啟動時再次被執(zhí)行甫窟，重建原始數(shù)據(jù)集粗井。
這種持久性的方法能夠確保比 RDB 快照更持久街图，因為它是一個僅附加文件懒构。隨著操作的發(fā)生，我們將它們緩沖到日志中絮姆，但它們還沒有被持久化秩霍。該日志與我們運行的實際命令一致，以便在需要時進行重放鸽照。
然后匿垄，如果可能，我們使用 fsync 將其刷新到磁盤（當此運行可配置時）漏峰，它將被持久化届榄。缺點是格式不緊湊，并且比 RDB 文件使用更多的磁盤靖苇。
為什么不兼得班缰？
RDB + AOF：可以將 AOF 和 RDB 組合在同一個 Redis 實例中。如果你愿意的話脾拆，可以以速度換取持久化是一種折衷方法莹妒。我認為這是設置 Redis 的一種可接受的方式。在重啟的情況下渠驼，請記住如果兩者都啟用鉴腻，Redis 將使用 AOF 來重建數(shù)據(jù)，因為它是最完整的蜓席。
Forking
現(xiàn)在我們了解了持久化的類型瓮床，讓我們討論一下我們如何在像 Redis 這樣的單線程應用程序中實際執(zhí)行它产镐。
在我看來，Redis 最酷的部分是它如何利用 forking 和寫時復制來高效地促進數(shù)據(jù)持久化丑掺。
Forking 是操作系統(tǒng)通過創(chuàng)建自身副本來創(chuàng)建新進程的一種方式述雾。這樣，你將獲得一個新的進程 ID 和一些其他信息和句柄唆缴，因此新 forking 的進程（子進程）可以與原始進程父進程通信黍翎。
現(xiàn)在事情變得有趣了匣掸。Redis 是一個分配了大量內存的進程，那么它如何在不耗盡內存的情況下進行復制呢碰酝？
當你 fork 一個進程時送爸，父進程和子進程共享內存，并且在該子進程中 Redis 開始快照（Redis）進程弄痹。這是通過一種稱為寫時復制的內存共享技術實現(xiàn)的——該技術在創(chuàng)建分叉時傳遞對內存的引用嵌器。如果在子進程持久化到磁盤時沒有發(fā)生任何更改，則不會進行新的分配蚓让。
在發(fā)生更改的情況下，內核會跟蹤對每個頁面的引用窄瘟，如果某個頁面有多個更改趟卸，則將更改寫入新頁面。子進程完全不知道更改以及具有一致的內存快照的事情图云。因此邻邮，在只使用了一小部分內存的情況下，我們能夠非车と快速有效地獲得潛在千兆字節(jié)內存的時間點快照鸭蛙！
