?

1. 分布數(shù)據(jù)的理由

• 單機(jī)無(wú)法承受負(fù)載，請(qǐng)寫請(qǐng)求太大，一臺(tái)機(jī)處理不過(guò)來(lái)，為了可擴(kuò)展性
• 避免單點(diǎn)故障，一臺(tái)機(jī)掛了，整個(gè)服務(wù)就掛了。為了容錯(cuò)和高可用
• 降低服務(wù)的延遲，用戶分布在各個(gè)地區(qū)，服務(wù)器部署在各個(gè)機(jī)房，將服務(wù)部署到離用戶近的地方

2. 垂直擴(kuò)容方案

• 一臺(tái)機(jī)器內(nèi)存不夠了，那就加內(nèi)存；CPU不夠了，那就加CPU。
• 在一臺(tái)機(jī)器上，內(nèi)存加一倍、CPU加一倍，但是硬件配置所需要花的錢，卻是多倍。
• 單機(jī)的硬件配置翻了一倍，該機(jī)器所能承受的負(fù)載卻并不能翻一倍，因?yàn)橛衅款i問(wèn)題。
• 這是一種 share-memory 結(jié)構(gòu)

3. 水平擴(kuò)容

• 加一臺(tái)單獨(dú)的機(jī)器，每臺(tái)機(jī)器稱為一個(gè)節(jié)點(diǎn)，組成所謂的集群
• 節(jié)點(diǎn)之間的協(xié)調(diào)由 軟件層面(用戶程序) 來(lái)實(shí)現(xiàn)
• 這是一種share-nothing 結(jié)構(gòu)

4. 數(shù)據(jù)的分布方式

• 副本，Replication

  將數(shù)據(jù)復(fù)制成多份，每份放在不同的節(jié)點(diǎn)上。復(fù)制產(chǎn)生了冗余，一臺(tái)節(jié)點(diǎn)掛了，數(shù)據(jù)可從其他節(jié)點(diǎn)上拿到。

• 分片，Partition

  將量級(jí)很大的數(shù)據(jù)分布多個(gè)小塊，每個(gè)節(jié)點(diǎn)上存儲(chǔ)一小塊。因此，分片(Partition)是指：比如說(shuō)，一臺(tái)機(jī)器無(wú)法存下10T的數(shù)據(jù)，那我把這10T的數(shù)據(jù)，分成10個(gè)小份，每小份1T，放在10臺(tái)機(jī)器上。這樣，每臺(tái)機(jī)器只存儲(chǔ)1T數(shù)據(jù)。

副本

注意，是Replication，不是Partition。

為什么要將數(shù)據(jù)復(fù)制成多份呢？

• 我有一個(gè)關(guān)鍵詞過(guò)濾服務(wù)部署在三個(gè)機(jī)房，如果每個(gè)機(jī)房都有一份詞庫(kù)，這樣部署在本機(jī)房的過(guò)濾服務(wù)只需要讀取自己機(jī)房的詞庫(kù)即可，從而降低延遲。
• 如果只有一份詞庫(kù)，這些詞庫(kù)所在的機(jī)器掛了，部署在三個(gè)機(jī)房的關(guān)鍵詞過(guò)濾服務(wù)都不能用了。
• 分散讀壓力。如果只有一份詞庫(kù)，所有的關(guān)鍵詞過(guò)濾服務(wù)程序都要來(lái)讀取該詞庫(kù)，讀請(qǐng)求吞吐量太大，響應(yīng)不過(guò)來(lái)。

因此，每個(gè)機(jī)房有一份關(guān)鍵詞（三個(gè)副本）。因此，我這里采用多副本的原因是：讓數(shù)據(jù)更靠近用戶，以降低延遲。

副本帶來(lái)的難點(diǎn)是，當(dāng)數(shù)據(jù)修改的時(shí)候，如何保持各個(gè)副本的一致性？

保證副本一致性的解決方案

Leader-based replication

以上面的關(guān)鍵詞服務(wù)為例，三個(gè)副本中有一個(gè)副本是Leader，當(dāng)需要添加新關(guān)鍵詞時(shí)（網(wǎng)絡(luò)上又出現(xiàn)了新的罵人的話^>^），向Leader發(fā)起寫請(qǐng)求，將新詞添加到詞庫(kù)中。

其他兩個(gè)副本稱為Follower。當(dāng)Leader將新添加的詞持久化到本地磁盤后，開(kāi)始將新詞同步到其他兩個(gè)Follower。這里還有更深入一點(diǎn)的討論，比如：同步操作是不是要保證以相同的順序進(jìn)行？比如Leader先將 詞A 持久化，再將 詞B 持久化，那兩個(gè)副本是不是也應(yīng)該以相同的順序，先寫入關(guān)鍵詞A，再寫入關(guān)鍵詞B？

為了分擔(dān)Leader壓力，當(dāng)客戶端需要讀取關(guān)鍵詞時(shí)，可以從Follower讀取，但是從Follower讀取能不能讀取到最新的數(shù)據(jù)呢？

這種主從式的副本方案，Mysql實(shí)現(xiàn)了、MongoDB也實(shí)現(xiàn)了，哈哈。我們就是這樣干的。

同步復(fù)制還是異步復(fù)制？

• 這是一個(gè)權(quán)衡。在客戶端寫請(qǐng)求的響應(yīng)性和數(shù)據(jù)的可靠性二者之間權(quán)衡

• 完全異步復(fù)制，客戶端發(fā)寫請(qǐng)求給Leader，Leader寫入成功后，立即返回響應(yīng)給客戶端，然后Leader再將新寫入的數(shù)據(jù)同步給其他Follower。這種方式的特點(diǎn)：

• 客戶端響應(yīng)快，因?yàn)橹恍枰狶eader寫入成功就返回”寫成功“響應(yīng)給客戶端
• 如果Leader寫入數(shù)據(jù)后，還未來(lái)得及同步到Follower，就宕機(jī)了，就數(shù)據(jù)就丟失了。
• 客戶端向Follower發(fā)起讀請(qǐng)求時(shí)，有可能讀取不到最新的數(shù)據(jù)。Leader給客戶端返回的結(jié)果是寫入成功了，但Leader還未同步到Follower，這里客戶端就會(huì)看到：明明 已經(jīng)寫入成功的數(shù)據(jù)，卻讀取不到。

• 半同步復(fù)制。客戶端發(fā)請(qǐng)求給Leader，Leader將數(shù)據(jù)同步給Follower，當(dāng)其中一部分Follower同步成功后，立即給Leader回復(fù)成功。比如下圖，Follower1同步成功給Leader響應(yīng)，Leader再向客戶端響應(yīng) 寫入成功。

• 如果Leader掛了，Follower1馬上可以充當(dāng)Leader，因?yàn)镕ollower1與Leader之間數(shù)據(jù)是一致的。如果Follower1掛了，Follower2可以充當(dāng)Follower1的角色，并從Leader處同步最新的數(shù)據(jù)?？傊?#xff0c;可以實(shí)現(xiàn)一定的容錯(cuò)。
• 在響應(yīng)性和一致性、還有可靠性之間有一個(gè)較好的折衷。不需要等待所有的副本都寫入成功，才向Client返回寫入成功的響應(yīng)，因此有著較好的響應(yīng)性；在Client看來(lái)，Leader和Follower1 的數(shù)據(jù)是強(qiáng)一致的，如果Leader掛了，Follower1中保存著Client最近寫入成功的數(shù)據(jù)，因此能容忍單機(jī)掛掉。

• 同步復(fù)制。客戶端發(fā)寫請(qǐng)求給Leader，Leader向Follower發(fā)同步請(qǐng)求，當(dāng)所有的Follower都將 寫請(qǐng)求 持久化成功后，給Leader響應(yīng)，然后Leader再向客戶端響應(yīng)寫請(qǐng)求成功。這種方式的特點(diǎn)是：

• 寫操作吞吐量受到限制，因?yàn)橐粋€(gè)寫請(qǐng)求要等到所有的副本都持久化成功后，才算成功，只要有一臺(tái)機(jī)器掛了，那客戶端寫請(qǐng)求就一直阻塞在那里，得不到響應(yīng)。
• 客戶端不管讀哪個(gè)副本 ，每次都能讀到最新寫入成功的數(shù)據(jù)，因?yàn)閷?duì)于寫入成功的數(shù)據(jù)，肯定都已經(jīng)成功同步到各個(gè)副本了。

總結(jié)一下這種主從副本的同步方案：當(dāng)要更新數(shù)據(jù)時(shí)，都是向Leader發(fā)起請(qǐng)求。

如果采用完全異步復(fù)制，會(huì)存在數(shù)據(jù)一致性問(wèn)題，Client讀Follower不一定能讀到最新的數(shù)據(jù)，要想讀最新的數(shù)據(jù)，可以向Leader發(fā)起讀請(qǐng)求，但這樣可能造成Leader所在節(jié)點(diǎn)的負(fù)載過(guò)大，而Leader一旦掛掉，那些還未來(lái)得及同步到Follower的數(shù)據(jù)就都掛失了，導(dǎo)致Client看到的結(jié)果是：明明你給我返回的響應(yīng)是數(shù)據(jù)寫入成功了，但是我的數(shù)據(jù)卻丟失了

如果采用完全同步復(fù)制，響應(yīng)性就得不到很好的保證，畢竟網(wǎng)絡(luò)分區(qū)、網(wǎng)絡(luò)抖動(dòng)不可避免。只要有一個(gè)Follower出現(xiàn)故障，無(wú)法響應(yīng)，那Client就得不到 寫入成功的響應(yīng)了。當(dāng)然好處是，在Client看來(lái)，數(shù)據(jù)的一致性有保證，隨便讀哪臺(tái)Follower，都能讀取到已經(jīng)寫入成功的數(shù)據(jù)

瞎扯了這么多理論，后面有時(shí)間再了解下一個(gè)具體的用到的產(chǎn)品ElasticSearch中的Shard和Replica同步的原理。囧。

原文：https://www.cnblogs.com/hapjin/p/9609868.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的为什么要将服务或者数据部署多份？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。