今天我們來聊聊如何基于redis數(shù)據(jù)庫擴展數(shù)據(jù)服務(wù)，如何實現(xiàn)分片（sharding）以及高可用（high availability）。

分布式系統(tǒng)不存在完美的設(shè)計，處處都體現(xiàn)了trade off。

因此我們在開始正文前，需要確定后續(xù)的討論原則，仍然以分布式系統(tǒng)設(shè)計中的CAP原則為例。由于主角是redis，那性能表現(xiàn)肯定是最高設(shè)計目標(biāo)，之后討論過程中的所有抉擇，都會優(yōu)先考慮CAP中的AP性質(zhì)。

兩個點按順序來，先看分片。

何謂分片？簡單來說，就是對單機redis做水平擴展。

當(dāng)然，做游戲的同學(xué)可能要問了，一服一個redis，為什么需要水平擴展？這個話題我們在之前幾篇文章中都有討論，可以看這里，或這里，小說君不再贅述。

如果要實現(xiàn)服務(wù)級別的復(fù)用，那么數(shù)據(jù)服務(wù)的定位往往是全局服務(wù)。如此僅用單實例的redis就難以應(yīng)對多變的負(fù)載情況——畢竟redis是單線程的。

從mysql一路用過來的同學(xué)這時都會習(xí)慣性地水平拆分，redis中也是類似的原理，將整體的數(shù)據(jù)進行切分，每一部分是一個分片（shard），不同的分片維護不同的key集合。

那么，分片問題的實質(zhì)就是如何基于多個redis實例設(shè)計全局統(tǒng)一的數(shù)據(jù)服務(wù)。同時，有一個約束條件，那就是我們無法保證強一致性。

也就是說，數(shù)據(jù)服務(wù)進行分片擴展的前提是，不提供跨分片事務(wù)的保障。redis cluster也沒有提供類似支持，因為分布式事務(wù)本來就跟redis的定位是有沖突的。

因此，我們的分片方案有兩個限制：

·不同分片中的數(shù)據(jù)一定是嚴(yán)格隔離的，比如是不同組服的數(shù)據(jù)，或者是完全不相干的數(shù)據(jù)。要想實現(xiàn)跨分片的數(shù)據(jù)交互，必須依賴更上層的協(xié)調(diào)機制保證，數(shù)據(jù)服務(wù)層面不做任何承諾。 而且這樣一來，如果想給應(yīng)用層提供協(xié)調(diào)機制，只要在每個分片上部署上篇文章介紹的 單實例簡易鎖機制 即可，簡單明了。

·我們的分片方案無法在分片間做類似分布式存儲系統(tǒng)的數(shù)據(jù)冗余機制，換言之，一份數(shù)據(jù)交叉存在多個分片中。

如何實現(xiàn)分片？

首先，我們要確定分片方案需要解決什么問題。

分片的redis集群，實際上共同組成了一個有狀態(tài)服務(wù)（stateful service）。設(shè)計有狀態(tài)服務(wù)，我們通常會從兩點考慮：

cluster membership，系統(tǒng)間各個節(jié)點，或者說各個分片的關(guān)系是怎樣的。

work distribution，外部請求應(yīng)該如何、交由哪個節(jié)點處理，或者說用戶（以下都簡稱dbClient）的一次讀或?qū)憫?yīng)該去找哪個分片。

針對第一個問題，解決方案通常有三：

·presharding，也就是sharding靜態(tài)配置。

·

·gossip protocol，其實就是redis cluster采用的方案。簡單地說就是集群中每個節(jié)點會由于網(wǎng)絡(luò)分化、節(jié)點抖動等原因而具有不同的集群全局視圖。節(jié)點之間通過gossip protocol進行節(jié)點信息共享。這是業(yè)界比較流行的去中心化的方案。

·consensus system，這種方案跟上一種正相反，是依賴外部分布式一致性設(shè)施，由其仲裁來決定集群中各節(jié)點的身份。

·需求決定解決方案，小說君認(rèn)為，對于游戲服務(wù)端以及大多數(shù)應(yīng)用型后端情景，后兩者的成本太高，會增加很多不確定的復(fù)雜性，因此兩種方案都不是合適的選擇。 而且，大部分服務(wù)通常是可以在設(shè)計階段確定每個分片的容量上限的，也不需要太復(fù)雜的機制支持。

但是presharding的缺點也很明顯，做不到動態(tài)增容減容，而且無法高可用。不過其實只要稍加改造，就足以滿足需求了。

不過，在談具體的改造措施之前，我們先看之前提出的分片方案要解決的第二個問題—— work distribution 。

這個問題實際上是從另一種維度看分片，解決方案很多，但是如果從對架構(gòu)的影響上來看，大概分為兩種：

·一種是proxy-based，基于額外的轉(zhuǎn)發(fā)代理。例子有twemproxy/Codis。

·一種是client sharding，也就是dbClient（每個對數(shù)據(jù)服務(wù)有需求的服務(wù)）維護sharding規(guī)則，自助式選擇要去哪個redis實例。redis cluster本質(zhì)上就屬于這種，dblient側(cè)緩存了部分sharding信息。

第一種方案的缺點顯而易見——在整個架構(gòu)中增加了額外的間接層，流程中增加了一趟round-trip。如果是像twemproxy或者Codis這種支持高可用的還好，但是github上隨便一翻還能找到特別多的沒法做到高可用的proxy-based方案，無緣無故多個單點，這樣就完全搞不明白sharding的意義何在了。

第二種方案的缺點，小說君能想到的就是集群狀態(tài)發(fā)生變化的時候沒法即時通知到dbClient。

第一種方案，我們其實可以直接pass掉了。因為這種方案更適合私有云的情景，開發(fā)數(shù)據(jù)服務(wù)的部門有可能和業(yè)務(wù)部門相去甚遠(yuǎn)，因此需要統(tǒng)一的轉(zhuǎn)發(fā)代理服務(wù)。但是對于一些簡單的應(yīng)用開發(fā)情景，數(shù)據(jù)服務(wù)邏輯服務(wù)都是一幫人寫的，沒什么增加額外中間層的必要。

那么，看起來只能選擇第二種方案了。

將presharding與client sharding結(jié)合起來后，現(xiàn)在我們的成果是：數(shù)據(jù)服務(wù)是全局的，redis可以開多個實例，不相干的數(shù)據(jù)需要到不同的分片上存取，dbClient掌握這個映射關(guān)系。

不過目前的方案只能算是滿足了應(yīng)用對數(shù)據(jù)服務(wù)的基本需求。

游戲行業(yè)中，大部分采用redis的團隊，一般最終會選定這個方案作為自己的數(shù)據(jù)服務(wù)。后續(xù)的擴展其實對他們來說不是不可以做，但是可能有維護上的復(fù)雜性與不確定性。

但是作為一名有操守的程序員，小說君選擇繼續(xù)擴展。

現(xiàn)在的這個方案存在兩個問題：

·首先，雖然我們沒有支持在線數(shù)據(jù)遷移的必要，但是離線數(shù)據(jù)遷移是必須得有的，畢竟presharding做不到萬無一失。而在這個方案中，如果用單純的哈希算法，增加一個shard會導(dǎo)致原先的key到shard的對應(yīng)關(guān)系變得非常亂，抬高數(shù)據(jù)遷移成本。

·其次，分片方案固然可以將整個數(shù)據(jù)服務(wù)的崩潰風(fēng)險分散在不同shard中，比如相比于不分片的數(shù)據(jù)服務(wù)，一臺機器掛掉了，只影響到一部分client。但是，我們理應(yīng)可以對數(shù)據(jù)服務(wù)做更深入的擴展，讓其可用程度更強。

針對第一個問題，處理方式跟proxy-based采用的處理方式?jīng)]太大區(qū)別，由于目前的數(shù)據(jù)服務(wù)方案比較簡單，采用一致性哈希即可?；蛘卟捎靡环N比較簡單的兩段映射，第一段是靜態(tài)的固定哈希，第二段是動態(tài)的可配置map。前者通過算法，后者通過map配置維護的方式，都能最小化影響到的key集合。

而對于第二個問題，解決方案就是實現(xiàn)高可用。

如何讓數(shù)據(jù)服務(wù)高可用？在 討論這個問題之前，我們首先看redis如何實現(xiàn)「 可用性」。

對于redis來說，可用性的本質(zhì)是什么？其實就是redis實例掛掉之后可以有后備節(jié)點頂上。

redis通過兩種機制支持這一點。

第一種機制是replication。 通常的replication方案主要分為兩種。

·一種是active-passive，也就是active節(jié)點先修改自身狀態(tài)，然后寫統(tǒng)一持久化log，然后passive節(jié)點讀log跟進狀態(tài)。

·另一種是active-active，寫請求統(tǒng)一寫到持久化log，然后每個active節(jié)點自動同步log進度。

redis的replication方案采用的是一種一致性較弱的active-passive方案。也就是master自身維護log，將log向其他slave同步，master掛掉有可能導(dǎo)致部分log丟失，client寫完master即可收到成功返回，是一種異步replication。

這個機制只能解決節(jié)點數(shù)據(jù)冗余的問題，redis要具有可用性就還得解決redis實例掛掉讓備胎自動頂上的問題，畢竟由人肉去監(jiān)控master狀態(tài)再人肉切換是不現(xiàn)實的。 因此還需要第二種機制。

第二種機制是redis自帶的能夠自動化fail-over的redis sentinel。reds sentinel實際上是一種特殊的redis實例，其本身就是一種高可用服務(wù)——可以多開，可以自動服務(wù)發(fā)現(xiàn)（基于redis內(nèi)置的pub-sub支持，sentinel并沒有禁用掉pub-sub的command map），可以自主leader election（基于 raft算法 實現(xiàn)，作為 sentinel的一個模塊 ），然后在發(fā)現(xiàn)master掛掉時由leader發(fā)起fail-over，并將掉線后再上線的master降為新master的slave。

redis基于這兩種機制，已經(jīng)能夠?qū)崿F(xiàn)一定程度的可用性。

接下來，我們來看數(shù)據(jù)服務(wù)如何高可用。

數(shù)據(jù)服務(wù)具有可用性的本質(zhì)是什么？除了能實現(xiàn)redis可用性的需求——redis實例數(shù)據(jù)冗余、故障自動切換之外，還需要將切換的消息通知到每個dbClient。

也就是說把最開始的圖，改成下面這個樣子：