怎樣實(shí)現(xiàn)APP開發(fā)高安全可用性之主從、分片模式？
一、APP開發(fā)經(jīng)驗(yàn)之高可用集群
MongoDB作為NoSQL的代表之，其自身具備了良好的擴(kuò)展性能快速搭建個(gè)高可用、可擴(kuò)展的分布式集群，深圳APP開發(fā)公司下面介紹搭建MongoDB集群的幾種方案。APP開發(fā)高安全可用開發(fā)之主從。
MongoDB采用雙機(jī)主從備份，主節(jié)點(diǎn)的數(shù)據(jù)會(huì)自動(dòng)同步到從節(jié)點(diǎn)，當(dāng)主節(jié)點(diǎn)宕機(jī)后，能切換到從節(jié)點(diǎn)繼續(xù)提供服務(wù)，如圖8-4所示
APP開發(fā)安全高可用經(jīng)驗(yàn)示意圖之8-4MongoDB主從集群架構(gòu)
當(dāng)服務(wù)器訪問(wèn)量上升后，可能單靠臺(tái)主節(jié)點(diǎn)提供服務(wù)會(huì)造成比較大的性能瓶頸。在大多數(shù)的業(yè)務(wù)中，數(shù)據(jù)讀寫的比例會(huì)達(dá)到8:2，甚至是9:1，訪問(wèn)的壓力集中在讀取數(shù)據(jù)方面，當(dāng)一個(gè)節(jié)點(diǎn)無(wú)法承受讀壓力，可以把個(gè)節(jié)點(diǎn)增加為多個(gè)節(jié)點(diǎn)來(lái)減輕單臺(tái)服務(wù)器的負(fù)載。
MongoDB提供了主多從的架構(gòu)來(lái)降低單臺(tái)節(jié)點(diǎn)的負(fù)載，由主節(jié)點(diǎn)負(fù)責(zé)寫數(shù)據(jù)，多個(gè)從節(jié)點(diǎn)負(fù)責(zé)讀數(shù)據(jù)，數(shù)據(jù)從主節(jié)點(diǎn)復(fù)制到多個(gè)從節(jié)點(diǎn)，如圖8-5所示。
APP開發(fā)數(shù)據(jù)庫(kù)高安全可用集群示意圖之8-5MongoDB主從關(guān)系集群
但是MongoDB的t從架構(gòu)有下面3個(gè)問(wèn)題
·當(dāng)主節(jié)點(diǎn)宕機(jī)后，不能支持自動(dòng)切換連接，目前只能手動(dòng)切換。
·主節(jié)點(diǎn)寫壓力過(guò)大的問(wèn)題沒(méi)法解決。
·沒(méi)法支持?jǐn)?shù)據(jù)的路由。
現(xiàn)在MongoDB官方已經(jīng)不推薦使用主從的架構(gòu)，取代方案是接下來(lái)介紹的副本集
APP開發(fā)數(shù)據(jù)庫(kù)集群高安全可用方法之之副本集。
副本集使用多臺(tái)機(jī)器做同份數(shù)據(jù)的異步同步，從而使多臺(tái)服務(wù)器擁有同份數(shù)據(jù)的多個(gè)副本。一臺(tái)服務(wù)器作為主節(jié)點(diǎn)提供寫入服務(wù)，多臺(tái)服務(wù)器作為副本節(jié)點(diǎn)提供讀取服務(wù)，實(shí)現(xiàn)讀寫分離和負(fù)載均衡。當(dāng)主節(jié)點(diǎn)宕機(jī)后，可以在不需要用戶干預(yù)的情況下把臺(tái)副本節(jié)點(diǎn)或其他節(jié)點(diǎn)提升為主節(jié)點(diǎn)，繼續(xù)提供服務(wù)。副本集的架構(gòu)如圖8-6所示。
APP開發(fā)高可用數(shù)據(jù)庫(kù)安全集群經(jīng)驗(yàn)示意圖8-6MongoDB副本集架構(gòu)圖
應(yīng)用服務(wù)器連接到整個(gè)服務(wù)集，并不關(guān)心主服務(wù)器是否掛掉。主節(jié)點(diǎn)負(fù)責(zé)整個(gè)副本集的讀寫，副本節(jié)點(diǎn)從主節(jié)點(diǎn)中同步數(shù)據(jù)。副本集內(nèi)的機(jī)器通過(guò)心跳機(jī)制通信，當(dāng)檢測(cè)到主節(jié)點(diǎn)宕機(jī)時(shí)，副本集內(nèi)的服務(wù)器從剩余的服務(wù)器中選舉臺(tái)新的服務(wù)器作為主節(jié)點(diǎn)繼續(xù)提供服務(wù)。這一切對(duì)于應(yīng)用服務(wù)器來(lái)說(shuō)都是透明的。
MongoDB的副本集是通過(guò)oplog實(shí)現(xiàn)的，主節(jié)點(diǎn)數(shù)據(jù)的修改操作會(huì)被記錄到主節(jié)點(diǎn)的oplog日志，然后副本節(jié)點(diǎn)通過(guò)異步方式復(fù)制主節(jié)點(diǎn)的oplog文件并且將oplog日志應(yīng)用到副本節(jié)點(diǎn)，從而實(shí)現(xiàn)了與主節(jié)點(diǎn)的數(shù)據(jù)同步。副本集啟動(dòng)時(shí)，副本集內(nèi)的服務(wù)器通過(guò)選舉機(jī)制選舉臺(tái)服務(wù)器為主節(jié)點(diǎn)，其他服務(wù)器為副本節(jié)點(diǎn)，選舉過(guò)程如下
l.獲取每臺(tái)服務(wù)器oplog的最后操作時(shí)間。在MongoDB中，修改的數(shù)據(jù)會(huì)先放在匈存中段時(shí)間再寫入硬盤，為了防止未寫入硬盤前因?yàn)閿嚯姷仍蛟斐蓴?shù)據(jù)丟失，所以MongoDB會(huì)把把相關(guān)的數(shù)據(jù)更新操作寫入日士oplog中，以便MongoDB宕機(jī)后恢復(fù)。
2.如果集群中有超過(guò)半的節(jié)點(diǎn)宕機(jī)（包含半），停止選舉。為了避免這個(gè)問(wèn)題，MougoDB官方建議副本集中節(jié)點(diǎn)的個(gè)數(shù)最好為奇數(shù)。
3.如果集辭中服務(wù)器的oplog的最后操作時(shí)間看起來(lái)很舊，就停止選舉等待管理員操作。
4.如果集群內(nèi)部沒(méi)有上面的問(wèn)題，集群內(nèi)的機(jī)器根據(jù)一致性協(xié)議，選舉oplog的最后操作時(shí)間最新的那臺(tái)服務(wù)器為主節(jié)點(diǎn)。
選舉觸發(fā)的條件如下
·副本集剛剛初始化的時(shí)候。
·由于網(wǎng)絡(luò)的原因，副本節(jié)點(diǎn)和主節(jié)點(diǎn)斷開通信。
·主節(jié)點(diǎn)宕機(jī)。
副本集的集群中，有如下4種角色。
·Primary:主節(jié)點(diǎn)，負(fù)責(zé)集群的讀寫
副本節(jié)點(diǎn)，從Priuary的oplog讀取操作日志，以便與Primary保持一致，主要是備份。
·Arbiter:仲裁節(jié)點(diǎn)，其不負(fù)責(zé)任何讀寫，只負(fù)責(zé)主節(jié)點(diǎn)宕機(jī)的時(shí)候的參與選舉。
·Passive Node:除了沒(méi)有被選舉權(quán)，其他同Secondary。
MongoDB官方推薦的集群節(jié)點(diǎn)是奇數(shù)，同時(shí)集群中又提供了仲裁節(jié)點(diǎn)這個(gè)角色，因此為了保證副本集的選舉能順利進(jìn)行，可以在集群中加入一臺(tái)仲裁服務(wù)器，如圖8-7所示。
APP開發(fā)數(shù)據(jù)庫(kù)高安全可用性架構(gòu)圖之圖8-7副本集中加入仲裁節(jié)點(diǎn)的架構(gòu)圖
副本集還有一個(gè)問(wèn)題：如果主節(jié)點(diǎn)讀寫壓力過(guò)大，為了減輕主節(jié)點(diǎn)的壓力，可以設(shè)置讀寫分離，由主節(jié)點(diǎn)負(fù)責(zé)讀寫，副本節(jié)點(diǎn)負(fù)責(zé)讀，仲裁節(jié)點(diǎn)只參與選舉，如圖8-8所示。
APP開發(fā)數(shù)據(jù)庫(kù)安全高可用雞群架購(gòu)示意圖8-8MongoDB讀寫分離的架構(gòu)
二、APP開發(fā)數(shù)據(jù)庫(kù)高安全可用架構(gòu)經(jīng)驗(yàn)之分片
隨著MougoDB數(shù)據(jù)量和訪問(wèn)量持續(xù)增加，單個(gè)集群的性能有可能達(dá)到瓶頸，針對(duì)這種情況，架構(gòu)上一般的處理方法是“分而治之”，把集群中大量的數(shù)據(jù)讀寫請(qǐng)求分散到多個(gè)集群處理，在MySQL中稱為數(shù)據(jù)庫(kù)分片。
MySQL要實(shí)現(xiàn)分庫(kù)功能，還要依賴Amoeba、Cobar或MyCAT等分布式關(guān)系數(shù)據(jù)庫(kù)產(chǎn)品，而MongoDB提供了分片這種原生的機(jī)制來(lái)處理這種“分而治之”的問(wèn)題。
當(dāng)一臺(tái)服務(wù)器的承載能力達(dá)到瓶頸，無(wú)論怎樣提升單機(jī)硬件配置（例如加CPU、內(nèi)存，把硬盤換成SSD）都無(wú)法解決問(wèn)題，這時(shí)最好的策略就是分片，把集中在臺(tái)服務(wù)器上的壓力分散到多臺(tái)。例如，有性能瓶頸的服務(wù)器要處理2TB的數(shù)據(jù)，而把2TB數(shù)據(jù)通過(guò)合理的分片策略分散到兩臺(tái)服務(wù)器上，每臺(tái)服務(wù)器就存儲(chǔ)1TB的數(shù)據(jù)和承擔(dān)半的訪問(wèn)量了。
為了保證每個(gè)分片服務(wù)器能均衡地承擔(dān)訪問(wèn)量，避免有的服務(wù)器承擔(dān)很大的訪問(wèn)量，有的服務(wù)器承擔(dān)很少的訪問(wèn)量，需要在設(shè)置分片規(guī)則時(shí)就仔細(xì)考慮。例如，根據(jù)文檔的id來(lái)分片，就能保證分片是比較均衡的。
MongoDB分片的架構(gòu)圖如圖8-9所示
APP開發(fā)數(shù)據(jù)庫(kù)高安全可用經(jīng)驗(yàn)示意圖之8-9MongoDB分H的架構(gòu)圖
在圖8-9中，MongoDB通過(guò)下面的31'組件實(shí)現(xiàn)分片：
．mougos:作為數(shù)據(jù)庫(kù)集群請(qǐng)求的入口，由于數(shù)據(jù)已經(jīng)分布在shard服務(wù)器上，所有請(qǐng)求經(jīng)過(guò)mongos轉(zhuǎn)發(fā)到shard服務(wù)器上，mongos充當(dāng)路由的角色。mongos是無(wú)狀態(tài)的，因此可以部署多臺(tái)mongos做負(fù)載均衡，防止因?yàn)槟撑_(tái)mongos宕機(jī)導(dǎo)致整個(gè)集群不可用。在某些MougoDB客戶端中，連接MongoDB集群時(shí)支持同時(shí)傳入多個(gè)mongos ip地址作為參數(shù)，在客戶端內(nèi)部實(shí)現(xiàn)負(fù)載均衡和故障移除。
．coufig server:配置服務(wù)器，存儲(chǔ)了所有數(shù)據(jù)庫(kù)元信息（路由、分片）的配置。mongos服務(wù)器自身是沒(méi)有在硬盤上存儲(chǔ)shard服務(wù)器和路由的元信息的，只是在內(nèi)存中存儲(chǔ)過(guò)，當(dāng)mougos服務(wù)器重啟或關(guān)機(jī)后，這些信息會(huì)丟失。因此，為了保證shard服務(wù)器和路由的元信息不丟失，信息會(huì)存儲(chǔ)在coufig server服務(wù)器。當(dāng)mongos第次啟動(dòng)或重啟時(shí)，會(huì)從config server加載配置信息，同時(shí)，當(dāng)配置信息發(fā)生變化時(shí)，mougos服務(wù)器會(huì)接收到最新的變化并更新內(nèi)存中的數(shù)據(jù)。由于配置服務(wù)器中存儲(chǔ)昀信息太重要，萬(wàn)一丟失會(huì)引起整個(gè)集群的崩潰，所以在生產(chǎn)環(huán)境中會(huì)配置多臺(tái)coufig server保證高可用。
·shard server:分片服務(wù)器，分片后保存數(shù)據(jù)的服務(wù)器。
在分片集群中，某個(gè)分片的數(shù)據(jù)只存儲(chǔ)在個(gè)服務(wù)器，如果這個(gè)服務(wù)器宕機(jī)了，那這部分?jǐn)?shù)據(jù)就無(wú)法訪問(wèn)。為了保證分片的高可用，分片服務(wù)器也能使用副本集的架構(gòu)，在生產(chǎn)環(huán)境中，每個(gè)副本集通常是由個(gè)主節(jié)點(diǎn)(Primary)、一個(gè)副本節(jié)點(diǎn)(SecondarV)、一個(gè)仲裁節(jié)點(diǎn)組成(Arbiter)，架構(gòu)如圖8-10所示。
APP開發(fā)數(shù)據(jù)庫(kù)安全高可用示意圖之8-10分片加上副本集的架構(gòu)。
在UCloud上已經(jīng)提供了基于MongoDB的分片集群的云數(shù)據(jù)庫(kù)服務(wù)，UCloud只提供了配置服務(wù)器和分片服務(wù)器組件，mongos還需要用戶在云服務(wù)器上自行搭建，APP開發(fā)公司希望各位在實(shí)際開發(fā)中根據(jù)情況相應(yīng)完善具體細(xì)節(jié)。好了，本文就分享到這里，博納網(wǎng)絡(luò)希望本站這類型的文章能對(duì)您的開發(fā)工作有所幫助，謝謝關(guān)注。
