分布式數據庫的多主，有哪幾種方式?
發布時間：2022.07.20 新聞來源：杭州展特信息科技有限公司 瀏覽次數：
我們知道，當前的分布式數據庫改造中，最大的問題之一是數據庫不能支持多讀多寫模式，所以數據除了做副本之外還必須切片，這導致了業務改造難度加大，同時可靠性降低。另一方面當前很多分布式數據庫，包括社區開源代的MySQL，都宣稱可以支持多主工作模式，可以多讀多寫。 那么這些數據庫所講的多主工作模式各自有哪些特點，又有哪些區別呢。通過本文的探討，希望能獲得一些答案。 講具體實施方案之前，我們要先討論場景。 所謂多主，顧名思義，是相對于主備模式而言的。由于當前開源數據庫里，MySQL仍然使用廣泛，所以我們以MySQL為例討論。MySQL的主備部署模式下，只有主機可以接受讀寫請求。備機通過獲取主機產生的binlog，回放出頁面。所以，備機和主機的數據不是完全實時同步的。實際部署中，大部分業務都部署為直接訪問主機。備機只是作為故障時的接管用，不跑業務。 這會造成資源的浪費，大部分資源要給備機預留，服務器規模急劇變大。另外主從之間的RPO和RTO很難保障，很多基于MySQL實現的數據庫廠商，都在嘗試修改主從同步這部分的實現，通過不斷打補丁的方式，加固可靠性獲得更好的RPO/RTO。 有些業務會把多套上述MySQL主從組串在一起，組成一個分布式解決方案。比如使用分布式中間件，這個選型就比較多了，很多互聯網大廠也都發布過自己的中間件。這些中間件的本質都是通過分庫分表的方式，實現水平擴展。我們抽象一下，大概就是像下面這樣。 在這種模式下，不同的MySQL主從組，對應的是完全不同的內容，所以雖然集群總體規�？梢院艽螅總�主從組其實都是一個孤島。業務層或中間件層要知道某個數據位于哪個孤島，以便能夠正確訪問。而具體到每一個MySQL主從組內，所遇到的問題和上面說的單個主從部署模式其實是完全一樣的。此外這種模式下對于彈性不太友好，因為要增加性能，增加節點，必須調整數據在MySQL各個主從組之間的分布。這是需要業務參與和感知甚至停機的。 所以，實現數據庫多主其實要解決幾個問題，首先是備機要能參與工作，提升資源利用率，而不是閑置在那里浪費資源；還應打破多個主從組之間的孤島，不需要業務或中間件去感知和記錄；進一步地，能夠讓業務無感知的透明擴縮容，不需要為補從或者數據搬遷苦惱；最后還要解決大規模集群便于維護管理的問題。 帶著上面這幾個問題，我們看一下業界都是怎么構建多主的。 為了便于直觀理解，我們先暫時不說數據庫的事，先講一個寫書的故事。 假設我要寫一本書。為了寫書，我聘請了一個叫張三的人，他在自己的電腦上建了一個Word文檔開始寫作。為了在他萬一請假時寫書不中斷，我又請了兩個人張A和張B作為張三的后備。不過張三正常出勤的時候，他倆只能在旁邊看著。為不讓他倆閑著，我讓張A和張B每人也拿一臺電腦，在張三碼字同時，他倆在旁邊各開一個Word照著張三寫的內容完整地抄。每天這仨人“噼啪”敲鍵盤熱火朝天。 不過我這書的內容有點多，張三一個人寫得太慢了。我又聘了一個叫李四的人來幫張三。可張三和李四倆人要各用一臺電腦，沒辦法打開同一個Word文檔一起寫，怎么辦呢？我就切分了一下章節，把一部分章節單獨拆出另一個Word文件，讓李四拿到自己電腦上去寫。為預防李四請假，我本想讓張A和張B在李四請假的時候幫他寫，結果這倆人說他們每天抄張三碼的字都忙不過來，沒空幫李四。我只好另外請了兩個后備李A和李B，每天抄李四的**。 可是出版社那邊還是覺得我的書寫的太慢了，不停催我。我只好又聘用了王五，又再拆分幾個章節讓王五去寫，并請了王A和王B每天照著王五的抄。 就這樣，團隊的人越來越多，有必要請個項目經理了。于是趙六來了。趙六負責整本書章節怎么分，誰來寫。一個10人小團隊運作起來了。 讀者可能已經看出，這張圖和分布式MySQL的基本架構是完全一樣的。 有一天，我跟趙六說，我需要加一段情節進去，這段情節要張三和李四分別配合修改。結果2天過去毫無進展。找趙六問，他說早就把任務傳達下去了；而張三卻說他不知道這事；李四則說稿子早寫完了，也沒人再找過他。我只好把幾個人叫到一起，開會討論半天才解決問題。我叮囑趙六，他要協調好這幾個人的工作，別總出是岔子讓我擦屁股。 但出岔子總是常態。張三請了一天假回來，就和張A吵起來了。張三堅持說他休假前寫過的一段內容被張A篡改了，而且他的電腦本地盤不知怎么壞了，數據全沒了。張A現在寫的東西和他之前的完全不同。張A卻說從沒見過張三寫的這段，這段是自己全新寫的。兩個人吵得我腦袋嗡嗡響。我只好把趙六叫來問怎么回事，趙六卻兩手一攤說這事情他管不了，這是張三和張A之間的事。一聲嘆息……我只好把張三張A張B叫一起又開一下午會。 心累啊，都聘請十個人了，還有專職項目經理。幫我寫一本書而已，為什么卻這么難？ 因為我犯了錯誤。我誤以為一份文檔幾個人沒辦法同時編輯。其實多人在線共享編輯一個文檔的技術早就有了，只是我不知道。當然張三李四王五趙六也沒跟我提起過。 我決定不再讓他們每個人在自己電腦上各寫各的文檔了。我把張三李四王五的文檔合重新整成一份（原本就是一本書啊，我當時為啥要拆開的呢？），還讓他們繼續負責自己的章節，通過共享文檔進行編輯。 同時為了避免再出現電腦本地盤壞的事情，我去買了一套共享存儲，把文檔存在上面了。 聽說了這事，張A、張B、李A、李B、王A、王B都跑來找我。因為他們的工作就是每天照抄文檔，現在文檔全合一起了，他們該抄誰的文檔呢。我說，你們不用再抄文檔了，都先回家吧。但一轉念，張三李四王五這仨人還是有可能請假的。就又說，王A你留下吧。如果他們仨誰請假了，你就繼續替寫**吧。 其余5個人一聽要被解聘都不干了，嚷嚷說萬一張三和王A同時病了怎么辦，沒人頂替。我一想也對，就跟大家說，你們明天開始不用來辦公室了，我也不發錢。萬一人手不夠的時候，你們再隨時來，按天結算。就這樣我的團隊常駐人員一下少了5個。 趙六看走了這么多人有點慌，悄悄問我他自己怎么辦。我拍拍趙六說，項目經理還是需要的，只不過文檔共享了，以后再有要增加故事情節的事，我會直接交給其中一個人去負責，不再會扯皮打架了。趙六你的主要任務，是關注大家工作壓力和狀態，別把一個人累垮了。 這樣，我的項目組人員一下少了一半，也不吵了。一切變得順利多了。 上面其實就是數據庫一致性多主多寫的模型。這是基于Share Everything的多寫，所有數據庫實例共享所有數據進行協同工作，每個實例都可以對接業務，按需操作訪問所有的庫和表。這種方式下可以節省很多數據庫實例，也就能減少很多計算用服務器。 同時由于大家是共享數據，所以協同的難度要遠遠小于分拆成幾個分片，而且需要彈的時候可以直接加實例，應用幾乎無感知，維護管理要簡單很多。 業界還有一種分片方式的多主。他是怎么運作的呢。我們先回到我的寫書工作室。 為了多人一起寫書，大家還是每人拷貝一份文檔各寫各的，不做合并。但趙六幫我發布了一個分工表，每個人都需要知道三個人是如何對文檔分工的。一旦我需要增寫一個新情節的時候，我直接把工作丟給一個人去寫就行（比如張三），然后此人把不屬于自己負責的部分，轉交給另一個人去寫（比如王五），寫完后（張三）交給我。這樣一來張三，李四，王五每個人都可以直接接收寫作任務，私下再根據分工進行交換。我的工作似乎也簡單了，只管下發任務給他們仨就行。 但沒幾天，我檢查書稿發現有一段內容寫錯了。一查，這部分是交給張三負責的，就把張三叫來臭罵了一頓。張三卻覺得不是他的錯，說是李四改錯了。我很惱火，質問道，任務交給你了，你只管自己嗎，就不懂得端到端拉通嗎。 張三一攤手，李四那邊內容我不負責啊，我就傳個話而已，我又不是李四的領導。我瞪了一眼李四。李四馬上彈起來說，我每天從領導你這領一堆活，張三王五還要給我轉一堆活，交代的也不清不楚，我忙不過來。張三王五最近又沒啥事，為什么非都丟給我做。 李四這種借口正要令我發作，我轉頭卻看見張A、張B、李A、李B，幾個人居然在旁邊看報喝茶�；鹁透罅�，你們幾個怎么不去干活？！4個人嬉皮笑臉地說，領導我們要抄張三和李四的書，可他們都在和你開會啊…… 我忍無可忍了，讓這幾個喝茶的走人！張三，李四，王五，以后你們給我互相抄對方的書，我不養這幾個不干活的了。李四一聽直接癱在了地上，領導你是認真的嗎？寫書的活都干不過來了，還要抄書，抄書你當不用花時間的嗎？ 顧不上管昏迷不醒的李四，我喊來趙六，讓他把大家工作拆分細一些，任務均衡一點。趙六卻說，工作再怎么拆，總量也還在那里，這幾個人要互相抄書恐怕真的忙不過來。 我一咬牙，那就再把寫書的章節重新劃分一下，讓更多的人一起寫書、抄書。趙六一聽要加人，嘴上沒說話，心里很復雜。加人？拆好的文檔得重新再拆，分工任務表得重整一遍，我自己得折騰半天不說，大家手上的寫書任務起碼也得停半天啊。關鍵是加人就不吵了嗎？ 這種分片多主，通過分片級的交叉主備，可以解決一部分資源閑置的問題，但備機（也即抄書人）的額外開銷其實還在。同時分片之間邏輯上還是一個個孤島，雖然可以做一些協同，但拉通不徹底。在擴縮容的時候，對業務也不能完全透明。所以對管理和運維而言，簡化程度遠遠不夠。 MySQL自己其實也提供了一種多主方式叫MGR。這種方式的多主又是怎么工作的呢。我們再請來張三李四王五出場，當當當…… 首先，張三李四王五幾個人把文檔合成了一本書，但他們之間不是共享協同編輯，每人都各自拷了一份完整文檔，放在自己電腦本地盤編輯。為了保證大家**別寫亂，我定了個規矩，張三每次改的內容寫完保存前(聰明的讀者，可以想想為什么是寫完保存前而不是張三開始動手寫之前)，都必須通知李四和王五，讓他倆一起修改保存。李四也是一樣，每次修改保存前都得通知給張三和王五一起修改保存。我想這樣做，應該和共享文檔修改沒啥區別，我就不用單獨買個共享存儲了。不就是每天他們費點嘴皮子溝通而已嘛。 但很快，張三就發飆了，他質問李四王五為啥不同步保存他的修改。王五很不解，說明明李四先告訴他要改某一段，張三通知晚了呀。張三火冒三丈，問李四為什么要改這一段，自己寫了一下午都白寫了，本可以下班現在卻要加班。李四也很不爽，大家約定好的保存前才通知，你自己寫的慢怪我咯，我當然可以改啊。趙六跑來找我報告情況，順便還說了一句，老大這事可不歸我管。好吧，一切罪惡我來承擔，我只能出面協調安撫每個小伙伴。 這所謂的多主的模式，孤島倒是打破了，每個人都有一份完整數據了，可資源利用率變得更糟了，存儲多副本沒解決不說，每個人還都處在不停的和別人協商的狀態。一旦沖突了活就算白干，還得業務介入來解決，這種管理維護也是非�？简炄说哪托牡�。所以這種方式用的并不多，用了MGR的人，自有一把辛酸淚。 寫書的故事到此講完了。為了提高多人一起寫書的效率，我們嘗試了一致性多主，分片多主和類MGR多主三種不同的方式。 看到這里大家可能會說，這個故事開頭設定就不太合理，文檔多人共享編輯這個技術早就有了呀，有這種技術，一開始就可以更合理的分工，不需要這么復雜的過程呀。 是的，可現在分布式數據庫改造過程里，不少業務的實際工作方式，其實就和本文的寫書一樣，在摸索中前進。也在嘗試分片多主或者類MGR多主等方式視圖解決問題，但這兩種方式并不能把資源利用發揮到極致，同時管理的開銷也很大。 有小伙伴問，多人寫書能高效合理地分工合作的前提，是借助多人共享編輯技術，數據庫現在有這種“多人共享編輯”方法嗎？這個現在真的已經有了。 華為OceanData解決方案提供了一種基于一致性數據庫多主的方案，并已經商用。所有的數據庫實例全部共享同一份數據，消除多余的副本�；谌值木彺婧腿值馁Y源管理系統，實現了對業務完全透明的多讀多寫。目前已經完全無侵入地支持了MySQL生態，直接以插件方式就能接入現有數據庫集群無需改造�；贕aussDB生態的預計未來也會發布。 OceanData的方案能完美解決資源利用問題，數據孤島問題，業務透明問題，并提供簡便的維護管理。選擇OceanData，讓你的分布式改造不再頭疼，讓真正的多主幫你簡化業務管理的復雜�？靵碓囋嚢伞�分布式數據庫為什么要做多主
從寫一本書開始談起
我犯了什么錯誤，讓寫書這么困難
為了提高工作效率，我的寫書小組變成了多主架構
分片多主是怎么一回事
改進的分片多主，能拯救我嗎
MGR是一種多主解決思路嗎？
分布式數據庫，共享數據多主時代，已經來到