非常幸运
你好,游客 登錄
背景:
閱讀新聞

搭建高可用的MongoDB集群

[日期:2014-04-25] 來源:CSDN  作者:嚴瀾 [字體: ]

  MongoDB公司原名10gen,創立于2007年,在2013年收到一筆2.31億美元的融資后,公司市值評估已增至10億美元級別,這個高度是知名開源公司Red Hat(創建于1993年)20年的奮斗成果。

  高性能、易擴展一直是MongoDB的立足之本,同時規范的文檔和接口更讓其深受用戶喜愛,這一點從分析DB-Engines的得分結果不難看出——僅僅1年時間,MongoDB就完成了第7名到第五名的提升,得分就從124分上升至214分,上升值是第四名PotgreSQL的兩倍,同時當下與PostgreSQL的得分也只相差16分不到。

  

 

    MongoDB能以如此速度發展,很大程度上歸結于許多傳統關系數據庫已無法應對當下數據處理的擴展性需求,雖然它們久經考驗,并具備不錯的性能及穩定性。然而區別于以往的使用方法,許多NoSQL都有著自己的限制,從而也導致了入門難的問題。這里我們為大家分享 嚴瀾的博文——如何搭建高效的MongoDB集群。

  以下為博文

  深入副本集內部機制

  該系列文章的第一部分介紹了副本集的配置,這個部分將深入研究一下副本集的內部機制。還是帶著副本集的問題來看吧!

  副本集故障轉移,主節點是如何選舉的?能否手動干涉下架某一臺主節點。

  官方說副本集數量最好是奇數,為什么?

  MongDB副本集是如何同步的?如果同步不及時會出現什么情況?會不會出現不一致性?

  MongDB的故障轉移會不會無故自動發生?什么條件會觸發?頻繁觸發可能會帶來系統負載加重?

  Bully算法

  MongDB副本集故障轉移功能得益于它的選舉機制。選舉機制采用了Bully算法,可以很方便從分布式節點中選出主節點。一個分布式集群架構中一般都有一個所謂的主節點,可以有很多用途,比如緩存機器節點元數據,作為集群的訪問入口等等。主節點有就有吧,我們干嘛要什么Bully算法?要明白這個我們先看看這兩種架構:

  指定主節點的架構,這種架構一般都會申明一個節點為主節點,其他節點都是從節點,如我們常用的MySQL就是這樣。但是這樣架構我們在第一節說了整個集群如果主節點掛掉了就得手工操作,上架一個新的主節點或者從從節點恢復數據,不太靈活。

  

mongodb4

 

  不指定主節點,集群中的任意節點都可以成為主節點。MongoDB也就是采用這種架構,一但主節點掛了其他從節點自動接替變成主節點。如下圖:

  

mongodb故障轉移

 

  好了,問題就在這個地方,既然所有節點都是一樣,一但主節點掛了,怎么確定下一個主節點?這就是Bully算法解決的問題。

  那什么是Bully算法,Bully算法是一種協調者(主節點)競選算法,主要思想是集群的每個成員都可以聲明它是主節點并通知其他節點。別的節點可以選擇接受這個聲稱或是拒絕并進入主節點競爭。被其他所有節點接受的節點才能成為主節點。節點按照一些屬性來判斷誰應該勝出。這個屬性可以是一個靜態ID,也可以是更新的度量像最近一次事務ID(最新的節點會勝出)。詳情請參考 NoSQL數據庫分布式算法的協調者競選還有 維基百科的解釋。

  選舉

  那么,MongDB是怎進行選舉的呢?官方這么描述:

  We use a consensus protocol to pick a primary. Exact details will be spared here but that basic process is:

  get maxLocalOpOrdinal from each server.

  if a majority of servers are not up (from this server’s POV), remain in Secondary mode and stop.

  if the last op time seems very old, stop and await human intervention.

  else, using a consensus protocol, pick the server with the highest maxLocalOpOrdinal as the Primary.

  大致翻譯過來為使用一致協議選擇主節點。基本步驟為:

  得到每個服務器節點的最后操作時間戳。每個MongDB都有oplog機制記錄本機操作,方便和主服務器進行對比數據是否同步還可以用于錯誤恢復。

  如果集群中大部分服務器down機了,保留活著的節點都為secondary狀態并停止,不選舉了。

  如果集群中選舉出來的主節點或者所有從節點最后一次同步時間看起來很舊,停止選舉等待人來操作。

  如果上面都沒有問題就選擇最后操作時間戳最新(保證數據是最新的)的服務器節點作為主節點。

  這里提到了一個一致協議(其實就是bully算法),這個和數據庫的一致性協議還是有些區別,一致協議主要強調的是通過一些機制保證大家達成共識;而一致性協議強調的是操作的順序一致性,比如同時讀寫一個數據會不會出現臟數據。一致協議在分布式里有一個經典的算法叫“Paxos算法”,后續再介紹。

  上面有個問題,就是所有從節點的最后操作時間都是一樣怎么辦?就是誰先成為主節點的時間最快就選誰。

  選舉觸發條件

  選舉不是什么時刻都會被觸發的,有以下情況可以觸發。

  初始化一個副本集時。

  副本集和主節點斷開連接,可能是網絡問題。

  主節點掛掉。

  選舉還有個前提條件,參與選舉的節點數量必須大于副本集總節點數量的一半,如果已經小于一半了所有節點保持只讀狀態。日志將會出現:

  can't see a majority of the set, relinquishing primary

  1. 主節點掛掉能否人為干預?答案是肯定的。

  可以通過replSetStepDown命令下架主節點。這個命令可以登錄主節點使用

  db.adminCommand({replSetStepDown : 1})

  如果殺不掉可以使用強制開關

  db.adminCommand({replSetStepDown : 1, force : true})

  或者使用 rs.stepDown(120)也可以達到同樣的效果,中間的數字指不能在停止服務這段時間成為主節點,單位為秒。

  2. 設置一個從節點有比主節點有更高的優先級。

  先查看當前集群中優先級,通過rs.conf()命令,默認優先級為1是不顯示的,這里標示出來

  [java] view plaincopyrs.conf();

  [java] view plaincopy{

  "_id" : "rs0",

  "version" : 9,

  "members" : [

  {

  "_id" : 0,

  "host" : "192.168.1.136:27017" },

  {

  "_id" : 1,

  "host" : "192.168.1.137:27017" },

  {

  "_id" : 2,

  "host" : "192.168.1.138:27017" }

  ]

  }

  如果不想讓一個從節點成為主節點可以怎么操作?

  使用rs.freeze(120)凍結指定的秒數不能選舉成為主節點。

  按照上一篇設置節點為Non-Voting類型。

  當主節點不能和大部分從節點通訊。把主機節點網線拔掉,嘿嘿:)

  優先級還可以這么用,如果我們不想設置什么hidden節點,就用secondary類型作為備份節點也不想讓他成為主節點怎么辦?看下圖,共三個節點分布在兩個數據中心,數據中心2的節點設置優先級為0不能成為主節點,但是可以參與選舉、數據復制。架構還是很靈活吧!

  

deeprepset1

 

  奇數

  官方推薦副本集的成員數量為奇數,最多12個副本集節點,最多7個節點參與選舉。最多12個副本集節點是因為沒必要一份數據復制那么多份,備份太多反而增加了網絡負載和拖慢了集群性能;而最多7個節點參與選舉是因為內部選舉機制節點數量太多就會導致1分鐘內還選不出主節點,凡事只要適當就好。這個“12”、“7”數字還好,通過他們官方經過性能測試定義出來可以理解。具體還有哪些限制參考官方文檔 《 MongoDB Limits and Thresholds 》。 但是這里一直沒搞懂整個集群為什么要奇數,通過測試集群的數量為偶數也是可以運行的,參考這個文章http://www.itpub.net/thread-1740982-1-1.html。后來突然看了一篇 stackoverflow的文章終于頓悟了,mongodb本身設計的就是一個可以跨IDC的分布式數據庫,所以我們應該把它放到大的環境來看。

  假設四個節點被分成兩個IDC,每個IDC各兩臺機器,如下圖。但這樣就出現了個問題,如果兩個IDC網絡斷掉,這在廣域網上很容易出現的問題,在上面選舉中提到只要主節點和集群中大部分節點斷開鏈接就會開始一輪新的選舉操作,不過MongoDB副本集兩邊都只有兩個節點,但是選舉要求參與的節點數量必須大于一半,這樣所有集群節點都沒辦法參與選舉,只會處于只讀狀態。但是如果是奇數節點就不會出現這個問題,假設3個節點,只要有2個節點活著就可以選舉,5個中的3個,7個中的4個……

  

deeprepset2

 

  心跳

  綜上所述,整個集群需要保持一定的通信才能知道哪些節點活著哪些節點掛掉。MongoDB節點會向副本集中的其他節點每兩秒就會發送一次pings包,如果其他節點在10秒鐘之內沒有返回就標示為不能訪問。每個節點內部都會維護一個狀態映射表,表明當前每個節點是什么角色、日志時間戳等關鍵信息。如果是主節點,除了維護映射表外還需要檢查自己能否和集群中內大部分節點通訊,如果不能則把自己降級為secondary只讀節點。

  同步

  副本集同步分為初始化同步和keep復制。初始化同步指全量從主節點同步數據,如果主節點數據量比較大同步時間會比較長。而keep復制指初始化同步過后,節點之間的實時同步一般是增量同步。初始化同步不只是在第一次才會被處罰,有以下兩種情況會觸發:

  secondary第一次加入,這個是肯定的。

  secondary落后的數據量超過了oplog的大小,這樣也會被全量復制。

  那什么是oplog的大小?前面說過oplog保存了數據的操作記錄,secondary復制oplog并把里面的操作在secondary執行一遍。但是oplog也是mongodb的一個集合,保存在local.oplog.rs里;然而這個oplog是一個capped collection,也就是固定大小的集合,新數據加入超過集合的大小會覆蓋,所以這里需要注意,跨IDC的復制要設置合適的oplogSize,避免在生產環境經常產生全量復制。oplogSize 可以通過–oplogSize設置大小,對于Linux 和Windows 64位,oplog size默認為剩余磁盤空間的5%。

  同步也并非只能從主節點同步,假設集群中3個節點,節點1是主節點在IDC1,節點2、節點3在IDC2,初始化節點2、節點3會從節點1同步數據。后面節點2、節點3會使用就近原則從當前IDC的副本集中進行復制,只要有一個節點從IDC1的節點1復制數據。

  設置同步還要注意以下幾點:

  secondary不會從delayed和hidden成員上復制數據。

  只要是需要同步,兩個成員的buildindexes必須要相同無論是否是true和false。buildindexes主要用來設置是否這個節點的數據用于查詢,默認為true。

  如果同步操作30秒都沒有反應,則會重新選擇一個節點進行同步。

  到此,本章前面提到的問題全部解決了,不得不說MongoDB的設計還真是強大!

  后續繼續解決上一節這幾個問題:

  主節點掛了能否自動切換連接?目前需要手工切換。

  主節點的讀寫壓力過大如何解決?

  在系統早期,數據量還小的時候不會引起太大的問題,但是隨著數據量持續增多,后續遲早會出現一臺機器硬件瓶頸問題的。而MongoDB主打的就是海量數據架構,他不能解決海量數據怎么行!“分片”就用這個來解決這個問題。

  傳統數據庫怎么做海量數據讀寫?其實一句話概括:分而治之。上圖看看就清楚了,如下TaoBao岳旭強提到的架構圖:

  

fenpian1

 

  上圖中有個TDDL,是TaoBao的一個數據訪問層組件,他主要的作用是SQL解析、路由處理。根據應用的請求的功能解析當前訪問的sql判斷是在哪個業務數據庫、哪個表訪問查詢并返回數據結果。具體如圖:

  

fenpian2

 

  說了這么多傳統數據庫的架構,那NoSQL怎么去做到了這些呢?MySQL要做到自動擴展需要加一個數據訪問層用程序去擴展,數據庫的增加、刪除、備份還需要程序去控制。一但數據庫的節點一多,要維護起來也是非常頭疼的。不過MongoDB所有的這一切通過他自己的內部機制就可以搞定!還是上圖看看MongoDB通過哪些機制實現路由、分片:

  

fenpian3

 

  從圖中可以看到有四個組件:mongos、config server、shard、replica set。

  mongos,數據庫集群請求的入口,所有的請求都通過mongos進行協調,不需要在應用程序添加一個路由選擇器,mongos自己就是一個請求分發中心,它負責把對應的數據請求請求轉發到對應的shard服務器上。在生產環境通常有多mongos作為請求的入口,防止其中一個掛掉所有的mongodb請求都沒有辦法操作。

  config server,顧名思義為配置服務器,存儲所有數據庫元信息(路由、分片)的配置。mongos本身沒有物理存儲分片服務器和數據路由信息,只是緩存在內存里,配置服務器則實際存儲這些數據。mongos第一次啟動或者關掉重啟就會從 config server 加載配置信息,以后如果配置服務器信息變化會通知到所有的 mongos 更新自己的狀態,這樣 mongos 就能繼續準確路由。在生產環境通常有多個 config server 配置服務器,因為它存儲了分片路由的元數據,這個可不能丟失!就算掛掉其中一臺,只要還有存貨, mongodb集群就不會掛掉。

  shard,這就是傳說中的分片了。上面提到一個機器就算能力再大也有天花板,就像軍隊打仗一樣,一個人再厲害喝血瓶也拼不過對方的一個師。俗話說三個臭皮匠頂個諸葛亮,這個時候團隊的力量就凸顯出來了。在互聯網也是這樣,一臺普通的機器做不了的多臺機器來做,如下圖:

  

fenpian4

 

  一臺機器的一個數據表 Collection1 存儲了 1T 數據,壓力太大了!在分給4個機器后,每個機器都是256G,則分攤了集中在一臺機器的壓力。也許有人問一臺機器硬盤加大一點不就可以了,為什么要分給四臺機器呢?不要光想到存儲空間,實際運行的數據庫還有硬盤的讀寫、網絡的IO、CPU和內存的瓶頸。在mongodb集群只要設置好了分片規則,通過mongos操作數據庫就能自動把對應的數據操作請求轉發到對應的分片機器上。在生產環境中分片的片鍵可要好好設置,這個影響到了怎么把數據均勻分到多個分片機器上,不要出現其中一臺機器分了1T,其他機器沒有分到的情況,這樣還不如不分片!

  replica set,上兩節已經詳細講過了這個東東,怎么這里又來湊熱鬧!其實上圖4個分片如果沒有 replica set 是個不完整架構,假設其中的一個分片掛掉那四分之一的數據就丟失了,所以在高可用性的分片架構還需要對于每一個分片構建 replica set 副本集保證分片的可靠性。生產環境通常是 2個副本 + 1個仲裁。

  說了這么多,還是來實戰一下如何搭建高可用的mongodb集群:

  首先確定各個組件的數量,mongos 3個, config server 3個,數據分3片 shard server 3個,每個shard 有一個副本一個仲裁也就是 3 * 2 = 6 個,總共需要部署15個實例。這些實例可以部署在獨立機器也可以部署在一臺機器,我們這里測試資源有限,只準備了 3臺機器,在同一臺機器只要端口不同就可以,看一下物理部署圖:

  

fenpian5

 

  架構搭好了,安裝軟件!

  1. 準備機器,IP分別設置為: 192.168.0.136、192.168.0.137、192.168.0.138。

  2. 分別在每臺機器上建立mongodb分片對應測試文件夾。

  #存放mongodb數據文件

  mkdir -p /data/mongodbtest

  #進入mongodb文件夾

  cd /data/mongodbtest

  3. 下載mongodb的安裝程序包

  wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.4.8.tgz

  #解壓下載的壓縮包

  tar xvzf mongodb-linux-x86_64-2.4.8.tgz

  4. 分別在每臺機器建立mongos 、config 、 shard1 、shard2、shard3 五個目錄。

  因為mongos不存儲數據,只需要建立日志文件目錄即可。

  #建立mongos目錄

  mkdir -p /data/mongodbtest/mongos/log

  #建立config server 數據文件存放目錄

  mkdir -p /data/mongodbtest/config/data

  #建立config server 日志文件存放目錄

  mkdir -p /data/mongodbtest/config/log

  #建立config server 日志文件存放目錄

  mkdir -p /data/mongodbtest/mongos/log

  #建立shard1 數據文件存放目錄

  mkdir -p /data/mongodbtest/shard1/data

  #建立shard1 日志文件存放目錄

  mkdir -p /data/mongodbtest/shard1/log

  #建立shard2 數據文件存放目錄

  mkdir -p /data/mongodbtest/shard2/data

  #建立shard2 日志文件存放目錄

  mkdir -p /data/mongodbtest/shard2/log

  #建立shard3 數據文件存放目錄

  mkdir -p /data/mongodbtest/shard3/data

  #建立shard3 日志文件存放目錄

  mkdir -p /data/mongodbtest/shard3/log

  5. 規劃5個組件對應的端口號,由于一個機器需要同時部署 mongos、config server 、shard1、shard2、shard3,所以需要用端口進行區分。

  這個端口可以自由定義,在本文 mongos為 20000, config server 為 21000, shard1為 22001 , shard2為22002, shard3為22003.

  6. 在每一臺服務器分別啟動配置服務器。

  /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongod --configsvr --dbpath /data/mongodbtest/config/data --port 21000 --logpath /data/mongodbtest/config/log/config.log --fork

  7. 在每一臺服務器分別啟動mongos服務器。

  /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongos --configdb 192.168.0.136:21000,192.168.0.137:21000,192.168.0.138:21000 --port 20000 --logpath /data/mongodbtest/mongos/log/mongos.log --fork

  8. 配置各個分片的副本集。

  #在每個機器里分別設置分片1服務器及副本集shard1

  /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongod --shardsvr --replSet shard1 --port 22001 --dbpath /data/mongodbtest/shard1/data --logpath /data/mongodbtest/shard1/log/shard1.log --fork --nojournal --oplogSize 10

  為了快速啟動并節約測試環境存儲空間,這里加上 nojournal 是為了關閉日志信息,在我們的測試環境不需要初始化這么大的redo日志。同樣設置 oplogsize是為了降低 local 文件的大小,oplog是一個固定長度的 capped collection,它存在于”local”數據庫中,用于記錄Replica Sets操作日志。注意,這里的設置是為了測試!

  #在每個機器里分別設置分片2服務器及副本集shard2

  /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongod --shardsvr --replSet shard2 --port 22002 --dbpath /data/mongodbtest/shard2/data --logpath /data/mongodbtest/shard2/log/shard2.log --fork --nojournal --oplogSize 10

  #在每個機器里分別設置分片3服務器及副本集shard3

  /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongod --shardsvr --replSet shard3 --port 22003 --dbpath /data/mongodbtest/shard3/data --logpath /data/mongodbtest/shard3/log/shard3.log --fork --nojournal --oplogSize 10

  分別對每個分片配置副本集,深入了解副本集參考本系列前幾篇文章。

  任意登陸一個機器,比如登陸192.168.0.136,連接MongoDB

  #設置第一個分片副本集

  /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongo 127.0.0.1:22001

  #使用admin數據庫

  use admin

  #定義副本集配置

  config = { _id:"shard1", members:[

  {_id:0,host:"192.168.0.136:22001"},

  {_id:1,host:"192.168.0.137:22001"},

  {_id:2,host:"192.168.0.138:22001",arbiterOnly:true}

  ]

  }

  #初始化副本集配置

  rs.initiate(config);

  #設置第二個分片副本集

  /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongo 127.0.0.1:22002

  #使用admin數據庫

  use admin

  #定義副本集配置

  config = { _id:"shard2", members:[

  {_id:0,host:"192.168.0.136:22002"},

  {_id:1,host:"192.168.0.137:22002"},

  {_id:2,host:"192.168.0.138:22002",arbiterOnly:true}

  ]

  }

  #初始化副本集配置

  rs.initiate(config);

  #設置第三個分片副本集

  /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongo 127.0.0.1:22003

  #使用admin數據庫

  use admin

  #定義副本集配置

  config = { _id:"shard3", members:[

  {_id:0,host:"192.168.0.136:22003"},

  {_id:1,host:"192.168.0.137:22003"},

  {_id:2,host:"192.168.0.138:22003",arbiterOnly:true}

  ]

  }

  #初始化副本集配置

  rs.initiate(config);

  9. 目前搭建了mongodb配置服務器、路由服務器,各個分片服務器,不過應用程序連接到 mongos 路由服務器并不能使用分片機制,還需要在程序里設置分片配置,讓分片生效。

  #連接到mongos /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongo 127.0.0.1:20000

  #使用admin數據庫 user admin

  #串聯路由服務器與分配副本集1

  db.runCommand( { addshard : "shard1/192.168.0.136:22001,192.168.0.137:22001,192.168.0.138:22001"});

  如里shard是單臺服務器,用 db.runCommand( { addshard : “ [: ]” } )這樣的命令加入,如果shard是副本集,用db.runCommand( { addshard : “replicaSetName/ [:port][,serverhostname2[:port],…]” });這樣的格式表示 。

  #串聯路由服務器與分配副本集2

  db.runCommand( { addshard : "shard2/192.168.0.136:22002,192.168.0.137:22002,192.168.0.138:22002"});

  #串聯路由服務器與分配副本集3

  db.runCommand( { addshard : "shard3/192.168.0.136:22003,192.168.0.137:22003,192.168.0.138:22003"});

  #查看分片服務器的配置

  db.runCommand( { listshards : 1 } );

  #內容輸出

  [plain] view plaincopy{

  "shards" : [

  {

  "_id" : "shard1",

  "host" : "shard1/192.168.0.136:22001,192.168.0.137:22001"

  },

  {

  "_id" : "shard2",

  "host" : "shard2/192.168.0.136:22002,192.168.0.137:22002"

  },

  {

  "_id" : "shard3",

  "host" : "shard3/192.168.0.136:22003,192.168.0.137:22003"

  }

  ],

  "ok" : 1

  }

  因為192.168.0.138是每個分片副本集的仲裁節點,所以在上面結果沒有列出來。

  10. 目前配置服務、路由服務、分片服務、副本集服務都已經串聯起來了,但我們的目的是希望插入數據,數據能夠自動分片,就差那么一點點,一點點。。。

  連接在mongos上,準備讓指定的數據庫、指定的集合分片生效。

  #指定testdb分片生效

  db.runCommand( { enablesharding :"testdb"});

  #指定數據庫里需要分片的集合和片鍵

  db.runCommand( { shardcollection : "testdb.table1",key : {id: 1} } )

  我們設置testdb的 table1 表需要分片,根據 id 自動分片到 shard1 ,shard2,shard3 上面去。要這樣設置是因為不是所有mongodb 的數據庫和表 都需要分片!

  11. 測試分片配置結果。

  #連接mongos服務器

  /data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongo 127.0.0.1:20000

  #使用testdb use testdb;

  #插入測試數據

  for (var i = 1; i <= 100000; i++)

  db.table1.save({id:i,"test1":"testval1"});

  #查看分片情況如下,部分無關信息省掉了

  db.table1.stats();

  [java] view plaincopy{

  "sharded" : true,

  "ns" : "testdb.table1",

  "count" : 100000,

  "numExtents" : 13,

  "size" : 5600000,

  "storageSize" : 22372352,

  "totalIndexSize" : 6213760,

  "indexSizes" : {

  "_id_" : 3335808,

  "id_1" : 2877952

  },

  "avgObjSize" : 56,

  "nindexes" : 2,

  "nchunks" : 3,

  "shards" : {

  "shard1" : {

  "ns" : "testdb.table1",

  "count" : 42183,

  "size" : 0,

  ...

  "ok" : 1

  },

  "shard2" : {

  "ns" : "testdb.table1",

  "count" : 38937,

  "size" : 2180472,

  ...

  "ok" : 1

  },

  "shard3" : {

  "ns" : "testdb.table1",

  "count" :18880,

  "size" : 3419528,

  ...

  "ok" : 1

  }

  },

  "ok" : 1

  }

  可以看到數據分到3個分片,各自分片數量為: shard1 “count” : 42183,shard2 “count”: 38937,shard3 “count” : 18880。已經成功了!不過分的好像不是很均勻,所以這個分片還是很有講究的,后續再深入討論。

  12. Java程序調用分片集群,因為我們配置了三個mongos作為入口,就算其中哪個入口掛掉了都沒關系,使用集群客戶端程序如下:[java] view plaincopypublic class TestMongoDBShards { public static void main(String[] args)

  { try { List addresses = new ArrayList();

  ServerAddress address1 = new ServerAddress("192.168.0.136" , 20000); ServerAddress

  address2 = new ServerAddress("192.168.0.137" , 20000); ServerAddress address3

  = new ServerAddress("192.168.0.138" , 20000); addresses.add(address1);

  addresses.add(address2); addresses.add(address3); MongoClient client =

  new MongoClient(addresses); DB db = client.getDB( "testdb" ); DBCollection

  coll = db.getCollection( "table1" ); BasicDBObject object = new BasicDBObject();

  object.append( "id" , 1); DBObject dbObject = coll.findOne(object); System.

  out .println(dbObject); } catch (Exception e) { e.printStackTrace(); }

  } }

  整個分片集群搭建完了,思考一下我們這個架構是不是足夠好呢?其實還有很多地方需要優化,比如我們把所有的仲裁節點放在一臺機器,其余兩臺機器承擔了全部讀寫操作,但是作為仲裁的192.168.0.138相當空閑。讓機器3 192.168.0.138多分擔點責任吧!架構可以這樣調整,把機器的負載分的更加均衡一點,每個機器既可以作為主節點、副本節點、仲裁節點,這樣壓力就會均衡很多了,如圖:

  

fenpian6

 

  當然生產環境的數據遠遠大于當前的測試數據,大規模數據應用情況下我們不可能把全部的節點像這樣部署,硬件瓶頸是硬傷,只能擴展機器。要用好mongodb還有很多機制需要調整,不過通過這個東東我們可以快速實現高可用性、高擴展性,所以它還是一個非常不錯的Nosql組件。

  再看看我們使用的mongodb java 驅動客戶端 MongoClient(addresses),這個可以傳入多個mongos 的地址作為mongodb集群的入口,并且可以實現自動故障轉移,但是負載均衡做的好不好呢?打開源代碼查看:

  

fenpian7

 

   它的機制是選擇一個ping 最快的機器來作為所有請求的入口,如果這臺機器掛掉會使用下一臺機器。那這樣。。。。肯定是不行的!萬一出現雙十一這樣的情況所有請求集中發送到這一臺機器,這臺機器很有可能掛掉。一但掛掉了,按照它的機制會轉移請求到下臺機器,但是這個壓力總量還是沒有減少啊!下一臺還是可能崩潰,所以這個架構還有漏洞!限于文章篇幅,請待后續解決。

推薦 打印 | 錄入: | 閱讀:
相關新聞      
本文評論   
評論聲明
  • 尊重網上道德,遵守中華人民共和國的各項有關法律法規
  • 承擔一切因您的行為而直接或間接導致的民事或刑事法律責任
  • 本站管理人員有權保留或刪除其管轄留言中的任意內容
  • 本站有權在網站內轉載或引用您的評論
  • 參與本評論即表明您已經閱讀并接受上述條款
非常幸运