李 丹，葉廷東

(廣東輕工職業(yè)技術(shù)學(xué)院 信息技術(shù)學(xué)院, 廣州 510300)

0 引言

隨著人類進(jìn)入移動(dòng)互聯(lián)網(wǎng)(互聯(lián)網(wǎng)+)時(shí)代，新的業(yè)務(wù)形態(tài)層出不窮，應(yīng)用程序?qū)笈_(tái)性能的要求也越來越高。傳統(tǒng)的單機(jī)、單點(diǎn)、關(guān)系型數(shù)據(jù)庫(kù)早已不能滿足業(yè)界需要，因此很多公司把數(shù)據(jù)存儲(chǔ)在分布式NoSql數(shù)據(jù)庫(kù)中[1]。 最簡(jiǎn)單的分布式存儲(chǔ)，就是在單一機(jī)房，通過多服務(wù)器組成一個(gè)集群等模式來實(shí)現(xiàn)。

然而，為了更進(jìn)一步縮短用戶訪問時(shí)間，一般讓用戶就近接入，所以分布式后臺(tái)服務(wù)都跨機(jī)房部署，通過接入層的某種路由算法，可以把用戶請(qǐng)求分配到就近的機(jī)房。這樣可以大大縮短數(shù)據(jù)的傳輸距離，從而提升了用戶體驗(yàn)。

而且，異地部署可以有容災(zāi)的好處，如果整個(gè)大片區(qū)的網(wǎng)絡(luò)不通或者機(jī)房宕機(jī)，另外一個(gè)片區(qū)的機(jī)房可以無縫的接管所有的服務(wù)請(qǐng)求，從而提高整個(gè)后臺(tái)服務(wù)的可靠性[2]。

伴隨著后臺(tái)業(yè)務(wù)服務(wù)的跨機(jī)房部署，存儲(chǔ)也需要跨機(jī)房部署，怎么能使部署在不同機(jī)房存儲(chǔ)中的數(shù)據(jù)保持同步，且不影響分布式服務(wù)的可用性，是一項(xiàng)巨大的挑戰(zhàn)。本文從分布式系統(tǒng)的基礎(chǔ)理論入手，分析了分布式存儲(chǔ)的特性、應(yīng)用場(chǎng)景和技術(shù)挑戰(zhàn)，利用開源的Redis存儲(chǔ), RabbitMQ消息隊(duì)列等技術(shù)，搭建了一個(gè)滿足最終一致性，可用性和分區(qū)容忍性的“異地多活”分布式存儲(chǔ)系統(tǒng)。

1 異地多活的概念

異地多活數(shù)據(jù)中心是現(xiàn)在傳統(tǒng)大型數(shù)據(jù)中心的發(fā)展趨勢(shì)?！爱惖亍毕鄬?duì)于同城而言，一般不在同一城域；“多活”是區(qū)別于一個(gè)數(shù)據(jù)中心、多個(gè)災(zāi)備中心的模式，前者是多個(gè)數(shù)據(jù)中心都在運(yùn)行中，所以稱為“多活”， 且互為備份。后者是一個(gè)數(shù)據(jù)中心投入運(yùn)行，另外一個(gè)多個(gè)數(shù)據(jù)中心備份全量數(shù)據(jù)，平時(shí)處于不工作狀態(tài)，只有在主機(jī)房出現(xiàn)故障的時(shí)候才會(huì)切換到備用機(jī)房。冷備份的主要問題是成本高，不跑業(yè)務(wù)，當(dāng)主機(jī)房出問題的時(shí)候，也不一定能成功把業(yè)務(wù)接管過來[3]。

異地多活主要有如下好處[4]：

1)服務(wù)端離用戶更近，接入層可以把用戶請(qǐng)求路由到離用戶最近的機(jī)房，減少了網(wǎng)絡(luò)傳輸距離，大大提升了用戶訪問性能和體驗(yàn)。

2)異地快速容災(zāi)：如果整個(gè)機(jī)房(比如整個(gè)大區(qū))掛掉或者網(wǎng)絡(luò)癱瘓，另外一個(gè)異地機(jī)房能無縫單獨(dú)提供服務(wù)，用戶完全無感知，大大提高了服務(wù)的可靠性。

2 分布式系統(tǒng)的CAP理論

在分布式的環(huán)境下，設(shè)計(jì)和部署系統(tǒng)時(shí)主要考慮下述3個(gè)重要的核心系統(tǒng)需求。

1)一致性(Consistency)：所有節(jié)點(diǎn)在同一時(shí)間具有相同的數(shù)據(jù)。

2)可用性(Availability)：保證對(duì)每個(gè)請(qǐng)求的成功或者失敗都有響應(yīng)。

3)分區(qū)容錯(cuò)性(Partition Tolerance)：分布式系統(tǒng)在遇到某節(jié)點(diǎn)或網(wǎng)絡(luò)分區(qū)故障的時(shí)候，仍然能夠?qū)ν馓峁M足一致性或可用性的服務(wù)。

上述3 個(gè)重要的核心系統(tǒng)需求又簡(jiǎn)稱為 CAP需求[5]，在理論計(jì)算機(jī)科學(xué)中，CAP定理(CAP theorem)，又被稱作布魯爾定理(Brewer’s theorem)，它指出對(duì)于一個(gè)分布式計(jì)算系統(tǒng)來說，不可能同時(shí)滿足以上三點(diǎn)， 如圖1所示，三個(gè)核心系統(tǒng)特性沒有交疊的區(qū)域。即在構(gòu)建分布式系統(tǒng)的時(shí)候，一致性，可用性，分區(qū)容忍性，這三者只可以同時(shí)選擇兩樣[6]。

圖1 CAP理論分布式系統(tǒng)的三特性

不幸的是，分區(qū)容錯(cuò)性是實(shí)際運(yùn)營(yíng)的分布式系統(tǒng)所必需的。設(shè)想下，誰能保證系統(tǒng)的各節(jié)點(diǎn)永遠(yuǎn)保持網(wǎng)絡(luò)聯(lián)通？一旦網(wǎng)絡(luò)出現(xiàn)丟包，系統(tǒng)就不可用。而保證分區(qū)容錯(cuò)性最基本的要求是數(shù)據(jù)要跨數(shù)據(jù)中心存儲(chǔ)。所以需要在一致性和可用性中二選其一。

為什么強(qiáng)一致性和高可用性不能同時(shí)滿足？ 假如需要滿足強(qiáng)一致性，就需要寫入一條數(shù)據(jù)的時(shí)候，擴(kuò)散到分布式系統(tǒng)里面的每一臺(tái)機(jī)器，每一臺(tái)機(jī)器都回復(fù)ACK確認(rèn)后再給客戶端確認(rèn)，這就是強(qiáng)一致性。如果集群任何一臺(tái)機(jī)器故障了，都回滾數(shù)據(jù)，對(duì)客戶端返回失敗，因此影響了可用性。如果只滿足高可用性，任何一臺(tái)機(jī)器寫入成功都返回成功，那么有可能中途因?yàn)榫W(wǎng)絡(luò)抖動(dòng)或者其他原因造成了數(shù)據(jù)不同步，部分客戶端獨(dú)到的仍然是舊數(shù)據(jù)，因此，無法滿足強(qiáng)一致性。

選擇一致性，構(gòu)建的就是強(qiáng)一致性系統(tǒng)，比如符合ACID特性的數(shù)據(jù)庫(kù)系統(tǒng)。選擇可用性，構(gòu)建的就是最終一致性系統(tǒng)。前者的特點(diǎn)是數(shù)據(jù)落地即是一致的，但是可用性不能時(shí)時(shí)保證，這意思就是，有時(shí)系統(tǒng)在忙著保證一致性，無法對(duì)外界服務(wù)。后者的特點(diǎn)是時(shí)時(shí)刻刻都保證可用性，用戶隨時(shí)都可以訪問，但是各個(gè)節(jié)點(diǎn)之間會(huì)存在不一致的時(shí)刻。

需要注意的是最終一致性的系統(tǒng)不是不保證一致性，而是不在保證可用性和分區(qū)容錯(cuò)性的同時(shí)保證一致性。最終我們還是要在最終一致性的各節(jié)點(diǎn)之間處理數(shù)據(jù)，使他們達(dá)到一致[7]。

3 異地多活分布式存儲(chǔ)系統(tǒng)的挑戰(zhàn)

眾所周知，如果數(shù)據(jù)只是保存在單一節(jié)點(diǎn)，就沒有一致性的問題；但是單機(jī)房存儲(chǔ)連最基本的“分區(qū)容忍性”就保證不了。而對(duì)于“異地多活”系統(tǒng)而言，數(shù)據(jù)必然是跨數(shù)據(jù)中心存儲(chǔ)的。保存在異地機(jī)房NoSql數(shù)據(jù)庫(kù)中的數(shù)據(jù)要做到可用、并且盡可能一致，因?yàn)槔碚撋?，任何一個(gè)機(jī)房在任何時(shí)刻要給每一個(gè)用戶提供服務(wù)，這就給分布式存儲(chǔ)系統(tǒng)帶來如下挑戰(zhàn)[8]：

1)網(wǎng)絡(luò)延遲&丟包:異地多活系統(tǒng)由于要跨數(shù)據(jù)中心存儲(chǔ), 而跨數(shù)據(jù)中心的路途遙遠(yuǎn)導(dǎo)致的弱網(wǎng)絡(luò)質(zhì)量，數(shù)據(jù)同步是非常大的挑戰(zhàn)；

2)一致性:用戶可能幾乎同時(shí)在兩個(gè)機(jī)房寫入數(shù)據(jù)，怎么保寫入的數(shù)據(jù)不沖突并一致。

4 異地多活分布式存儲(chǔ)系統(tǒng)的設(shè)計(jì)

鑒于異地多活系統(tǒng)的上述挑戰(zhàn)，及分布式系統(tǒng)的CAP定理，本文設(shè)計(jì)的分布式存儲(chǔ)系統(tǒng)滿足了分區(qū)容錯(cuò)性和可用性，實(shí)現(xiàn)了最終一致性。

滿足分區(qū)容錯(cuò)性，分布式數(shù)據(jù)在異地存儲(chǔ)，任何一個(gè)機(jī)房掛掉或者跨區(qū)域網(wǎng)絡(luò)不通，單機(jī)房可以立即提供服務(wù)。 對(duì)分區(qū)錯(cuò)誤的容忍性可以達(dá)到100%。

滿足可用性，分布式存儲(chǔ)本地機(jī)房寫成功后就返回給用戶，不等待遠(yuǎn)端機(jī)房是否寫成功。

為了滿足最終一致性，引入消息中間件進(jìn)行多地域數(shù)據(jù)分發(fā)，消息中間件可以確保消息不丟失[9]。并對(duì)寫入的數(shù)據(jù)附上時(shí)間戳，通過時(shí)間戳的記錄和比較機(jī)制，確保兩邊同時(shí)寫入的數(shù)據(jù)不沖突。同時(shí)，引入一致性校驗(yàn)和補(bǔ)償機(jī)制，數(shù)據(jù)最終一致性得到進(jìn)一步的保證。

4.1 系統(tǒng)框架

如圖2 所示，在性能方面，由于redis的卓越表現(xiàn)，選擇redis作為數(shù)據(jù)的承載[10]，在一個(gè)機(jī)房中部署多個(gè)redis，組成一個(gè)集群，滿足一個(gè)機(jī)房對(duì)數(shù)據(jù)的讀寫需求。為了解耦業(yè)務(wù)層和存儲(chǔ)redis，在redis之上引入一個(gè)proxy層，業(yè)務(wù)通過proxy，按一定的hash策略訪問redis[11]。對(duì)于多機(jī)房分布高可用方面的需求，在proxy層實(shí)現(xiàn)數(shù)據(jù)在多機(jī)房間的互相同步機(jī)制，提供最終一致性。在多機(jī)房網(wǎng)絡(luò)通信方面，數(shù)據(jù)同步以消息的形式發(fā)送。為了保證不丟消息，本文選擇用RabbitMQ作為中間件發(fā)送。

圖2 系統(tǒng)架構(gòu)圖

4.2 實(shí)現(xiàn)方案

4.2.1 引入中間代理層redisProxy節(jié)點(diǎn)

業(yè)務(wù)進(jìn)程通過redisProxy讀寫本地redis。redisProxy對(duì)key進(jìn)行hash，訪問其對(duì)應(yīng)的redis。同時(shí)，redisProxy節(jié)點(diǎn)做到無狀態(tài)，按組管理，一個(gè)組內(nèi)部署多個(gè)redisProxy，組成集群。集群內(nèi)的redisProxy可以方便地水平擴(kuò)展，業(yè)務(wù)系統(tǒng)無感知。

業(yè)務(wù)進(jìn)程通過配置文件指定需要訪問哪個(gè)組的redisProxy。另外，redisProxy節(jié)點(diǎn)也對(duì)redis的讀寫情況、訪問質(zhì)量等做統(tǒng)計(jì)和監(jiān)控。

4.2.2 寫沖突問題的解決機(jī)制

本設(shè)計(jì)支持對(duì)數(shù)據(jù)的put(寫覆蓋)操作，而支持對(duì)數(shù)據(jù)的寫覆蓋，必然帶來寫沖突的問題，即兩個(gè)機(jī)房同時(shí)對(duì)同一個(gè)Key寫入數(shù)據(jù)，因?yàn)闀r(shí)序問題，兩個(gè)機(jī)房最終呈現(xiàn)的結(jié)果可能不一致。為了解決此問題，我們對(duì)存儲(chǔ)在系統(tǒng)中的key，維護(hù)一份元數(shù)據(jù)，目前維護(hù)的有key的版本，即key寫操作的時(shí)間戳[13]。對(duì)key的寫操作(插入、更新、刪除)，需要將操作發(fā)生的時(shí)間和本地記錄的key對(duì)應(yīng)的時(shí)間戳版本做比較，比版本更新(更晚)的操作將被執(zhí)行，更舊(更早)的操作將被丟棄。

Redis支持的數(shù)據(jù)類型比較豐富。除了最基本的string類型，通過上述方法，能夠直接支持外，對(duì)set、sorted set、hash結(jié)構(gòu)，通過做一些轉(zhuǎn)換，也能夠支持。轉(zhuǎn)換方式如下：為set、sorted set、hash結(jié)構(gòu)中存儲(chǔ)的每個(gè)成員維護(hù)一份時(shí)間戳版本，對(duì)key做寫操作時(shí)，需要對(duì)操作涉及的每個(gè)成員做時(shí)間戳比較，以決定是執(zhí)行還是放棄?；跁r(shí)間戳版本的寫操作流程如圖3所示。

圖3 寫操作流程圖

時(shí)間戳機(jī)制能夠工作的一個(gè)前提是服務(wù)器之間同步系統(tǒng)時(shí)間。一般線上服務(wù)器都有同步系統(tǒng)時(shí)間，機(jī)器之間系統(tǒng)時(shí)間誤差一般不超過1 s，為毫秒(ms)級(jí)別。這個(gè)能滿足互聯(lián)網(wǎng)生產(chǎn)環(huán)境對(duì)存儲(chǔ)系統(tǒng)最終一致性的要求。同時(shí)，為了減少時(shí)間沖突，對(duì)一個(gè)key的讀寫，我們hash到一臺(tái)機(jī)器上執(zhí)行。

4.2.3 引入第三方消息隊(duì)列，增強(qiáng)同步消息傳遞的可靠性

redisProxy需要保證帶有時(shí)間戳的寫操作能夠同步到其他組。為了增加同步消息的可靠性，本設(shè)計(jì)通過引入一個(gè)第三方隊(duì)列來滿足對(duì)同步的可靠性要求。RabbitMQ是我們本文選定的方案， RabbitMQ實(shí)現(xiàn)了高級(jí)消息隊(duì)列協(xié)議(AMQP)，RabbitMQ消息中間件有著完善的可靠性機(jī)制并且使用方便[14]。通過RabbitMQ對(duì)同步消息的持久化、集群部署及mirrored queue等機(jī)制，實(shí)現(xiàn)寫操作的可靠同步。

4.2.4 平滑的升級(jí)擴(kuò)容機(jī)制

為實(shí)現(xiàn)升級(jí)擴(kuò)容時(shí)部署一個(gè)新的組，我們利用redis的主從同步獲取‘舊’的最近未更新的數(shù)據(jù)，利用RabbitMQ的同步獲取‘新’的最近變化的操作。通過兩者的結(jié)合，使新組的數(shù)據(jù)與已有組一致。

4.3 系統(tǒng)節(jié)點(diǎn)

4.3.1 業(yè)務(wù)節(jié)點(diǎn)(redis client)

App業(yè)務(wù)進(jìn)程，由配置文件指定通過哪個(gè)組的redisProxy訪問存儲(chǔ)系統(tǒng)。對(duì)redisProxy的訪問，通過輪詢的方式來均衡負(fù)載。為了接口使用方便友好，redis client提供類似于redis的接口。

4.3.2 redisProxy

訪問代理層，負(fù)責(zé)對(duì)redis讀寫訪問。對(duì)外提供網(wǎng)絡(luò)協(xié)議接口訪問存儲(chǔ)系統(tǒng)。底層存儲(chǔ)用redis，將數(shù)據(jù)存在內(nèi)存中。內(nèi)部對(duì)數(shù)據(jù)按key進(jìn)行hash分片，每片存儲(chǔ)在一個(gè)redis中。寫操作帶上時(shí)間戳，通過RabbitMQ同步到其他組。寫操作成功發(fā)送到RabbitMQ即認(rèn)為同步成功，返回。因此，狀態(tài)系統(tǒng)各集群間實(shí)現(xiàn)的是最終一致性。

4.3.3 RabbitMQ

第三方消息隊(duì)列，負(fù)責(zé)將redisProxy的寫操作可靠地同步到其他組。通過配置，將同步隊(duì)列持久化，防止RabbitMQ重啟后消息丟失[15]。一套狀態(tài)系統(tǒng)內(nèi)，部署多個(gè)RabbitMQ，組成集群，防止RabbitMQ單點(diǎn)失敗。配置mirrored queue，使同步隊(duì)列在集群中有多個(gè)鏡像，進(jìn)一步提高可靠性。

4.3.4 redis

類型的數(shù)據(jù)存儲(chǔ)節(jié)點(diǎn)。數(shù)據(jù)不持久化，只存在內(nèi)存中。為配合數(shù)據(jù)分布，一個(gè)集群中部署多個(gè)redis節(jié)點(diǎn)。

4.4 交互流程

4.4.1 讀數(shù)據(jù)流程

讀數(shù)據(jù)流程如圖4所示。

圖4 讀數(shù)據(jù)流程圖

1)業(yè)務(wù)節(jié)點(diǎn)發(fā)消息給RedisProxy節(jié)點(diǎn)，此消息是基于TCP的網(wǎng)絡(luò)消息，由業(yè)務(wù)自定義。

2)RedisProxy節(jié)點(diǎn)收到業(yè)務(wù)讀請(qǐng)求后，按照Key Hash到某個(gè)Redis本地分片。

3)執(zhí)行標(biāo)準(zhǔn)的Redis命令，從本地redis讀取數(shù)據(jù)。

4)標(biāo)準(zhǔn)Redis命令的回包。

5)業(yè)務(wù)收到Redis命令的回復(fù)后，返回給業(yè)務(wù)節(jié)點(diǎn)一個(gè)回包(此回包也是由業(yè)務(wù)定義的基于TCP的網(wǎng)絡(luò)消息)

4.4.2 寫數(shù)據(jù)流程

寫數(shù)據(jù)流程如圖5所示。

圖5 寫數(shù)據(jù)時(shí)序圖

1)業(yè)務(wù)節(jié)點(diǎn)發(fā)消息給RedisProxy節(jié)點(diǎn)，此消息是基于TCP的網(wǎng)絡(luò)消息，由業(yè)務(wù)自定義。

2)RedisProxy把寫操作請(qǐng)求同步給RabbitMQ;

3)RedisProxy節(jié)點(diǎn)收到業(yè)務(wù)讀請(qǐng)求后，按照Key Hash到某個(gè)Redis本地分片。

4)步驟4.1、4.2、4.3、4.4為一個(gè)事務(wù)操作，通過比較操作的時(shí)間戳和本地保存的時(shí)間戳來決定是否執(zhí)行本次操作，以避免寫沖突，確保兩邊數(shù)據(jù)一致。

4.4.3 同步遠(yuǎn)端數(shù)據(jù)流

同步遠(yuǎn)端數(shù)據(jù)流如圖6所示。

1)本地RabbitMQ從遠(yuǎn)端RabbitMQ收到寫同步消息；

2)推送同步消息到本機(jī)房的RedisProxy節(jié)點(diǎn)；

3)RedisProxy節(jié)點(diǎn)處理推送過來的寫請(qǐng)求，按key Hash到某個(gè)本地Redis分片(步驟3.1)； 步驟3.2、3.3、3.4、3.5是一個(gè)事務(wù)操作，通過比較操作的時(shí)間戳和本地保存的時(shí)間戳大小來決定是否執(zhí)行本次操作，以避免寫沖突，確保兩邊數(shù)據(jù)一致。

圖6 同步遠(yuǎn)端數(shù)據(jù)

4.5 容災(zāi)設(shè)計(jì)

4.5.1 redisProxy服務(wù)器宕機(jī)

redisProxy多臺(tái)機(jī)集群化部署提高可用性。如果某臺(tái)服務(wù)器宕機(jī)，其redisProxy服務(wù)器可以繼續(xù)提供服務(wù)。

4.5.2 RabbitMQ服務(wù)器宕機(jī)

同步消息隊(duì)列持久化，同時(shí)RabbitMQ在多臺(tái)機(jī)集群化部署，同步消息在集群中有多個(gè)鏡像。如果某臺(tái)服務(wù)器宕機(jī)，集群中的其他RabbitMQ可以繼續(xù)提供服務(wù)。宕機(jī)恢復(fù)后的RabbitMQ，追趕上其他RabbitMQ后可以繼續(xù)提供服務(wù)。

4.5.3 Redis服務(wù)器宕機(jī)

當(dāng)做整個(gè)集群不可用，切換到另一個(gè)狀態(tài)系統(tǒng)集群。當(dāng)機(jī)器恢復(fù)后，按升級(jí)擴(kuò)容的策略對(duì)待，重新部署該組狀態(tài)系統(tǒng)。等追趕上其他集群后，可開始對(duì)外提供服務(wù)，將業(yè)務(wù)流量切換到本集群。

4.5.4 集群機(jī)房網(wǎng)絡(luò)不可用

切換業(yè)務(wù)流量到其他集群，繼續(xù)提供服務(wù)。等機(jī)房恢復(fù)后，通過RabbitMQ獲取其他集群中存儲(chǔ)著的同步消息，本地回放，追趕數(shù)據(jù)。同步隊(duì)列處理完，即已追趕上其他集群，此時(shí)可將業(yè)務(wù)流量切換回，對(duì)外提供服務(wù)。

4.6 升級(jí)擴(kuò)容

如圖7所示，升級(jí)擴(kuò)容的步驟如下：

1)在新機(jī)房部署redis從庫(kù)，同步現(xiàn)有機(jī)房的數(shù)據(jù)。

2)在新機(jī)房部署RabbitMQ，同步并存儲(chǔ)更新操作。

3) 在redis主庫(kù)中寫入一測(cè)試數(shù)據(jù)，測(cè)試從庫(kù)是否同步上。

4) 第三步中的測(cè)試數(shù)據(jù)，如果已同步到從庫(kù)，將從庫(kù)提升為主庫(kù)，同時(shí)啟動(dòng)redisProxy，開始回放RabbitMQ中的同步消息。

圖7 回放同步消息

4.7 一致性校驗(yàn)和補(bǔ)償

通過腳本，定期隨機(jī)抽取一批key，比較在各集群之間的數(shù)據(jù)是否一致。如發(fā)現(xiàn)不一致，人工介入校正，根據(jù)業(yè)務(wù)特性做一致性補(bǔ)償?shù)却胧?/p>

5 模擬性能測(cè)試

用C++編寫模擬測(cè)試代碼訪問redisProxy對(duì)系統(tǒng)進(jìn)行性能測(cè)試，跨機(jī)房部署，分別從兩個(gè)機(jī)房對(duì)多個(gè)key進(jìn)行讀寫。用Redis-set、Redis-get 分別表示Redis寫、Redis讀命令。 通過代碼分別統(tǒng)計(jì)出redisProxy的平均處理時(shí)延， 吞吐量，和數(shù)據(jù)一致性時(shí)延等指標(biāo)。

環(huán)境搭建：異地兩個(gè)機(jī)房 RedisProxy部署在單臺(tái)服務(wù)器，CPU: E5-2620/2.10 GHz,內(nèi)存: 32G, 操作系統(tǒng) ubuntu 12.04。異地兩個(gè)機(jī)房，分別部署4個(gè)Redis 實(shí)例，Key-Value 通過鍵名hash到不同的redis實(shí)例。

實(shí)驗(yàn)1：測(cè)試系統(tǒng)的吞吐量和系統(tǒng)處理時(shí)延。

分別以每秒1個(gè)、 100個(gè)、 1 000個(gè)， 5 000個(gè)、10 000個(gè)讀寫不同的key請(qǐng)求， 逐步增大系統(tǒng)的請(qǐng)求數(shù)， 觀察系統(tǒng)的CPU指標(biāo)和系統(tǒng)延時(shí)。

結(jié)果分析: 如圖8和圖9所示，系統(tǒng)時(shí)延和CPU隨著請(qǐng)求數(shù)增加而緩慢增加。 當(dāng)請(qǐng)求數(shù)接近達(dá)到1萬/秒時(shí)，系統(tǒng)延時(shí)和CPU利用率明顯增大，所以單redisProxy進(jìn)程部署的QPS接近1萬。

圖8 系統(tǒng)處理時(shí)延與請(qǐng)求數(shù)的關(guān)系

圖9 CPU利用率與請(qǐng)求數(shù)的關(guān)系

實(shí)驗(yàn)2：在保持系統(tǒng)80% QPS情況下，對(duì)某一個(gè)key反復(fù)進(jìn)行寫操作，寫完之后分別在兩個(gè)機(jī)房實(shí)時(shí)讀，記錄兩個(gè)機(jī)房不同數(shù)據(jù)結(jié)構(gòu)數(shù)據(jù)一致的平均時(shí)間差。

結(jié)果分析：如圖10所示，實(shí)驗(yàn)結(jié)果可以看出，不同數(shù)據(jù)結(jié)構(gòu)的數(shù)據(jù)同步時(shí)間有略微差別，但是都在1s以內(nèi)，可以滿足工業(yè)級(jí)數(shù)據(jù)同步要求。

圖10 系統(tǒng)一致性時(shí)間

6 結(jié)束語

跨機(jī)房的存儲(chǔ)設(shè)計(jì)是業(yè)界的難點(diǎn)，根據(jù)CAP理論，根本做不到同時(shí)滿足一致性要求和可用性的系統(tǒng)。本文根據(jù)分布式存儲(chǔ)應(yīng)用的特點(diǎn)，選擇了滿足可用性和最終一致性。 通過多機(jī)集群，異地部署等保證可用性；通過開源的可靠消息隊(duì)列技術(shù)和定時(shí)一致性校驗(yàn)&補(bǔ)償技術(shù)來確保最終一致性。經(jīng)過壓測(cè)，系統(tǒng)基本能滿足工業(yè)級(jí)互聯(lián)網(wǎng)應(yīng)用吞吐量和可用性的要求。 NoSql技術(shù)、Web應(yīng)用的規(guī)模和使用模式的發(fā)展，為分布式存儲(chǔ)和相關(guān)領(lǐng)域的發(fā)展帶來了新的契機(jī)。近年來，業(yè)界開始研究CRDT(Conflict-Free Replicated Data Type)數(shù)據(jù)結(jié)構(gòu)，CRDT是各種基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)最終一致算法的理論總結(jié)，能根據(jù)一定的規(guī)則自動(dòng)合并，解決沖突，達(dá)到強(qiáng)最終一致的效果[16]。這可以作為本課題的以后研究方向。