国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

MySQL - 擴(kuò)展性 3 負(fù)載均衡:眼花繚亂迷人眼

jindong / 549人閱讀

摘要:負(fù)載均衡器的作用是將請(qǐng)求的連接路由到最空閑的可用服務(wù)器上。負(fù)載均衡有五個(gè)常見目的可擴(kuò)展性。靈活的負(fù)載均衡方案能夠大幅提高服務(wù)的可用性。連接池和長(zhǎng)連接可能會(huì)阻礙負(fù)載均衡器分發(fā)連接請(qǐng)求。

負(fù)載均衡的基本思路很簡(jiǎn)單:

在一個(gè)服務(wù)器集群中盡可能地的平均負(fù)載量。

基于這個(gè)思路,我們通常的做法是在服務(wù)器前端設(shè)置一個(gè)負(fù)載均衡器。負(fù)載均衡器的作用是將請(qǐng)求的連接路由到最空閑的可用服務(wù)器上。如圖 1,顯示了一個(gè)大型網(wǎng)站負(fù)載均衡設(shè)置。其中一個(gè)負(fù)責(zé) HTTP 流量,另一個(gè)用于 MySQL 訪問(wèn)。

負(fù)載均衡有五個(gè)常見目的:

可擴(kuò)展性。負(fù)載均衡對(duì)某些擴(kuò)展很有幫助,比如讀寫分離時(shí)從備庫(kù)讀數(shù)據(jù)。

高效性。負(fù)載均衡因?yàn)槟軌蚩刂普?qǐng)求被路由到何處,因此有助于更有效的使用資源。

可用性。靈活的負(fù)載均衡方案能夠大幅提高服務(wù)的可用性。

透明性。客戶端無(wú)需知道是否存在負(fù)載均衡器,也不需要關(guān)系在負(fù)載均衡器的背后有多少機(jī)器。呈現(xiàn)給客戶端看到的就是一個(gè)透明的服務(wù)器。

一致性。如果應(yīng)用是有狀態(tài)的(數(shù)據(jù)庫(kù)事務(wù)、網(wǎng)站會(huì)話等),那么負(fù)載均衡器就可以將相關(guān)的查詢指向同一個(gè)服務(wù)器,以防止?fàn)顟B(tài)丟失。

而對(duì)于負(fù)載均衡的實(shí)現(xiàn),一般有兩種方式:直接連接引入中間件

1 直接連接

有些人認(rèn)為負(fù)載均衡就是配置在應(yīng)用和 MySQL 服務(wù)器直接?xùn)|西,但實(shí)際上這并不是唯一的負(fù)載均衡方法。接下來(lái)我們就討論一下常見的應(yīng)用直連的方法,及其相關(guān)注意事項(xiàng)。

1.1 復(fù)制的讀寫分離

此種方式下,容易出現(xiàn)一個(gè)最大的問(wèn)題:臟數(shù)據(jù)。一個(gè)典型的例子是,當(dāng)用戶評(píng)論了一篇博文,然后重新加載頁(yè)面,卻沒有看到新增的評(píng)論。

當(dāng)然,我們也不能因?yàn)榕K數(shù)據(jù)的問(wèn)題,就將讀寫分離棄之不用。實(shí)際上,對(duì)于很多應(yīng)用,可能對(duì)臟數(shù)據(jù)的容忍度比較高,此時(shí)就可以大膽的引入此種方式。

那么對(duì)于臟數(shù)據(jù)的容忍度比較低的應(yīng)用,如何進(jìn)行讀寫分離呢?接下來(lái),我們對(duì)讀寫分離再進(jìn)一步區(qū)分,相信你總能找到適合自己的一款策略。

1) 基于查詢分離

如果應(yīng)用只有少數(shù)數(shù)據(jù)不能容忍臟數(shù)據(jù),我們可以將所有不能容忍臟數(shù)據(jù)的讀和寫都分配到 master 上。其它的讀查詢分配的 slave 上。該策略很容易實(shí)現(xiàn),但如果容忍臟數(shù)據(jù)的查詢比較少,很可能會(huì)出現(xiàn)不能有效使用備庫(kù)的情況。

2) 基于臟數(shù)據(jù)分離

這是對(duì)基于查詢分離策略的小改進(jìn)。需要做一些額外的工作,比如讓應(yīng)用檢查復(fù)制延遲,以確定備庫(kù)數(shù)據(jù)是否最新。許多報(bào)表類應(yīng)用都可以使用這個(gè)策略:只需要晚上加載的數(shù)據(jù)復(fù)制到備庫(kù)接口,并不關(guān)心是不是完全跟上了主庫(kù)。

3) 基于會(huì)話分離

這個(gè)策略比臟數(shù)據(jù)分離策略更深入 一些。它是判斷用戶是否修改了數(shù)據(jù),用戶不需要看到其他用戶的最新數(shù)據(jù),只需要看到自己的更新。

具體可以在會(huì)話層設(shè)置一個(gè)標(biāo)記位,表明用戶是否做了更新,用戶一旦做了更新,就將該用戶的查詢?cè)谝欢螘r(shí)間內(nèi)指向主庫(kù)。

這種策略在簡(jiǎn)單和有效性之間做了很好的妥協(xié),是一種較為推薦的策略。

當(dāng)然,如果你的想法夠多,可以把基于會(huì)話的分離策略和復(fù)制延遲監(jiān)控策略結(jié)合起來(lái)。如果用戶在 10 秒前更新了數(shù)據(jù),而所有備庫(kù)延遲在 5 秒內(nèi),就可以大膽的從備庫(kù)中讀取數(shù)據(jù)。要注意的是,記得為整個(gè)會(huì)話選擇同個(gè)備庫(kù),否則一旦多個(gè)備庫(kù)的延遲不一致,就會(huì)給用戶造成困擾。

4) 基于全局版本 / 會(huì)話分離

通過(guò)記錄主庫(kù)日志坐標(biāo)和備庫(kù)已復(fù)制的坐標(biāo)對(duì)比,確認(rèn)備庫(kù)是否更新數(shù)據(jù)。當(dāng)應(yīng)用指向?qū)懖僮鲿r(shí),在提交事務(wù)后,執(zhí)行一次 SHOW MASTER STATUS 操作,然后將主庫(kù)日志坐標(biāo)存儲(chǔ)在緩存中,作為被修改對(duì)象或者會(huì)話的版本號(hào)。當(dāng)應(yīng)用連接到備庫(kù)時(shí),執(zhí)行 SHOW SLAVE STATUS,并將備庫(kù)上的坐標(biāo)和緩存中的版本號(hào)對(duì)比。如果備庫(kù)比主庫(kù)記錄點(diǎn)更新,就表明備庫(kù)已更新對(duì)應(yīng)數(shù)據(jù),可放心的使用。

實(shí)際上,很多讀寫分離策略都需要監(jiān)控復(fù)制延遲來(lái)決定讀查詢的分配。不過(guò)要注意的是,SHOW SLAVE STATUS 得到的 Seconds_behind_master 列的值并不能精確的表示延遲。我們可以使用 Percona Toolkit 中的 pt-heartbeat 工具更好的監(jiān)控延遲。

1.2 修改 DNS 名

對(duì)于一些比較簡(jiǎn)單的應(yīng)用,可以為不同目的創(chuàng)建 DNS。最簡(jiǎn)單的方法是只讀服務(wù)器擁有一個(gè) DNS 名(read.mysql-db.com),給負(fù)責(zé)寫操作的服務(wù)器起另外一個(gè) DNS 名(write.mysql-db.com)。如果備庫(kù)能夠跟得上主庫(kù),就把只讀 DNS 名指向到備庫(kù),否則,就指向到主庫(kù)。

這種策略非常容易實(shí)現(xiàn),但有個(gè)很大的問(wèn)題是:無(wú)法完全控制 DNS。

修改 DNS 并不是立刻生效的,也不是原子性的。將 DNS 的變化傳遞到整個(gè)網(wǎng)絡(luò)或者網(wǎng)絡(luò)間傳播都需要比較長(zhǎng)的時(shí)間。

DNS 數(shù)據(jù)會(huì)在各個(gè)地方緩存下,它的過(guò)期時(shí)間是建議性質(zhì),而非強(qiáng)制的。

可能需要應(yīng)用或服務(wù)器重啟才能使修改后的 DNS 完全生效。

這種策略較為危險(xiǎn),即使可以通過(guò)修改 /etc/hosts 文件來(lái)避免 DNS 無(wú)法完全控制的問(wèn)題,但仍不失理想策略。

1.3 轉(zhuǎn)移 IP 地址

通過(guò)在服務(wù)器間轉(zhuǎn)移虛擬地址,來(lái)實(shí)現(xiàn)負(fù)載均衡。是不是感覺和修改 DNS 很像?但實(shí)際上完全是兩碼事。轉(zhuǎn)移 IP 地址允許 DNS 名保持不變,我們可以通過(guò) ARP 命令(不了解 ARP,看這里)強(qiáng)制使 IP 地址的更改快速而且原子性的通知到局域網(wǎng)絡(luò)上。

一個(gè)比較方便的技術(shù)是為每個(gè)物理服務(wù)器分配一個(gè)固定的 IP 地址。該 IP 地址固定在服務(wù)器上,不再改變。然后可以為每個(gè)邏輯上的 “服務(wù)”(可以理解為容器)使用一個(gè)虛擬 IP 地址。

這樣,IP 就能夠很方便的在服務(wù)器間轉(zhuǎn)移,無(wú)需重新配置應(yīng)用,實(shí)現(xiàn)也更加容易。

2 引入中間件

上面的策略都是假定應(yīng)用是和 MySQL 服務(wù)器之間連接的,但是許多負(fù)載均衡都會(huì)引入一個(gè)中間件,作為網(wǎng)絡(luò)通信的代理。它一邊接受所有的通信,另一邊將這些請(qǐng)求分發(fā)的指定服務(wù)器上,并將執(zhí)行結(jié)果發(fā)送回請(qǐng)求機(jī)器。圖 2 展示了此種架構(gòu)。

2.1 負(fù)載均衡器

現(xiàn)在有許多負(fù)載均衡硬件和軟件,但很少有專門為 MySQL 服務(wù)器設(shè)計(jì)的。Web 服務(wù)器通常更需要負(fù)載均衡,因此許多多用途的負(fù)載均衡設(shè)備都會(huì)支持 HTTP,而對(duì)其他用途則只有一些很少的基本特性。

MySQL 連接只是正常的 TCP/IP 連接,所以可以在 MySQL 上使用多用途負(fù)載均衡器。但由于缺少 MySQL 專有的特性,因此會(huì)多一些限制:

分發(fā)請(qǐng)求是可能無(wú)法做到很好的負(fù)載均衡。

對(duì) MySQL 會(huì)話支持不足,可能不知道如何把所有從單個(gè) HTTP 會(huì)話發(fā)送的連接請(qǐng)求 “固定” 到一個(gè) MySQL 服務(wù)器上。

連接池和長(zhǎng)連接可能會(huì)阻礙負(fù)載均衡器分發(fā)連接請(qǐng)求。

不能很好的對(duì) MySQL 服務(wù)器做健康和負(fù)載檢查。

2.2 負(fù)載均衡算法

有很多算法用來(lái)決定哪個(gè)服務(wù)器接受下一個(gè)連接。每個(gè)廠商都有各自不同的算法,有以下常用方法:

隨機(jī)分配。從可用的服務(wù)器池中隨機(jī)選擇一個(gè)服務(wù)器來(lái)處理請(qǐng)求。

輪詢。以循環(huán)順序發(fā)送請(qǐng)求到服務(wù)器,例如:A、B、C、A、B、C。

哈希。通過(guò)連接的源 IP 地址進(jìn)行哈希,將其映射到池中的同一個(gè)服務(wù)器上。

最快響應(yīng)。將連接分配給能夠最快處理請(qǐng)求的服務(wù)器上。

最少連接數(shù)。將連接分配給擁有最少活躍連接的服務(wù)器上。

權(quán)重。根據(jù)機(jī)器的性能等條件,給不同機(jī)器配置不同的權(quán)重,以便讓高性能的機(jī)器能處理更多的連接。

上述各種方法沒有最好,只有最適合的,這取決于具體的工作負(fù)載。

另外,我們只描述了即時(shí)處理的算法。但有時(shí)候使用排隊(duì)算法可能會(huì)更有效。例如,一個(gè)算法可能只維護(hù)給定的數(shù)據(jù)庫(kù)服務(wù)器并發(fā)數(shù)量,同一時(shí)刻只允許不超過(guò) N 個(gè)活躍事務(wù)。如果有太多的活躍事務(wù),就將新的請(qǐng)求放到一個(gè)隊(duì)列里,然后讓可用服務(wù)器列表來(lái)處理。

2.3 一主多備間的負(fù)載均衡

最常見的復(fù)制結(jié)構(gòu)就是一個(gè)主庫(kù)加多個(gè)備庫(kù)。這種架構(gòu)的擴(kuò)展性較差,但我們可以通過(guò)一些方法結(jié)合負(fù)載均衡來(lái)獲得更好的效果。

功能分區(qū)。對(duì)于廠家的功能包括報(bào)表、分析、數(shù)據(jù)倉(cāng)庫(kù)以及全文索引,配置一個(gè)或一組備庫(kù)來(lái)擴(kuò)展單個(gè)功能的容量。

保證備庫(kù)跟上主庫(kù)。備庫(kù)存在的問(wèn)題就是臟數(shù)據(jù)。對(duì)于此,我們可以使用函數(shù) MASTER_POS_WAIT() 阻塞主庫(kù)的操作,直到備庫(kù)趕上了設(shè)置的主庫(kù)同步點(diǎn)。另外,我們還可以使用復(fù)制心跳來(lái)檢查延遲情況。

我們不能也不應(yīng)該在應(yīng)用的開始就就想著把架構(gòu)做成阿里那樣的架構(gòu)。最好的方式是實(shí)現(xiàn)應(yīng)用當(dāng)前所明確需要的,并為可能的快速增長(zhǎng)做好預(yù)先規(guī)劃

另外,為可擴(kuò)展性制定一個(gè)數(shù)字目標(biāo)是很有意義的,就像我們?yōu)樾阅苤贫艘粋€(gè)精確目標(biāo),滿足 10K 或 100K 并發(fā)一樣。這樣可以通過(guò)相關(guān)理論避免諸如序列化或交互操作的開銷問(wèn)題帶入到我們的應(yīng)用中。

在 MySQL 擴(kuò)展策略方面,典型的的應(yīng)用在增長(zhǎng)到非常龐大時(shí),通常先從單個(gè)服務(wù)器轉(zhuǎn)移到向外擴(kuò)展的擁有備庫(kù)的架構(gòu),再到數(shù)據(jù)分片或按功能分區(qū)。這里要注意的是,我們不提倡諸如 “盡早分片,盡量分片” 的建議。實(shí)際上,分片很復(fù)雜,而且成本很高,最主要的是很多應(yīng)用可能根本不需要。與其花大成本去分片,還不如先去看看新的硬件和新版本的 MySQL 有哪些變化,也許這些新變化會(huì)給你帶來(lái)驚喜。

總結(jié)

直接連接重 "分離",均衡器和算法有局限。

為擴(kuò)展性量化指標(biāo)。

文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/74287.html

相關(guān)文章

  • MySQL - 擴(kuò)展性 3 負(fù)載均衡眼花繚亂人眼

    摘要:負(fù)載均衡器的作用是將請(qǐng)求的連接路由到最空閑的可用服務(wù)器上。負(fù)載均衡有五個(gè)常見目的可擴(kuò)展性。靈活的負(fù)載均衡方案能夠大幅提高服務(wù)的可用性。連接池和長(zhǎng)連接可能會(huì)阻礙負(fù)載均衡器分發(fā)連接請(qǐng)求。 負(fù)載均衡的基本思路很簡(jiǎn)單: 在一個(gè)服務(wù)器集群中盡可能地的平均負(fù)載量。 基于這個(gè)思路,我們通常的做法是在服務(wù)器前端設(shè)置一個(gè)負(fù)載均衡器。負(fù)載均衡器的作用是將請(qǐng)求的連接路由到最空閑的可用服務(wù)器上。如圖 1,顯示...

    wangdai 評(píng)論0 收藏0
  • 如何應(yīng)對(duì)服務(wù)器壓力?服務(wù)器橫向擴(kuò)展(加機(jī)器)策略漫談

    摘要:均衡負(fù)載多臺(tái)服務(wù)器執(zhí)行程序,將大量請(qǐng)求分?jǐn)偨o多臺(tái)服務(wù)器無(wú)論如何,一臺(tái)服務(wù)器的進(jìn)程是有限的,我們不可能無(wú)限制的把一臺(tái)服務(wù)器的加到個(gè),把內(nèi)存加到,則是不可能的。 在生產(chǎn)環(huán)境中,一個(gè)網(wǎng)站或服務(wù)端應(yīng)用出現(xiàn)響應(yīng)遲緩的時(shí)候,就應(yīng)該考慮是否由于用戶量太多,導(dǎo)致服務(wù)器難以處理的情況,并應(yīng)該考慮花錢來(lái)解決這個(gè)問(wèn)題。當(dāng)然,這里首先會(huì)想到廉價(jià)的解決方式,比如通過(guò)調(diào)整服務(wù)器配置,優(yōu)化代碼性能等,但這些方式技術(shù)...

    he_xd 評(píng)論0 收藏0
  • 如何應(yīng)對(duì)服務(wù)器壓力?服務(wù)器橫向擴(kuò)展(加機(jī)器)策略漫談

    摘要:均衡負(fù)載多臺(tái)服務(wù)器執(zhí)行程序,將大量請(qǐng)求分?jǐn)偨o多臺(tái)服務(wù)器無(wú)論如何,一臺(tái)服務(wù)器的進(jìn)程是有限的,我們不可能無(wú)限制的把一臺(tái)服務(wù)器的加到個(gè),把內(nèi)存加到,則是不可能的。 在生產(chǎn)環(huán)境中,一個(gè)網(wǎng)站或服務(wù)端應(yīng)用出現(xiàn)響應(yīng)遲緩的時(shí)候,就應(yīng)該考慮是否由于用戶量太多,導(dǎo)致服務(wù)器難以處理的情況,并應(yīng)該考慮花錢來(lái)解決這個(gè)問(wèn)題。當(dāng)然,這里首先會(huì)想到廉價(jià)的解決方式,比如通過(guò)調(diào)整服務(wù)器配置,優(yōu)化代碼性能等,但這些方式技術(shù)...

    Anshiii 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<