如何在云計(jì)算平臺(tái)中構(gòu)建大規(guī)模分布式系統(tǒng)

本篇文章為大家展示了如何在云計(jì)算平臺(tái)中構(gòu)建大規(guī)模分布式系統(tǒng)，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

如何利用云計(jì)算平臺(tái)的彈性，結(jié)合業(yè)務(wù)自身特點(diǎn)，設(shè)計(jì)和構(gòu)建一個(gè)高可用、高伸縮性的后端系統(tǒng)架構(gòu)。同時(shí)會(huì)以 QingCloud 平臺(tái)上的真實(shí)案例為背景，講述從簡(jiǎn)單后端系統(tǒng)到大規(guī)模分布式系統(tǒng)的演進(jìn)之路。

很多企業(yè)和開發(fā)者在開發(fā)一款產(chǎn)品時(shí)，首要考慮的是產(chǎn)品功能的實(shí)現(xiàn)，其后端架構(gòu)通常都是非常簡(jiǎn)單直接的。產(chǎn)品在剛上線初期，由于用戶訪問壓力很小，數(shù)據(jù)量積累也并不大，在短時(shí)間內(nèi)都會(huì)運(yùn)行良好。

然而如今移動(dòng)互聯(lián)網(wǎng)的普及和成熟，讓一款產(chǎn)品很可能在短時(shí)間內(nèi)聚集大量用戶，面對(duì)流量激增、數(shù)據(jù)量翻番、訪問量指數(shù)級(jí)攀升等諸多“煩惱”，這本來(lái)是一件好事，可是如果后端系統(tǒng)不能及時(shí)擴(kuò)展，勢(shì)必會(huì)造成響應(yīng)緩慢，頻繁出錯(cuò)甚至拒絕服務(wù)的情況。

即便沒有上述系統(tǒng)壓力突然增大的“煩惱”，產(chǎn)品在不斷開發(fā)升級(jí)的過程中，各種功能模塊會(huì)變的越來(lái)越復(fù)雜，如果不能很好的梳理和組織后端架構(gòu)，系統(tǒng)出錯(cuò)崩潰、不可使用的風(fēng)險(xiǎn)也會(huì)越來(lái)越大。

在沒有云計(jì)算的時(shí)代，物理硬件從采購(gòu)、上架、插線，到安裝、調(diào)試、部署，再到真正投入使用，是一個(gè)漫長(zhǎng)而耗費(fèi)人力的過程，往往跟不上系統(tǒng)緊急擴(kuò)容的節(jié)奏。而云服務(wù)的出現(xiàn)不僅僅讓我們節(jié)約了使用成本，更重要的是可以利用云計(jì)算極度彈性的特點(diǎn)，讓企業(yè)和開發(fā)者根據(jù)需求，對(duì)系統(tǒng)進(jìn)行在線快速的擴(kuò)容。

但僅僅在云服務(wù)上快速擴(kuò)容是不夠的，企業(yè)也需要在業(yè)務(wù)層面，關(guān)注各個(gè)系統(tǒng)組件的可用性和伸縮性。接下來(lái)我來(lái)給大家介紹如果利用云計(jì)算的優(yōu)勢(shì)，結(jié)合企業(yè)的業(yè)務(wù)特點(diǎn)構(gòu)建穩(wěn)定可靠的分布式系統(tǒng)。

首先我們從一個(gè)最簡(jiǎn)單的后端架構(gòu)開始：

接入層：nginx 業(yè)務(wù)層：Java application 數(shù)據(jù)層：MySQL

在云計(jì)算環(huán)境中，網(wǎng)絡(luò)架構(gòu)的組織非常重要，QingCloud 提供了基礎(chǔ)網(wǎng)絡(luò)和 VPC 兩種網(wǎng)絡(luò)，他們的區(qū)別在官網(wǎng)用戶指南和以前的文章中已經(jīng)介紹，這里不贅述。推薦企業(yè)使用 VPC 來(lái)構(gòu)建自己的網(wǎng)絡(luò)，將所有主機(jī)和系統(tǒng)資源放置在 VPC 網(wǎng)絡(luò)中，指定內(nèi)網(wǎng)網(wǎng)段（如 192.168.x.x / 172.16.x.x），主機(jī)可以通過內(nèi)網(wǎng)地址進(jìn)行通信，該地址不會(huì)變化。

隨著主機(jī)越來(lái)越多，IP 地址不易記憶，為了方便主機(jī)間相互識(shí)別，可以給每臺(tái)主機(jī)設(shè)置內(nèi)網(wǎng)別名。為方便在控制臺(tái)管理，給每個(gè)資源打上標(biāo)簽，按照標(biāo)簽來(lái)組織分類。

接下來(lái)我們回到上面那個(gè)簡(jiǎn)單的后端架構(gòu)。隨著訪問壓力越來(lái)越大，單臺(tái) nginx + Java application 可能不足以應(yīng)付，你會(huì)看到這臺(tái)主機(jī)的 CPU 越來(lái)越忙 ，內(nèi)存使用越來(lái)越多。而且這臺(tái)主機(jī)一旦故障，整個(gè)服務(wù)都不可用了。

所以我們首先調(diào)整這里的結(jié)構(gòu)，增加多臺(tái) nignx + Java application 同時(shí)提供服務(wù)，在接入層引入負(fù)載均衡器（下文用 LB 這個(gè)詞代替），使外網(wǎng)請(qǐng)求首先發(fā)到 LB 上。LB 的選擇有很多，比如提供七層負(fù)載能力的 nginx 和 HAProxy，也有提供四層負(fù)載能力的 LVS，安裝和配置的方法各有不同。

LB 的引入可以分?jǐn)傉?qǐng)求壓力到后端的多臺(tái)業(yè)務(wù)服務(wù)器，并且可通過心跳檢查，自動(dòng)隔離后端出現(xiàn)故障的服務(wù)器，實(shí)現(xiàn)業(yè)務(wù)層的高可用。但這時(shí) LB 本身也會(huì)成為一個(gè)單點(diǎn)，當(dāng)出現(xiàn)故障也會(huì)導(dǎo)致全局不可用。所以可以使用 Keeplived 服務(wù)為 LB 提供一個(gè)副本，在一臺(tái)出問題的時(shí)候可以馬上頂上，部署方法網(wǎng)上有很多資料。

有人會(huì)說(shuō)可以通過 DNS 輪詢到不同的 IP ，實(shí)現(xiàn) LB 的高可用，但事實(shí)上這樣不行，因?yàn)橐坏┮慌_(tái) LB 掛掉，DNS 還會(huì)解析到這個(gè) LB，此時(shí)即便馬上修改 DNS，在 DNS 緩存更新之前（通常要很久），服務(wù)也是不可用的。

雖然 LB 的原理并不復(fù)雜，但是部署配置有很多工作量，而且為了實(shí)現(xiàn) LB 的高可用還要額外做一些事情。QingCloud 從北京3區(qū)開始提供了高性能、高可用的 LB 集群服務(wù)，可以直接拿來(lái)使用。

接下來(lái)我們來(lái)思考業(yè)務(wù)層的擴(kuò)展問題。首先要解決如何快速擴(kuò)充業(yè)務(wù)服務(wù)器。如果業(yè)務(wù)服務(wù)器的運(yùn)行環(huán)境和程序不會(huì)頻繁更新，可以基于已有的業(yè)務(wù)服務(wù)器制作主機(jī)映像，當(dāng)需要擴(kuò)容時(shí)，直接基于映像創(chuàng)建新的主機(jī)，掛接到 LB 后端就可以馬上對(duì)外服務(wù)了。

此時(shí)你還可以使用 AutoScaling 功能自動(dòng)化這一過程，即當(dāng)?shù)竭_(dá)某種觸發(fā)條件，如 LB 并發(fā)數(shù)、響應(yīng)延遲達(dá)到多少后，自動(dòng)觸發(fā)主機(jī)的擴(kuò)容。當(dāng)觸發(fā)條件不滿足時(shí)，可以回收資源。

當(dāng)然如果你的業(yè)務(wù)服務(wù)器的環(huán)境或程序需要頻繁更新，不適合做成固定模版。此時(shí)可以自己搭建自動(dòng)化部署（如 Puppet / Ansible）實(shí)現(xiàn)業(yè)務(wù)自動(dòng)擴(kuò)容，這一切操作可以使用 QingCloud 的開放 API 接口，結(jié)合你的自動(dòng)化部署程序完成。

此外你還需要保證業(yè)務(wù)服務(wù)器是無(wú)狀態(tài)的，因?yàn)槊看?LB 請(qǐng)求的后端可能不同，不能假設(shè)上一次請(qǐng)求和這一次請(qǐng)求落在同一臺(tái)業(yè)務(wù)服務(wù)器上。如果服務(wù)器需要保存用戶訪問的 session 信息，可將其下放到緩存或數(shù)據(jù)庫(kù)中存儲(chǔ)。

隨著產(chǎn)品功能越來(lái)越豐富，你會(huì)發(fā)現(xiàn)原有單一的業(yè)務(wù)項(xiàng)目越來(lái)越龐大，各種功能邏輯交織在一起，當(dāng)一個(gè)功能出現(xiàn)故障，可以引發(fā)全局不可用。此時(shí)你需要考慮將單一的業(yè)務(wù)項(xiàng)目分拆成多個(gè)獨(dú)立子服務(wù)。子服務(wù)之間可以基于消息的通信，亦或基于 RPC 的通信方式。

子服務(wù)的調(diào)用可分為需同步處理和可異步處理兩類。你應(yīng)該盡量異步化所有不需要馬上返回結(jié)果的請(qǐng)求。對(duì)于可異步處理的請(qǐng)求，我們通過引入消息隊(duì)列，為請(qǐng)求產(chǎn)生的數(shù)據(jù)做緩沖，請(qǐng)求的接收者（隊(duì)列消費(fèi)者）可根據(jù)隊(duì)列中任務(wù)的數(shù)量做水平擴(kuò)容。消息隊(duì)列的選擇有很多，例如 Redis, RabbitMQ, ActiveMQ, Kafka，QingCloud 平臺(tái)上目前已經(jīng)提供分布式、可分區(qū)、多副本的消息隊(duì)列服務(wù)，具有高吞吐量、低延遲等特點(diǎn)，用戶可以方便的集成到自己的系統(tǒng)中。

如今數(shù)據(jù)分析對(duì)于企業(yè)越來(lái)越至關(guān)重要，業(yè)務(wù)服務(wù)器在處理請(qǐng)求的過程中，可以將原始數(shù)據(jù)通過隊(duì)列，源源不斷地導(dǎo)入大數(shù)據(jù)處理系統(tǒng)，QingCloud 提供完善的大數(shù)據(jù)分布式處理平臺(tái) Spark 和 Hadoop，用戶可以根據(jù)需求方便的創(chuàng)建，使用和擴(kuò)容。

通過拆分子服務(wù)，使得我們有能力在某項(xiàng)子服務(wù)發(fā)生故障時(shí)，盡可能降低對(duì)于全局的影響，提高系統(tǒng)整體的可用性。另外，對(duì)于處理壓力比較大的子服務(wù)，我們還可以進(jìn)行獨(dú)立的水平擴(kuò)容，方式和前面講到的業(yè)務(wù)服務(wù)器擴(kuò)容相似，QingCloud 內(nèi)網(wǎng) LB 服務(wù)也可以在這里發(fā)揮作用。

隨著業(yè)務(wù)的增長(zhǎng)，數(shù)據(jù)層面臨的壓力會(huì)越來(lái)越大，單機(jī)數(shù)據(jù)庫(kù)已經(jīng)不足以支撐，接下來(lái)我們談一下數(shù)據(jù)層的分布式和擴(kuò)展技術(shù)。

對(duì)于大多數(shù)的業(yè)務(wù)場(chǎng)景來(lái)說(shuō)，數(shù)據(jù)的操作都是讀多寫少，而且讀都集中在少部分的熱點(diǎn)數(shù)據(jù)上，首先應(yīng)該引入緩存層來(lái)緩解數(shù)據(jù)庫(kù)的讀壓力，如果緩存容量需求比較大，可以構(gòu)建緩存集群，在上層按照 consistent hashing 算法將數(shù)據(jù)分散到多個(gè)節(jié)點(diǎn)，后續(xù)需要增加新緩存節(jié)點(diǎn)時(shí)，只有少部分的數(shù)據(jù)會(huì)失效。

接著引入新的數(shù)據(jù)庫(kù)種類，Redis 已經(jīng)成為諸多企業(yè)的首選標(biāo)配，因?yàn)槠渲С重S富的數(shù)據(jù)類型和數(shù)據(jù)查詢接口，且內(nèi)存型的數(shù)據(jù)庫(kù)天然具有更高的性能。 你可以講業(yè)務(wù)中關(guān)系性要求不高的數(shù)據(jù)，從 MySQL 轉(zhuǎn)移到 Redis 中，尤其是列表類的數(shù)據(jù)以及計(jì)數(shù)統(tǒng)計(jì)類的數(shù)據(jù)。給 MySQL 減負(fù)的同時(shí)提高數(shù)據(jù)的查詢性能。 單臺(tái) Redis 節(jié)點(diǎn)也許不能滿足你對(duì)容量的需求，QingCloud 平臺(tái)提供了支持多主多從 Redis 3.0 集群服務(wù)，一方面可對(duì)數(shù)據(jù)自動(dòng)分區(qū)提高存儲(chǔ)容量，另一方面保證了服務(wù)的高可用性。

對(duì)于 MySQL 的擴(kuò)展可以分為幾個(gè)步驟來(lái)做。首先，增加 MySQL slave 節(jié)點(diǎn)，在上層將部分讀請(qǐng)求分發(fā)到 slave 節(jié)點(diǎn)上去，由于 slave 同步可能有延時(shí)，業(yè)務(wù)應(yīng)該能容忍短暫的數(shù)據(jù)不一致現(xiàn)象，舉例，比如你的一個(gè)用戶修改了年齡屬性，其他用戶要等一會(huì)兒才能看到他的新年齡。

QingCloud MySQL 數(shù)據(jù)庫(kù)支持一主多從的架構(gòu)，并且已經(jīng)在多個(gè)從節(jié)點(diǎn)之上做好了負(fù)載均衡，你可以輕易在界面上操作增加新的從節(jié)點(diǎn)來(lái)為你分擔(dān)讀壓力。

即便有 slave 作為數(shù)據(jù)副本，你也應(yīng)該定期對(duì)你的數(shù)據(jù)庫(kù)進(jìn)行冷備份，方便當(dāng)業(yè)務(wù)出現(xiàn)誤操作時(shí)，能夠回滾或恢復(fù)到曾經(jīng)的某個(gè)時(shí)間點(diǎn)。在 QingCloud 平臺(tái)上，備份的過程可以手動(dòng)執(zhí)行或者配置為自動(dòng)任務(wù)，在備份過程中對(duì)數(shù)據(jù)庫(kù)正常使用沒有影響。

隨著數(shù)據(jù)的增長(zhǎng)，單個(gè)數(shù)據(jù)庫(kù)不能承載完整的數(shù)據(jù)集合，并且寫操作對(duì)于單庫(kù)的壓力越來(lái)越明顯，你應(yīng)該考慮分庫(kù)分表技術(shù)。將比較龐大的數(shù)據(jù)表拆分出來(lái)單獨(dú)存放，可以給主數(shù)據(jù)庫(kù)騰出來(lái)一部分空間，分擔(dān)讀寫壓力。拆分的時(shí)候，還可以按照功能邏輯，把相關(guān)聯(lián)的數(shù)據(jù)表存在一個(gè)庫(kù)里。

當(dāng)數(shù)據(jù)庫(kù)單表非常龐大，對(duì)讀寫都造成瓶頸時(shí)，你需要開始考慮水平分表 sharding，這種擴(kuò)展方式可以同時(shí)解決單表容量過大，讀壓力和寫壓力很大的問題，但帶來(lái)的研發(fā)和運(yùn)維難度也會(huì)增大，推薦把上述的優(yōu)化做完以后，最后在有必要的情況下再做。

這里簡(jiǎn)略說(shuō)一下水平分表的要點(diǎn)。首先要從數(shù)據(jù)表的字段中，選擇一個(gè)合理的分區(qū)鍵（shard key），這個(gè)鍵應(yīng)該是所有該表查詢條件里，最經(jīng)常用到的字段，這樣才會(huì)使大部分的查詢，能夠提前判斷應(yīng)該向哪些特定的分區(qū)（shard）發(fā)送請(qǐng)求，如果查詢條件中不帶shard key，需要遍歷所有的分區(qū)，并將結(jié)果進(jìn)行merge。

有了 shard key 還要設(shè)計(jì)一種分區(qū)算法，比如常見的有按照區(qū)間，如 user_id in [0, 100] 在 shard 1，user_id in [101, 200] 在 shard2，還比如按照 hash 取模等等。設(shè)計(jì)分區(qū)算法的時(shí)候要充分考慮業(yè)務(wù)特點(diǎn)，多從讀寫操作的角度思考，這么設(shè)計(jì)能否將壓力和數(shù)據(jù)均勻分?jǐn)偟矫總€(gè) shard 上去。

還需要考慮數(shù)據(jù)層的擴(kuò)展如何對(duì)上層透明，比如引入分布式數(shù)據(jù)庫(kù)中間件，或者結(jié)合業(yè)務(wù)邏輯把數(shù)據(jù)庫(kù)操作做成一個(gè)獨(dú)立的子服務(wù)，供其它服務(wù)調(diào)用。如果不做成子服務(wù)，至少在業(yè)務(wù)代碼里有獨(dú)立的一層來(lái)封裝對(duì)數(shù)據(jù)庫(kù)的操作。

除了上述的結(jié)構(gòu)化數(shù)據(jù)的存取以外，企業(yè)還有存儲(chǔ)海量小文件數(shù)據(jù)（非結(jié)構(gòu)化數(shù)據(jù)）的需求，單機(jī)硬盤、LVM 和 NAS 可以作為臨時(shí)方案使用，但都無(wú)法同時(shí)滿足無(wú)限容量、高性能、高安全性、高可用性的多重需要。而自行搭建分布式存儲(chǔ)系統(tǒng)，如 Ceph、GlusterFS、HDFS 適用場(chǎng)景非常有限，且運(yùn)維和二次開發(fā)的成本也非常高。

在 QingCloud 平臺(tái)上用戶可以使用 QingStor 對(duì)象存儲(chǔ)服務(wù)來(lái)存儲(chǔ)海量的數(shù)據(jù)文件，服務(wù)本身提供了無(wú)限容量、高擴(kuò)展性、高可用性和高安全性的特性。

講完數(shù)據(jù)層的擴(kuò)展技術(shù)，最后來(lái)談一下多機(jī)房部署和異地容災(zāi)的話題。QingCloud 從北京3區(qū)機(jī)房開始，通過自營(yíng)的骨干網(wǎng)光纖和多路環(huán)網(wǎng)技術(shù)，使得當(dāng)機(jī)房出現(xiàn)網(wǎng)絡(luò)故障時(shí)對(duì)用戶無(wú)感知，在基礎(chǔ)設(shè)施上保障了高可用性。但是用戶的業(yè)務(wù)如果能夠多機(jī)房部署，可以在分?jǐn)傇L問負(fù)載的同時(shí)加速區(qū)域訪問，比如加速中國(guó)南北方的用戶或者海外用戶的訪問。

若是有三個(gè)機(jī)房，中間是 QingCloud 北京3區(qū)機(jī)房，負(fù)責(zé)主營(yíng)業(yè)務(wù)。左邊是 QingCloud 亞太1區(qū)機(jī)房，主要服務(wù)亞太和海外的客戶。這兩個(gè)機(jī)房都使用了 QingCloud 私有網(wǎng)絡(luò)（VPC）部署，通過GRE或IPsec加密隧道在網(wǎng)絡(luò)上的互聯(lián)互通。右邊是你辦公室的物理機(jī)房，IT 人員可以在這個(gè)環(huán)境下進(jìn)行開發(fā)和辦公。

在業(yè)務(wù)上實(shí)現(xiàn)異地多活時(shí)，通常從易到難有三個(gè)階段：第一，在備用機(jī)房搭建反向代理，用戶請(qǐng)求到備用機(jī)房，請(qǐng)求直接被轉(zhuǎn)向主機(jī)房，如果兩機(jī)房有專線互聯(lián)或延時(shí)很小，這樣部署最為簡(jiǎn)單。第二，兩個(gè)機(jī)房同時(shí)部署業(yè)務(wù)服務(wù)器和緩存，由于大部分?jǐn)?shù)據(jù)請(qǐng)求可以從緩存中讀取，不用進(jìn)行跨機(jī)房訪問。但當(dāng)緩存失效時(shí)，依然要從主機(jī)房的數(shù)據(jù)庫(kù)去查詢。第三，兩機(jī)房同時(shí)部署全套系統(tǒng)，包括接入層、業(yè)務(wù)層和數(shù)據(jù)層。數(shù)據(jù)層依靠數(shù)據(jù)庫(kù)雙主或主從技術(shù)進(jìn)行跨機(jī)房同步。

最后總結(jié)一下今天的分享。沒有一個(gè)所謂經(jīng)典或完美的架構(gòu)，只有最適合企業(yè)業(yè)務(wù)的架構(gòu)，今天分享的是在最通用的業(yè)務(wù)場(chǎng)景下，系統(tǒng)在接入層、業(yè)務(wù)層和數(shù)據(jù)層的常用擴(kuò)展方法。企業(yè)后端架構(gòu)的演進(jìn)過程是一個(gè)漫長(zhǎng)而艱巨的過程，不可能從零開始一蹴而就，就能設(shè)計(jì)出一個(gè)萬(wàn)般周全的系統(tǒng)，但如果設(shè)計(jì)之初能更多著眼于未來(lái)，就可以為進(jìn)一步優(yōu)化留出了余地。

問題

1、企業(yè)客戶，私有云如何建設(shè)不同規(guī)模下的分布式系統(tǒng)？

企業(yè)首先要清楚當(dāng)前業(yè)務(wù)的規(guī)模有多大，比如業(yè)務(wù)的種類，服務(wù)QPS，數(shù)據(jù)的種類和數(shù)據(jù)量的大小，同時(shí)清楚業(yè)務(wù)和數(shù)據(jù)的SLA 和性能預(yù)期。只有在清楚這些的情況下，才能在規(guī)劃的過程中有權(quán)衡取舍。

云計(jì)算環(huán)境下，基礎(chǔ)資源的創(chuàng)建和銷毀都非常迅速，要把更多關(guān)注放在業(yè)務(wù)層面的可擴(kuò)展能力上，比如業(yè)務(wù)層要無(wú)狀態(tài)，數(shù)據(jù)層要做好索引，做好冷熱區(qū)分。無(wú)論規(guī)模大小，系統(tǒng)的組件不應(yīng)該有單點(diǎn)故障和單點(diǎn)瓶頸。在規(guī)模較小的時(shí)候，系統(tǒng)可以不擴(kuò)展，但是要具備可擴(kuò)展的能力。

2、冷熱數(shù)據(jù)管理以及數(shù)據(jù)持久化是怎么做的？

更熱的數(shù)據(jù)應(yīng)該被更快的訪問到，決定存取速度的因素主要是距離和介質(zhì)。從距離來(lái)看 本地內(nèi)存 > 本地硬盤 > 遠(yuǎn)端內(nèi)存 > 遠(yuǎn)端硬盤，從介質(zhì)來(lái)看 SSD > SAS > SATA。冷熱數(shù)據(jù)的比例一般是非常懸殊的，要將熱的數(shù)據(jù)存放到更近更好的介質(zhì)上。

每一種存儲(chǔ)系統(tǒng)諸如 MySQL Redis 都有自己的數(shù)據(jù)持久化策略。

3、數(shù)據(jù)大集中平臺(tái)的安全性是否比原來(lái)點(diǎn)對(duì)點(diǎn)接口低？

其實(shí)無(wú)論數(shù)據(jù)的存儲(chǔ)形式是怎樣的，數(shù)據(jù)的安全性主要取決于是否有冗余，冗余度是多少，冗余的分布是否是跨物理機(jī)，甚至是否跨機(jī)房。數(shù)據(jù)寫入是否真正落盤，以及數(shù)據(jù)的副本是同步寫入還是異步寫入。

4、構(gòu)建大型分布式平臺(tái)系統(tǒng)，緩存管理用redis來(lái)實(shí)現(xiàn)，應(yīng)該注意什么？

首先考慮緩存的粒度，太粗的粒度會(huì)導(dǎo)致失效太頻繁。還要考慮緩存容量，如果單臺(tái)節(jié)點(diǎn)無(wú)法承載足夠的熱點(diǎn)數(shù)據(jù)，在使用多節(jié)點(diǎn)是要注意選擇合適分布策略，比較常有的有一致性hash和hash取模。Redis3.0以上版本提供了集群能力，可以自動(dòng)對(duì)數(shù)據(jù)分區(qū)，并提供高可用能力。

5、分布式數(shù)據(jù)庫(kù)、緩存，如何實(shí)現(xiàn)資源池化？

可在數(shù)據(jù)庫(kù)服務(wù)之上增加代理中間件，有開源方案也有自己實(shí)現(xiàn)，對(duì)使用者提供的接口要屏蔽分布式的細(xì)節(jié)，用戶不用關(guān)心容量，性能，分布策略等，仿佛看到的是一臺(tái)單機(jī)數(shù)據(jù)庫(kù)

6、大規(guī)模分布式系統(tǒng)下后端交易數(shù)據(jù)是如何存放的，如何實(shí)現(xiàn)數(shù)據(jù)的多中心容災(zāi)保護(hù)？

交易數(shù)據(jù)最重要的是不能丟失，性能是次要，曾經(jīng)很多傳統(tǒng)企業(yè)會(huì)選擇oracle這樣的商業(yè)數(shù)據(jù)庫(kù)，新型企業(yè)越來(lái)越多愿意采用 MySQL PostgreSQL 等開源實(shí)現(xiàn)，但是配置的時(shí)候一定是配成最嚴(yán)格的同步寫多份成功才返回，并且有日志留存

7、云計(jì)算適合哪些類型的應(yīng)用，衡量標(biāo)準(zhǔn)是什么？

云計(jì)算做為 IT 基礎(chǔ)設(shè)施資源，在各行各業(yè)都有成功案例，已經(jīng)不分適合哪類應(yīng)用。唯一衡量標(biāo)準(zhǔn)就是能否滿足需求，要看是否能取代傳統(tǒng)硬件能夠提供的能力，并且能夠提供傳統(tǒng)硬件以外的能力，例如彈性伸縮，按用量計(jì)費(fèi)，快速啟動(dòng)銷毀等。

8、keepalived的性能如何？后端是HAPROXY嗎？

keepalived 主要通過引入虛擬路由冗余（VRRP）來(lái)實(shí)現(xiàn)高可用，本質(zhì)上不會(huì)對(duì)性能造成影響，它是一個(gè)獨(dú)立的服務(wù)，和HAProxy沒有關(guān)系。

9、青云QingCloud 的云服務(wù)是否能夠預(yù)防由于namenode掉電等原因引發(fā)的hadoop集群崩潰？

目前青云的IaaS層在物理機(jī)掉電時(shí)會(huì)觸發(fā)災(zāi)難恢復(fù)，另一臺(tái)同樣的主機(jī)會(huì)啟動(dòng)起來(lái)，數(shù)據(jù)不會(huì)丟失，然后再啟動(dòng)hdfs的服務(wù)即可恢復(fù)集群使用。Hadoop的自身的HA也會(huì)很快提供，這樣就可以自動(dòng)恢復(fù)hdfs服務(wù)了。

10、auto scaling太多實(shí)例，db最大連接耗盡如何處理？

可以在實(shí)例和db之間引入代理中間件，還可以自己實(shí)現(xiàn)一個(gè)獨(dú)立的數(shù)據(jù)訪問服務(wù)，不讓實(shí)例直接操作db。

上述內(nèi)容就是如何在云計(jì)算平臺(tái)中構(gòu)建大規(guī)模分布式系統(tǒng)，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注億速云行業(yè)資訊頻道。