現(xiàn)如今 Redis 變得越來越流行怎燥，幾乎在很多項目中都要被用到荠锭，不知道你在使用 Redis 時呼股，有沒有思考過耕魄，Redis 到底是如何穩(wěn)定、高性能地提供服務的彭谁？

你也可以嘗試回答一下以下這些問題：

• 我使用 Redis 的場景很簡單吸奴，只使用單機版 Redis 會有什么問題嗎？
• 我的 Redis 故障宕機了缠局，數(shù)據(jù)丟失了怎么辦则奥？如何能保證我的業(yè)務應用不受影響？
• 為什么需要主從集群狭园？它有什么優(yōu)勢读处？
• 什么是分片集群？我真的需要分片集群嗎唱矛？
• ...

如果你對 Redis 已經(jīng)有些了解罚舱，肯定也聽說過數(shù)據(jù)持久化井辜、主從復制、哨兵這些概念管闷，它們之間又有什么區(qū)別和聯(lián)系呢粥脚？

如果你存在這樣的疑惑，這篇文章包个，我會從 0 到 1刷允，再從 1 到 N，帶你一步步構建出一個穩(wěn)定碧囊、高性能的 Redis 集群恃锉。

在這個過程中，你可以了解到 Redis 為了做到穩(wěn)定呕臂、高性能，都采取了哪些優(yōu)化方案肪跋，以及為什么要這么做歧蒋？

掌握了這些原理，這樣平時你在使用 Redis 時州既，就能夠做到「游刃有余」谜洽。

這篇文章干貨很多，希望你可以耐心讀完吴叶。

從最簡單的開始：單機版 Redis

首先阐虚，我們從最簡單的場景開始。

假設現(xiàn)在你有一個業(yè)務應用蚌卤，需要引入 Redis 來提高應用的性能实束，此時你可以選擇部署一個單機版的 Redis 來使用，就像這樣：

這個架構非常簡單逊彭，你的業(yè)務應用可以把 Redis 當做緩存來使用咸灿，從 MySQL 中查詢數(shù)據(jù)，然后寫入到 Redis 中侮叮，之后業(yè)務應用再從 Redis 中讀取這些數(shù)據(jù)避矢，由于 Redis 的數(shù)據(jù)都存儲在內(nèi)存中，所以這個速度飛快囊榜。

如果你的業(yè)務體量并不大审胸，那這樣的架構模型基本可以滿足你的需求。是不是很簡單卸勺？

隨著時間的推移砂沛，你的業(yè)務體量逐漸發(fā)展起來了，Redis 中存儲的數(shù)據(jù)也越來越多曙求，此時你的業(yè)務應用對 Redis 的依賴也越來越重尺上。

但是材蛛，突然有一天，你的 Redis 因為某些原因宕機了怎抛，這時你的所有業(yè)務流量卑吭，都會打到后端 MySQL 上，這會導致你的 MySQL 壓力劇增马绝，嚴重的話甚至會壓垮 MySQL豆赏。

這時你應該怎么辦？

我猜你的方案肯定是富稻，趕緊重啟 Redis掷邦，讓它可以繼續(xù)提供服務。

但是椭赋，因為之前 Redis 中的數(shù)據(jù)都在內(nèi)存中抚岗，盡管你現(xiàn)在把 Redis 重啟了，之前的數(shù)據(jù)也都丟失了哪怔。重啟后的 Redis 雖然可以正常工作宣蔚，但是由于 Redis 中沒有任何數(shù)據(jù)，業(yè)務流量還是都會打到后端 MySQL 上认境，MySQL 的壓力還是很大胚委。

這可怎么辦？你陷入了沉思叉信。

有沒有什么好的辦法解決這個問題亩冬？

既然 Redis 只把數(shù)據(jù)存儲在內(nèi)存中，那是否可以把這些數(shù)據(jù)也寫一份到磁盤上呢硼身？

如果采用這種方式硅急，當 Redis 重啟時，我們把磁盤中的數(shù)據(jù)快速恢復到內(nèi)存中佳遂，這樣它就可以繼續(xù)正常提供服務了铜秆。

是的，這是一個很好的解決方案讶迁，這個把內(nèi)存數(shù)據(jù)寫到磁盤上的過程连茧，就是數(shù)據(jù)持久化。

數(shù)據(jù)持久化：有備無患

現(xiàn)在巍糯，你設想的 Redis 數(shù)據(jù)持久化是這樣的：

但是啸驯，數(shù)據(jù)持久化具體應該怎么做呢？

我猜你最容易想到的一個方案是祟峦，Redis 每一次執(zhí)行寫操作罚斗，除了寫內(nèi)存之外，同時也寫一份到磁盤上宅楞，就像這樣：

沒錯针姿，這是最簡單直接的方案袱吆。

但仔細想一下，這個方案有個問題：客戶端的每次寫操作距淫，既需要寫內(nèi)存绞绒，又需要寫磁盤，而寫磁盤的耗時相比于寫內(nèi)存來說榕暇，肯定要慢很多蓬衡！這勢必會影響到 Redis 的性能。

如何規(guī)避這個問題彤枢？

我們可以這樣優(yōu)化：Redis 寫內(nèi)存由主線程來做，寫內(nèi)存完成后就給客戶端返回結果壁晒，然后 Redis 用另一個線程去寫磁盤业栅，這樣就可以避免主線程寫磁盤對性能的影響秒咐。

這確實是一個好方案式镐。除此之外固蚤，我們可以換個角度娘汞，思考一下還有什么方式可以持久化數(shù)據(jù)？

這時你就要結合 Redis 的使用場景來考慮了夕玩。

回憶一下燎孟，我們在使用 Redis 時，通常把它用作什么場景旷偿？

是的爆侣，緩存。

把 Redis 當做緩存來用茫负，意味著盡管 Redis 中沒有保存全量數(shù)據(jù)忍法，對于不在緩存中的數(shù)據(jù)，我們的業(yè)務應用依舊可以通過查詢后端數(shù)據(jù)庫得到結果勉失，只不過查詢后端數(shù)據(jù)的速度會慢一點而已戴质，但對業(yè)務結果其實是沒有影響的告匠。

基于這個特點离唬，我們的 Redis 數(shù)據(jù)持久化還可以用「數(shù)據(jù)快照」的方式來做输莺。

那什么是數(shù)據(jù)快照呢？

簡單來講型凳，你可以這么理解：

• 你把 Redis 想象成一個水杯嘱函，向 Redis 寫入數(shù)據(jù)往弓，就相當于往這個杯子里倒水

• 此時你拿一個相機給這個水杯拍一張照片函似，拍照的這一瞬間，照片中記錄到這個水杯中水的容量顿天，就是水杯的數(shù)據(jù)快照

  
  

也就是說露氮，Redis 的數(shù)據(jù)快照榆骚，是記錄某一時刻下 Redis 中的數(shù)據(jù)，然后只需要把這個數(shù)據(jù)快照寫到磁盤上就可以了莫绣。

它的優(yōu)勢在于，只在需要持久化時模燥，把數(shù)據(jù)「一次性」寫入磁盤蔫骂，其它時間都不需要操作磁盤辽旋。

基于這個方案檐迟，我們可以定時給 Redis 做數(shù)據(jù)快照追迟，把數(shù)據(jù)持久化到磁盤上。

其實，上面說的這些持久化方案每瞒，就是 Redis 的「RDB」和「AOF」：

• RDB：只持久化某一時刻的數(shù)據(jù)快照到磁盤上（創(chuàng)建一個子進程來做）
• AOF：每一次寫操作都持久到磁盤（主線程寫內(nèi)存剿骨，根據(jù)策略可以配置由主線程還是子線程進行數(shù)據(jù)持久化）

它們的區(qū)別除了上面講到的浓利，還有以下特點：

• RDB 采用二進制 + 數(shù)據(jù)壓縮的方式寫磁盤贷掖，這樣文件體積小渴语，數(shù)據(jù)恢復速度也快
• AOF 記錄的是每一次寫命令驾凶，數(shù)據(jù)最全掷酗，但文件體積大泻轰，數(shù)據(jù)恢復速度慢

如果讓你來選擇持久化方案浮声，你可以這樣選擇：

• 如果你的業(yè)務對于數(shù)據(jù)丟失不敏感旋奢，采用 RDB 方案持久化數(shù)據(jù)
• 如果你的業(yè)務對數(shù)據(jù)完整性要求比較高黄绩，采用 AOF 方案持久化數(shù)據(jù)

假設你的業(yè)務對 Redis 數(shù)據(jù)完整性要求比較高爽丹，選擇了 AOF 方案，那此時你又會遇到這些問題：

• AOF 記錄每一次寫操作真仲，隨著時間增長秸应，AOF 文件體積會越來越大
• 這么大的 AOF 文件软啼，在數(shù)據(jù)恢復時變得非常慢

這怎么辦延柠？數(shù)據(jù)完整性要求變高了贞间，恢復數(shù)據(jù)也變困難了增热？有沒有什么方法，可以縮小文件體積公黑？提升恢復速度呢凡蚜？

我們繼續(xù)來分析 AOF 的特點番刊。

由于 AOF 文件中記錄的都是每一次寫操作，但對于同一個 key 可能會發(fā)生多次修改蝉绷，我們只保留最后一次被修改的值熔吗，是不是也可以桅狠？

是的轿秧，這就是我們經(jīng)常聽到的「AOF rewrite」菇篡，你也可以把它理解為 AOF 「瘦身」驱还。

我們可以對 AOF 文件定時 rewrite，避免這個文件體積持續(xù)膨脹闷沥，這樣在恢復時就可以縮短恢復時間了舆逃。

再進一步思考一下颖侄，還有沒有辦法繼續(xù)縮小 AOF 文件？

回顧一下我們前面講到的炊琉，RDB 和 AOF 各自的特點：

• RDB 以二進制 + 數(shù)據(jù)壓縮方式存儲，文件體積小
• AOF 記錄每一次寫命令锰悼，數(shù)據(jù)最全

我們可否利用它們各自的優(yōu)勢呢箕般？

當然可以丝里，這就是 Redis 的「混合持久化」杯聚。

具體來說抒痒，當 AOF rewrite 時故响，Redis 先以 RDB 格式在 AOF 文件中寫入一個數(shù)據(jù)快照彩届，再把在這期間產(chǎn)生的每一個寫命令惨缆，追加到 AOF 文件中。因為 RDB 是二進制壓縮寫入的寂汇，這樣 AOF 文件體積就變得更小了骄瓣。

此時榕栏，你在使用 AOF 文件恢復數(shù)據(jù)時扒磁，這個恢復時間就會更短了妨托！

Redis 4.0 以上版本才支持混合持久化兰伤。

這么一番優(yōu)化，你的 Redis 再也不用擔心實例宕機了，當發(fā)生宕機時负懦，你就可以用持久化文件快速恢復 Redis 中的數(shù)據(jù)。

但這樣就沒問題了嗎？

仔細想一下躯枢，雖然我們已經(jīng)把持久化的文件優(yōu)化到最小了，但在恢復數(shù)據(jù)時依舊是需要時間的，在這期間你的業(yè)務應用還是會受到影響朝抖，這怎么辦？

我們來分析有沒有更好的方案。

一個實例宕機，只能用恢復數(shù)據(jù)來解決按傅，那我們是否可以部署多個 Redis 實例，然后讓這些實例數(shù)據(jù)保持實時同步，這樣當一個實例宕機時，我們在剩下的實例中選擇一個繼續(xù)提供服務就好了压汪。

沒錯，這個方案就是接下來要講的 主從復制：多副本。

主從復制：多副本

此時，你可以部署多個 Redis 實例洒宝，架構模型就變成了這樣：

我們這里把實時讀寫的節(jié)點叫做 master枫夺，另一個實時同步數(shù)據(jù)的節(jié)點叫做 slave。

采用多副本的方案丑勤，它的優(yōu)勢是：

• 縮短不可用時間：master 發(fā)生宕機耙厚，我們可以手動把 slave 提升為 master 繼續(xù)提供服務
• 提升讀性能：讓 slave 分擔一部分讀請求呆细，提升應用的整體性能

這個方案不錯趴酣，不僅節(jié)省了數(shù)據(jù)恢復的時間岖寞，還能提升性能慎璧，那它有什么問題嗎跨释？

你可以思考一下岁疼。

其實捷绒，它的問題在于：當 master 宕機時贯要，我們需要「手動」把 slave 提升為 master崇渗，這個過程也是需要花費時間的宅广。

雖然比恢復數(shù)據(jù)要快得多跟狱，但還是需要人工介入處理挪挤。一旦需要人工介入，就必須要算上人的反應時間鸠信、操作時間症副，所以，在這期間你的業(yè)務應用依舊會受到影響沮明。

怎么解決這個問題荐健？我們是否可以把這個切換的過程窖逗，變成自動化呢佑附？

對于這種情況音同，我們需要一個「故障自動切換」機制权均，這就是我們經(jīng)常聽到的哨兵所具備的能力螺句。

哨兵：故障自動切換

現(xiàn)在蛇尚，我們可以引入一個「觀察者」取劫，讓這個觀察者去實時監(jiān)測 master 的健康狀態(tài)炮捧，這個觀察者就是「哨兵」。

具體如何做书蚪？

• 1.哨兵每間隔一段時間殊校，詢問 master 是否正常
• 2.master 正常回復读存，表示狀態(tài)正常为流，回復超時表示異常
• 3.哨兵發(fā)現(xiàn)異常，發(fā)起主從切換

有了這個方案让簿，就不需要人去介入處理了敬察，一切就變得自動化了，是不是很爽莲祸？

但這里還有一個問題，如果 master 狀態(tài)正常居凶，但這個哨兵在詢問 master 時虫给，它們之間的網(wǎng)絡發(fā)生了問題，那這個哨兵可能會誤判侠碧。

這個問題怎么解決抹估？

答案是，我們可以部署多個哨兵弄兜，讓它們分布在不同的機器上药蜻，它們一起監(jiān)測 master 的狀態(tài)，流程就變成了這樣：

• 1.多個哨兵每間隔一段時間替饿，詢問 master 是否正常
• 2.master 正秤镌螅回復，表示狀態(tài)正常视卢，回復超時表示異常
• 3.一旦有一個哨兵判定 master 異常（不管是否是網(wǎng)絡問題）踱卵，就詢問其它哨兵，如果多個哨兵（設置一個閾值）都認為 master 異常了，這才判定 master 確實發(fā)生了故障
• 4.多個哨兵經(jīng)過協(xié)商后惋砂，判定 master 故障妒挎，則發(fā)起主從切換

所以，我們用多個哨兵互相協(xié)商來判定 master 的狀態(tài)西饵，這樣一來酝掩，就可以大大降低誤判的概率。

哨兵協(xié)商判定 master 異常后眷柔，這里還有一個問題：由哪個哨兵來發(fā)起主從切換呢期虾？

答案是，選出一個哨兵「領導者」驯嘱，由這個領導者進行主從切換镶苞。

問題又來了，這個領導者怎么選宙拉？

想象一下宾尚，在現(xiàn)實生活中丙笋，選舉是怎么做的谢澈？

是的，投票御板。

在選舉哨兵領導者時锥忿，我們可以制定這樣一個選舉規(guī)則：

• 每個哨兵都詢問其它哨兵，請求對方為自己投票
• 每個哨兵只投票給第一個請求投票的哨兵怠肋，且只能投票一次
• 首先拿到超過半數(shù)投票的哨兵敬鬓，當選為領導者，發(fā)起主從切換

其實笙各，這個選舉的過程就是我們經(jīng)常聽到的：分布式系統(tǒng)領域中的共識算法钉答。

什么是共識算法？

我們在多個機器部署哨兵杈抢，它們需要共同協(xié)作完成一項任務数尿，所以它們就組成了一個「分布式系統(tǒng)」。

在分布式系統(tǒng)領域惶楼，多個節(jié)點如何就一個問題達成共識的算法右蹦，就叫共識算法。

在這個場景下歼捐，多個哨兵共同協(xié)商何陆，選舉出一個都認可的領導者，就是使用共識算法完成的豹储。

這個算法還規(guī)定節(jié)點的數(shù)量必須是奇數(shù)個贷盲，這樣可以保證系統(tǒng)中即使有節(jié)點發(fā)生了故障，剩余超過「半數(shù)」的節(jié)點狀態(tài)正常剥扣，依舊可以提供正確的結果巩剖，也就是說慨灭，這個算法還兼容了存在故障節(jié)點的情況。

共識算法在分布式系統(tǒng)領域有很多球及，例如 Paxos氧骤、Raft，哨兵選舉領導者這個場景吃引，使用的是 Raft 共識算法筹陵，因為它足夠簡單，且易于實現(xiàn)镊尺。

現(xiàn)在朦佩，我們用多個哨兵共同監(jiān)測 Redis 的狀態(tài)，這樣一來庐氮，就可以避免誤判的問題了语稠，架構模型就變成了這樣：

好了，到這里我們先小結一下弄砍。

你的 Redis 從最簡單的單機版仙畦，經(jīng)過數(shù)據(jù)持久化、主從多副本音婶、哨兵集群慨畸，這一路優(yōu)化下來，你的 Redis 不管是性能還是穩(wěn)定性衣式，都越來越高寸士，就算節(jié)點發(fā)生故障，也不用擔心了碴卧。

你的 Redis 以這樣的架構模式部署弱卡，基本上就可以穩(wěn)定運行很長時間了。

...

隨著時間的發(fā)展住册，你的業(yè)務體量開始迎來了爆炸性增長婶博，此時你的架構模型，還能夠承擔這么大的流量嗎界弧？

我們一起來分析一下：

• 穩(wěn)定性：Redis 故障宕機凡蜻，我們有哨兵 + 副本，可以自動完成主從切換
• 性能：讀請求量增長垢箕，我們可以再部署多個 slave划栓，讀寫分離，分擔讀壓力
• 性能：寫請求量增長条获，但我們只有一個 master 實例忠荞，這個實例達到瓶頸怎么辦？

看到了么，當你的寫請求量越來越大時委煤，一個 master 實例可能就無法承擔這么大的寫流量了堂油。

要想完美解決這個問題，此時你就需要考慮使用分片集群了碧绞。

分片集群：橫向擴展

什么是分片集群府框？

簡單來講，一個實例扛不住寫壓力讥邻，那我們是否可以部署多個實例迫靖，然后把這些實例按照一定規(guī)則組織起來，把它們當成一個整體兴使，對外提供服務系宜，這樣不就可以解決集中寫一個實例的瓶頸問題嗎？

所以发魄，現(xiàn)在的架構模型就變成了這樣：

現(xiàn)在問題又來了盹牧，這么多實例如何組織呢？

我們制定規(guī)則如下：

• 每個節(jié)點各自存儲一部分數(shù)據(jù)励幼，所有節(jié)點數(shù)據(jù)之和才是全量數(shù)據(jù)
• 制定一個路由規(guī)則汰寓，對于不同的 key，把它路由到固定一個實例上進行讀寫

而分片集群根據(jù)路由規(guī)則所在位置的不同赏淌，還可以分為兩大類：

• 客戶端分片
• 服務端分片

客戶端分片指的是踩寇，key 的路由規(guī)則放在客戶端來做啄清，就是下面這樣：

這個方案的缺點是六水，客戶端需要維護這個路由規(guī)則，也就是說辣卒，你需要把路由規(guī)則寫到你的業(yè)務代碼中掷贾。

如何做到不把路由規(guī)則耦合在業(yè)務代碼中呢？

你可以這樣優(yōu)化荣茫，把這個路由規(guī)則封裝成一個模塊想帅，當需要使用時，集成這個模塊就可以了啡莉。

這就是 Redis Cluster 的采用的方案港准。

Redis Cluster 內(nèi)置了哨兵邏輯，無需再部署哨兵咧欣。

當你使用 Redis Cluster 時浅缸，你的業(yè)務應用需要使用配套的 Redis SDK，這個 SDK 內(nèi)就集成好了路由規(guī)則魄咕，不需要你自己編寫了衩椒。

再來看服務端分片。

這種方案指的是，路由規(guī)則不放在客戶端來做毛萌，而是在客戶端和服務端之間增加一個「中間代理層」苟弛，這個代理就是我們經(jīng)常聽到的 Proxy。

而數(shù)據(jù)的路由規(guī)則阁将，就放在這個 Proxy 層來維護膏秫。

這樣一來，你就無需關心服務端有多少個 Redis 節(jié)點了做盅，只需要和這個 Proxy 交互即可荔睹。

Proxy 會把你的請求根據(jù)路由規(guī)則，轉(zhuǎn)發(fā)到對應的 Redis 節(jié)點上言蛇，而且僻他，當集群實例不足以支撐更大的流量請求時，還可以橫向擴容腊尚，添加新的 Redis 實例提升性能吨拗，這一切對于你的客戶端來說，都是透明無感知的婿斥。

業(yè)界開源的 Redis 分片集群方案劝篷，例如 Twemproxy、Codis 就是采用的這種方案民宿。

分片集群在數(shù)據(jù)擴容時娇妓，還涉及到了很多細節(jié)，這塊內(nèi)容不是本文章重點活鹰，所以暫不詳述哈恰。

至此，當你使用分片集群后志群，對于未來更大的流量壓力着绷，都可以從容面對了！

總結

好了锌云，我們來總結一下荠医，我們是如何一步步構建一個穩(wěn)定、高性能的 Redis 集群的桑涎。

首先彬向，在使用最簡單的單機版 Redis 時，我們發(fā)現(xiàn)當 Redis 故障宕機后攻冷，數(shù)據(jù)無法恢復的問題娃胆，因此我們想到了「數(shù)據(jù)持久化」，把內(nèi)存中的數(shù)據(jù)也持久化到磁盤上一份讲衫，這樣 Redis 重啟后就可以從磁盤上快速恢復數(shù)據(jù)缕棵。

在進行數(shù)據(jù)持久化時孵班，我們又面臨如何更高效地將數(shù)據(jù)持久化到磁盤的問題。之后我們發(fā)現(xiàn) Redis 提供了 RDB 和 AOF 兩種方案招驴，分別對應了數(shù)據(jù)快照和實時的命令記錄篙程。當我們對數(shù)據(jù)完整性要求不高時，可以選擇 RDB 持久化方案别厘。如果對于數(shù)據(jù)完整性要求較高虱饿，那么可以選擇 AOF 持久化方案。

但是我們又發(fā)現(xiàn)触趴，AOF 文件體積會隨著時間增長變得越來越大氮发，此時我們想到的優(yōu)化方案是，使用 AOF rewrite 的方式對其進行瘦身冗懦，減小文件體積爽冕，再后來，我們發(fā)現(xiàn)可以結合 RDB 和 AOF 各自的優(yōu)勢披蕉，在 AOF rewrite 時使用兩者結合的「混合持久化」方式颈畸，又進一步減小了 AOF 文件體積。

之后没讲，我們發(fā)現(xiàn)盡管可以通過數(shù)據(jù)恢復的方式還原數(shù)據(jù)眯娱，但恢復數(shù)據(jù)也是需要花費時間的，這意味著業(yè)務應用還是會受到影響爬凑。我們進一步優(yōu)化徙缴，采用「多副本」的方案，讓多個實例保持實時同步嘁信，當一個實例故障時于样，可以手動把其它實例提升上來繼續(xù)提供服務。

但是這樣也有問題吱抚，手動提升實例上來百宇，需要人工介入，人工介入操作也需要時間秘豹，我們開始想辦法把這個流程變得自動化，所以我們又引入了「哨兵」集群昌粤，哨兵集群通過互相協(xié)商的方式既绕，發(fā)現(xiàn)故障節(jié)點，并可以自動完成切換涮坐，這樣就大幅降低了對業(yè)務應用的影響凄贩。

最后，我們把關注點聚焦在如何支撐更大的寫流量上袱讹，所以疲扎，我們又引入了「分片集群」來解決這個問題昵时，讓多個 Redis 實例分攤寫壓力，未來面對更大的流量椒丧，我們還可以添加新的實例壹甥，橫向擴展，進一步提升集群的性能壶熏。

至此句柠，我們的 Redis 集群才得以長期穩(wěn)定、高性能的為我們的業(yè)務提供服務棒假。

這里我畫了一個思維導圖溯职，方便你更好地去理解它們之間的關系，以及演化的過程帽哑。

后記

看到這里谜酒，我想你對如何構建一個穩(wěn)定、高性能的 Redis 集群問題時妻枕，應該會有自己的見解了甚带。

其實，這篇文章所講的優(yōu)化思路佳头，圍繞的主題就是「架構設計」的核心思想：

• 高性能：讀寫分離鹰贵、分片集群
• 高可用：數(shù)據(jù)持久化、多副本康嘉、故障自動切換
• 易擴展：分片集群碉输、橫向擴展

當我們講到哨兵集群、分片集群時亭珍，這還涉及到了「分布式系統(tǒng)」相關的知識：

• 分布式共識：哨兵領導者選舉
• 負載均衡：分片集群數(shù)據(jù)分片敷钾、數(shù)據(jù)路由

當然，除了 Redis 之外肄梨，對于構建任何一個數(shù)據(jù)集群阻荒，你都可以沿用這個思路去思考、去優(yōu)化众羡，看看它們到底是如何做的侨赡。

例如當你在使用 MySQL 時，你可以思考一下 MySQL 與 Redis 有哪些不同粱侣？MySQL 為了做到高性能羊壹、高可用，又是如何做的齐婴？其實思路都是類似的油猫。

我們現(xiàn)在到處可見分布式系統(tǒng)、數(shù)據(jù)集群柠偶，我希望通過這篇文章情妖，你可以理解這些軟件是如何一步步演化過來的睬关，在演化過程中，它們遇到了哪些問題毡证，為了解決這些問題电爹，這些軟件的設計者設計了怎樣的方案，做了哪些取舍情竹？

你只有了解了其中的原理藐不，掌握了分析問題、解決問題的能力秦效，這樣在以后的開發(fā)過程中雏蛮，或是學習其它優(yōu)秀軟件時，就能快速地找到「重點」阱州，在最短的時間掌握它挑秉，并能在實際應用中發(fā)揮它們的優(yōu)勢。

其實這個思考過程苔货，也是做「架構設計」的思路犀概。在做軟件架構設計時，你面臨的場景就是發(fā)現(xiàn)問題夜惭、分析問題姻灶、解決問題，一步步去演化诈茧、升級你的架構产喉，最后在性能、可靠性方面達到一個平衡敢会。雖然各種軟件層出不窮曾沈，但架構設計的思想不會變，我希望你真正吸收的是這些思想鸥昏，這樣才可以做到以不變應萬變塞俱。

原文鏈接：https://blog.csdn.net/asdf12388999/article/details/128834441