我們?cè)陂_發(fā)社交App后臺(tái)架構(gòu)的初期，一般采用單臺(tái)緩存的架構(gòu)，隨著業(yè)務(wù)的發(fā)展，單緩存的架構(gòu)會(huì)受到單機(jī)內(nèi)存限制。在大型的社交App中，雖然沒必要把所有的數(shù)據(jù)都放入緩存，但為了保證核心緩存（保存了用戶最近的內(nèi)容）的命中率達(dá)到99%，也需要大量的緩存。單臺(tái)服務(wù)器顯然沒法滿足緩存所有數(shù)據(jù)的要求。針對(duì)這個(gè)問題，深圳APP開發(fā)公司總結(jié)出以下解決方案：
1.布式緩存解決法
為了解決單機(jī)內(nèi)存受限的問題，社交App后臺(tái)引入了分布式緩存的架構(gòu)，如圖9- 24所示。
社交APP開發(fā)聊天功能升級(jí)解決方案示意圖9-24分布式緩存的架構(gòu)
后臺(tái)使用了分布式緩存后，每臺(tái)緩存服務(wù)器緩存總數(shù)據(jù)量的部分，這時(shí)要解決兩個(gè)問題
·后臺(tái)中有多臺(tái)緩存服務(wù)器，怎么確定某個(gè)數(shù)據(jù)緩存在哪臺(tái)緩存服務(wù)器？
·怎樣才能讓數(shù)據(jù)均衡地分布到緩存服務(wù)器上，以免造成有的緩存服務(wù)器緩存的數(shù)據(jù)多，有的緩存服務(wù)器緩存的數(shù)據(jù)少？
上面兩個(gè)問題可用余數(shù)hash的方案解決：用服務(wù)器的數(shù)量除以緩存數(shù)據(jù)的Key的hash值，余數(shù)為對(duì)應(yīng)的緩存服務(wù)器的下標(biāo)編號(hào)0例如，對(duì)于Key為“jeff”的數(shù)據(jù)．hash值（Java的hashCode返回值）為3258171，用服務(wù)器數(shù)目3除以該值，得到余數(shù)0，因此該數(shù)據(jù)存儲(chǔ)在“緩存服務(wù)器O”。
余數(shù)hash最大的缺點(diǎn)是當(dāng)增加、減少緩存服務(wù)器時(shí)，會(huì)造成緩存服務(wù)器結(jié)果的大震蕩。例如，緩存服務(wù)器從3臺(tái)變成了4臺(tái)，對(duì)于Key為“jeff”的數(shù)據(jù)，hash值(Java的hashCode返回值)為3258171，用服務(wù)器數(shù)目4除以該值，得到余數(shù)3，因此把數(shù)據(jù)從存儲(chǔ)在“緩存服務(wù)器0”變?yōu)榇鎯?chǔ)在“緩存服務(wù)器3”，如圖9-25所示。
社交APP開發(fā)聊天功能緩存升級(jí)方案示意圖9-25 Key為"jeff”的數(shù)據(jù)命中緩存服務(wù)器的不同情況
我們APP開發(fā)愛好者可以計(jì)算出來，當(dāng)緩存服務(wù)器的數(shù)目從3臺(tái)升到4臺(tái)，大約有75% (3/4)被緩存的數(shù)據(jù)不能命中緩存服務(wù)器，隨著服務(wù)器集群規(guī)模的增大，這個(gè)比值會(huì)不斷加大，整體的命中率下降得非?？?。
在App后臺(tái)中，大部分業(yè)務(wù)請(qǐng)求所需的數(shù)據(jù)是通過緩存獲取的，只有少部分請(qǐng)求會(huì)穿透到數(shù)據(jù)庫，因此數(shù)據(jù)庫的負(fù)載能力是按照緩存承擔(dān)了大部分請(qǐng)求的情況設(shè)計(jì)。當(dāng)因?yàn)樵黾泳彺娣?wù)器造成緩存沒法命中，大量的業(yè)務(wù)請(qǐng)求穿透到數(shù)據(jù)庫會(huì)造成數(shù)據(jù)庫的壓力過大，甚至造成數(shù)據(jù)庫宕機(jī)，從而使業(yè)務(wù)癱瘓，這個(gè)結(jié)果顯然是不能接受的。
為了使新增緩存服務(wù)器不至于影響大部分緩存的命中率，需要使用“一致性hash算法”這種更合理的hash算法。
一致性哈希算法是1997年由麻省理工學(xué)院提出的種分布式哈希(DHT)實(shí)現(xiàn)算法。其基本原理是構(gòu)造個(gè)長度為0—4294967296的圓環(huán)（稱為一致性hash環(huán)），根據(jù)緩存服務(wù)器名稱的hash值(分布范圍是。-4294967296)把緩存服務(wù)器放置在這個(gè)hash環(huán)上。當(dāng)緩存的請(qǐng)求到達(dá)，根據(jù)緩存數(shù)據(jù)的Key計(jì)算得到其hash值(分布范圍同樣是0-4294967296)，根據(jù)這個(gè)hash值判斷緩存數(shù)據(jù)是否命中緩存服務(wù)器，如果沒有命中緩存服務(wù)器，則順時(shí)針在hash環(huán)上查找距離這個(gè)Key的hash值最近的緩存服務(wù)器。
APP開發(fā)公司下面舉個(gè)例子說明一致性哈希算法的工作流程。在一致性哈希環(huán)下，存在3臺(tái)緩存服務(wù)器的情況，Key值是“jeff”的數(shù)據(jù)命中緩存服務(wù)器的情況如圖9-26所示。
按照一致性哈希算法（順時(shí)針查找的特性），在只有3臺(tái)緩存服務(wù)器的時(shí)候．hash值范圍是(3294967296 - 4294967296，0～1294967296)的Key都會(huì)命中緩存服務(wù)器0。
當(dāng)緩存服務(wù)器從3臺(tái)加至4臺(tái)，Key值是“jeff”的數(shù)據(jù)命中緩存服務(wù)器的情況如圖9-27所示。
社交APP開發(fā)升級(jí)示意圖9-27增加緩存服務(wù)器后的一致性啥希環(huán)
當(dāng)增加了一臺(tái)緩存服務(wù)器4(11ash值是1094967296)后，hash值范圍是3294967296- 4294967296，0--1094967296)的Key會(huì)命中緩存服
務(wù)器4．hash值范圍是1094967297'-1294967296的Key會(huì)命中緩存服務(wù)器0。因此可看出，在使用一致性哈希算法的情況下，增加了一臺(tái)緩存服務(wù)器后命中率受影響的Key只有[(4294967296-3294967296)+(1094967296-0)]／4294967296=0. 2549=25.49%．這個(gè)數(shù)值比起之前余數(shù)hash75%的值少多了。
但一致性哈希算法還有問題：新增了臺(tái)緩存服務(wù)器4后，原來落在緩存服務(wù)器。的請(qǐng)求現(xiàn)在由緩存服務(wù)器4和緩存服務(wù)器。共同承擔(dān)，但落在緩存服務(wù)器3和緩存服務(wù)器2上的請(qǐng)求不變，這就意味著緩存服務(wù)器3和緩存服務(wù)器2緩存的數(shù)據(jù)量和負(fù)載壓力比起緩存服務(wù)器4和緩存服務(wù)器0重多了。如果4臺(tái)緩存服務(wù)器的配置都是一樣，那么這個(gè)結(jié)果是不理想的，沒法充分利用每臺(tái)緩存服務(wù)器。
該問題可以通過引入虛擬節(jié)點(diǎn)解決。在上面的例子中，一臺(tái)緩存服務(wù)器只對(duì)應(yīng)一個(gè)hash值，如果杷臺(tái)緩存服務(wù)器對(duì)應(yīng)兩個(gè)hash值(一個(gè)真實(shí)節(jié)點(diǎn)，一個(gè)虛擬節(jié)點(diǎn))，甚至是多個(gè)hash值（多個(gè)虛擬節(jié)點(diǎn)）呢？這樣新加入臺(tái)緩存服務(wù)器，將會(huì)均勻地影響已經(jīng)存在的緩存服務(wù)器并分?jǐn)傇瓉矸?wù)器集群中的負(fù)載。新的一致性哈希算法環(huán)如圖9-28所示。
好了，APP開發(fā)公司本文關(guān)于我們?cè)谏缃籄PP升級(jí)開發(fā)時(shí)的解決方案就分享到這里，希望能給你的APP開發(fā)工作帶來幫助，謝謝關(guān)注，博納網(wǎng)絡(luò)編輯整理。
