<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    2. 

    <del id="afajh"><form id="afajh"></form></del>
    

    5. 

        1. <th id="afajh"><progress id="afajh"></progress></th>

          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>
          運維思考：一文聊聊高可用的“異地多活”架構設計
          共
                5077字，需瀏覽
                    11分鐘
                
           ·
          2022-10-14 21:33
          前言
          后臺服務可以劃分為兩類，有狀態(tài)和無狀態(tài)。高可用對于無狀態(tài)的應用來說是比較簡單的，無狀態(tài)的應用，只需要通過 F5 或者任何代理的方式就可以很好的解決。后文描述的主要是針對有狀態(tài)的服務進行分析。
          服務端進行狀態(tài)維護主要是通過磁盤或內(nèi)存進行保存，比如 MySQL 數(shù)據(jù)庫，redis 等內(nèi)存數(shù)據(jù)庫。除了這兩種類型的維護方式，還有 jvm 的內(nèi)存的狀態(tài)維持，但jvm的狀態(tài)生命周期通常很短。
          高可用
          1、高可用的一些解決方案
          高可用，從發(fā)展來看，大致經(jīng)過了這幾個過程：
          • 冷備
          • 雙機熱備
          • 同城雙活
          • 異地雙活
          • 異地多活
          在聊異地多活的時候，還是先看一些其他的方案，這有利于我們理解很多設計的緣由。
          冷備
          冷備，通過停止數(shù)據(jù)庫對外服務的能力，通過文件拷貝的方式將數(shù)據(jù)快速進行備份歸檔的操作方式。簡而言之，冷備，就是復制粘貼，在 linux 上通過 cp 命令就可以很快完成?？梢酝ㄟ^人為操作，或者定時腳本進行。有如下好處：
          • 簡單
          • 快速備份（相對于其他備份方式）
          • 快速恢復。只需要將備份文件拷貝回工作目錄即完成恢復過程（亦或者修改數(shù)據(jù)庫的配置，直接將備份的目錄修改為數(shù)據(jù)庫工作目錄）。更甚，通過兩次mv命令就可瞬間完成恢復。
          • 可以按照時間點恢復。比如，幾天前發(fā)生的拼多多優(yōu)惠券漏洞被人刷掉很多錢，可以根據(jù)前一個時間點進行還原，“挽回損失”。
          以上的好處，對于以前的軟件來說，是很好的方式。但是對于現(xiàn)如今的很多場景，已經(jīng)不好用了，因為：
          • 服務需要停機。n個9肯定無法做到了。然后，以前我們的停機冷備是在凌晨沒有人使用的時候進行，但是現(xiàn)在很多的互聯(lián)網(wǎng)應用已經(jīng)是面向全球了，所以，任何時候都是有人在使用的。
          • 數(shù)據(jù)丟失。如果不采取措施，那么在完成了數(shù)據(jù)恢復后，備份時間點到還原時間內(nèi)的數(shù)據(jù)會丟失。傳統(tǒng)的做法，是冷備還原以后，通過數(shù)據(jù)庫日志手動恢復數(shù)據(jù)。比如通過 redo日志，更甚者，我還曾經(jīng)通過業(yè)務日志去手動回放請求恢復數(shù)據(jù)?；謴褪菢O大的體力活，錯誤率高，恢復時間長。
          • 冷備是全量備份。全量備份會造成磁盤空間浪費，以及容量不足的問題，只能通過將備份拷貝到其他移動設備上解決。所以，整個備份過程的時間其實更長了。
          • 想象一下每天拷貝幾個T的數(shù)據(jù)到移動硬盤上，需要多少移動硬盤和時間。并且，全量備份是無法定制化的，比如只備份某一些表，是無法做到的。
          如何權衡冷備的利弊，是每個業(yè)務需要考慮的。
          雙機熱備
          熱備，和冷備比起來，主要的差別是不用停機，一邊備份一邊提供服務。但還原的時候還是需要停機的。由于我們討論的是和存儲相關的，所以不將共享磁盤的方式看作雙機熱備。
          Active/Standby模式
          相當于1主1從，主節(jié)點對外提供服務，從節(jié)點作為backup。通過一些手段將數(shù)據(jù)從主節(jié)點同步到從節(jié)點，當故障發(fā)生時，將從節(jié)點設置為工作節(jié)點。數(shù)據(jù)同步的方式可以是偏軟件層面，也可以是偏硬件層面的。偏軟件層面的，比如mysql的master/slave方式，通過同步binlog的方式；sqlserver的訂閱復制方式。偏硬件層面，通過扇區(qū)和磁盤的攔截等鏡像技術，將數(shù)據(jù)拷貝到另外的磁盤。偏硬件的方式，也被叫做數(shù)據(jù)級災備；偏軟件的，被叫做應用級災備。后文談得更多的是應用級災備。
          10T 技術資料限時領取！包括但不限于：Linux、虛擬化、容器、云計算、網(wǎng)絡、Python、Go 等。在開源Linux公眾號內(nèi)回復「10T」，即可免費獲??！
          雙機互備
          本質上還是Active/Standby，只是互為主從而已。雙機互備并不能工作于同一個業(yè)務，只是在服務器角度來看，更好的壓榨了可用的資源。比如，兩個業(yè)務分別有庫A和B，通過兩個機器P和Q進行部署。那么對于A業(yè)務，P主Q從，對于B業(yè)務，Q主P從。整體上看起來是兩個機器互為主備。這種架構下，讀寫分離是很好的，單寫多讀，減少沖突又提高了效率。
          其他的高可用方案還可以參考各類數(shù)據(jù)庫的多種部署模式，比如mysql的主從、雙主多從、MHA；redis 的主從，哨兵，cluster 等等。
          同城雙活
          前面講到的幾種方案，基本都是在一個局域網(wǎng)內(nèi)進行的。業(yè)務發(fā)展到后面，有了同城多活的方案。和前面比起來，不信任的粒度從機器轉為了機房。這種方案可以解決某個IDC機房整體掛掉的情況（停電，斷網(wǎng)等）。
          同城雙活其實和前文提到的雙機熱備沒有本質的區(qū)別，只是“距離”更遠了，基本上還是一樣（同城專線網(wǎng)速還是很快的）。雙機熱備提供了災備能力，雙機互備避免了過多的資源浪費。
          在程序代碼的輔助下，有的業(yè)務還可以做到真正的雙活，即同一個業(yè)務，雙主，同時提供讀寫，只要處理好沖突的問題即可。需要注意的是，并不是所有的業(yè)務都能做到。
          業(yè)界更多采用的是兩地三中心的做法。遠端的備份機房能更大的提供災備能力，能更好的抵抗地震，恐襲等情況。雙活的機器必須部署到同城，距離更遠的城市作為災備機房。災備機房是不對外提供服務的，只作為備份使用，發(fā)生故障了才切流量到災備機房；或者是只作為數(shù)據(jù)備份。原因主要在于：距離太遠，網(wǎng)絡延遲太大。
          圖1 兩地三中心
          如上圖，用戶流量通過負載均衡，將服務A的流量發(fā)送到IDC1，服務器集A；將服務B的流量發(fā)送到IDC2，服務器B；同時，服務器集a和b分別從A和B進行同城專線的數(shù)據(jù)同步，并且通過長距離的異地專線往IDC3進行同步。當任何一個IDC當機時，將所有流量切到同城的另一個IDC機房，完成了failover。
          當城市1發(fā)生大面積故障時，比如發(fā)生地震導致IDC1和2同時停止工作，則數(shù)據(jù)在IDC3得以保全。同時，如果負載均衡仍然有效，也可以將流量全部轉發(fā)到IDC3中。不過，此時IDC3機房的距離非常遠，網(wǎng)絡延遲變得很嚴重，通常用戶的體驗的會受到嚴重影響的。
          圖2 兩地三中心主從模式
          上圖是一種基于Master-Slave模式的兩地三中心示意圖。城市1中的兩個機房作為1主1從，異地機房作為從。也可以采用同城雙主+keepalived+vip的方式，或者MHA的方式進行failover。但城市2不能（最好不要）被選擇為Master。
          3、異地雙活
          同城雙活可以應對大部分的災備情況，但是碰到大面積停電，或者自然災害的時候，服務依然會中斷。對上面的兩地三中心進行改造，在異地也部署前端入口節(jié)點和應用，在城市1停止服務后將流量切到城市2，可以在降低用戶體驗的情況下，進行降級。但用戶的體驗下降程度非常大。
          所以大多數(shù)的互聯(lián)網(wǎng)公司采用了異地雙活的方案。
          圖3 簡單的異地雙活示意圖
          上圖是一個簡單的異地雙活的示意圖。流量經(jīng)過LB后分發(fā)到兩個城市的服務器集群中，服務器集群只連接本地的數(shù)據(jù)庫集群，只有當本地的所有數(shù)據(jù)庫集群均不能訪問，才failover到異地的數(shù)據(jù)庫集群中。
          在這種方式下，由于異地網(wǎng)絡問題，雙向同步需要花費更多的時間。更長的同步時間將會導致更加嚴重的吞吐量下降，或者出現(xiàn)數(shù)據(jù)沖突的情況。吞吐量和沖突是兩個對立的問題，你需要在其中進行權衡。例如，為了解決沖突，引入分布式鎖/分布式事務；為了解決達到更高的吞吐量，利用中間狀態(tài)、錯誤重試等手段，達到最終一致性；降低沖突，將數(shù)據(jù)進行恰當?shù)膕harding，盡可能在一個節(jié)點中完成整個事務。
          對于一些無法接受最終一致性的業(yè)務，餓了么采用的是下圖的方式：
          對于個別一致性要求很高的應用，我們提供了一種強一致的方案（Global Zone），Globa Zone是一種跨機房的讀寫分離機制，所有的寫操作被定向到一個 Master 機房進行，以保證一致性，讀操作可以在每個機房的 Slave庫執(zhí)行，也可以 bind 到 Master 機房進行，這一切都基于我們的數(shù)據(jù)庫訪問層（DAL）完成，業(yè)務基本無感知。
          ——《餓了么異地多活技術實現(xiàn)（一）總體介紹》
          也就是說，在這個區(qū)域是不能進行雙活的。采用主從而不是雙寫，自然解決了沖突的問題。
          實際上，異地雙活和異地多活已經(jīng)很像了，雙活的結構更為簡單，所以在程序架構上不用做過多的考慮，只需要做傳統(tǒng)的限流，failover等操作即可。但其實雙活只是一個臨時的步驟，最終的目的是切換到多活。因為雙活除了有數(shù)據(jù)沖突上的問題意外，還無法進行橫向擴展。
          異地多活
          圖4 異地多活的示意圖
          根據(jù)異地雙活的思路，我們可以畫出異地多活的一種示意圖。每個節(jié)點的出度和入度都是4，在這種情況下，任何節(jié)點下線都不會對業(yè)務有影響。但是，考慮到距離的問題，一次寫操作將帶來更大的時間開銷。時間開銷除了影響用戶體驗以外，還帶來了更多的數(shù)據(jù)沖突。在嚴重的數(shù)據(jù)沖突下，使用分布式鎖的代價也更大。這將導致系統(tǒng)的復雜度上升，吞吐量下降。所以上圖的方案是無法使用的。
          回憶一下我們在解決網(wǎng)狀網(wǎng)絡拓撲的時候是怎么優(yōu)化的？引入中間節(jié)點，將網(wǎng)狀改為星狀：
          圖5 星狀的異地多活
          改造為上圖后，每個城市下線都不會對數(shù)據(jù)造成影響。對于原有請求城市的流量，會被重新 LoadBalance 到新的節(jié)點（最好是LB到最近的城市）。為了解決數(shù)據(jù)安全的問題，我們只需要針對中心節(jié)點進行處理即可。但是這樣，對于中心城市的要求，比其他城市會更高。比如恢復速度，備份完整性等，這里暫時不展開。我們先假定中心是完全安全的。
          如果我們已經(jīng)將異地多活的業(yè)務部署為上圖的結構，很大程度解決了數(shù)據(jù)到處同步的問題，不過依然會存在大量的沖突，沖突的情況可以簡單認為和雙活差不多。那么還有沒有更好的方式呢？
          這里可以關聯(lián)一下餓了么的 GlobalZone 方案，總體思路就是“去分布式”，也就是說將寫的業(yè)務放到一個節(jié)點的（同城）機器上。阿里是這么思考的：
          阿里理想中的異地多活架構
          實際上我猜測很多業(yè)務也是按照上圖去實現(xiàn)的，比如滴滴打車業(yè)務這種，所有的業(yè)務都是按城市劃分開的。用戶、車主、目的地，他們的經(jīng)緯度通常都是在同一個城市的。單個數(shù)據(jù)中心并不需要和其他數(shù)據(jù)中心進行數(shù)據(jù)交互，只有在統(tǒng)計出報表的時候才需要，但報表是不太注重實時性的。那么，在這種情況下，全國的業(yè)務其實可以被很好的sharding的。
          但是對于電商這種復雜的場景和業(yè)務，按照前文說的方式進行sharding已經(jīng)無法滿足需求了。因為業(yè)務線非常復雜，數(shù)據(jù)依賴也非常復雜，每個數(shù)據(jù)中心相互進行數(shù)據(jù)同步的情況無可避免。淘寶的解決方式和我們切分微服務的方式有點類似：
          淘寶按照單元切分的異地多活架構
          注意看圖中的數(shù)據(jù)同步箭頭。以交易單元為例，屬于交易單元的業(yè)務數(shù)據(jù)，將與中心單元進行雙向同步；不屬于交易單元的業(yè)務數(shù)據(jù)，單向從中心單元同步。中心單元承擔了最復雜的業(yè)務場景，業(yè)務單元承擔了相對單一的場景。對于業(yè)務單元，可以進行彈性伸縮和容災；對于中心單元，擴展能力較差，穩(wěn)定性要求更高?？梢杂鲆?，大部分的故障都會出現(xiàn)在中心單元。
          按照業(yè)務進行單元切分，已經(jīng)需要對代碼和架構進行徹底的改造了（可能這也是為什么阿里要先從雙活再切到多活，歷時3年）。比如，業(yè)務拆分，依賴拆分，網(wǎng)狀改星狀，分布式事務，緩存失效等。除了對于編碼的要求很高以外，對測試和運維也有非常大的挑戰(zhàn)。
          如此復雜的情況，如何進行自動化覆蓋，如何進行演練，如何改造流水線。這種級別的災備，不是一般公司敢做的，投入產(chǎn)出也不成正比。不過還是可以把這種場景當作我們的“假想敵”，去思考我們自己的業(yè)務，未來會怎么發(fā)展，需要做到什么級別的災備。相對而言，餓了么的多活方案可能更適合大多數(shù)的企業(yè)。
          本文只是通過畫圖的方式進行了簡單的描述，其實異地多活是需要很多很強大的基礎能力的。比如，數(shù)據(jù)傳輸，數(shù)據(jù)校驗，數(shù)據(jù)操作層（簡化客戶端控制寫和同步的過程）等。
          來源：https://blog.dogchao.cn/?p=299
          10T 技術資源大放送！包括但不限于：Linux、虛擬化、容器、云計算、網(wǎng)絡、Python、Go 等。在開源Linux公眾號內(nèi)回復「10T」，即可免費獲?。?/span>
          shell編程100例（附PDF下載）
          IPv6技術白皮書（附PDF下載）
          Linux主流發(fā)行版本配置IP總結（Ubuntu、CentOS、Redhat、Suse）
          批量安裝Windows系統(tǒng)
          無人值守批量安裝服務器
          運維必備的《網(wǎng)絡端口大全》，看這一份就夠了。
          收藏：服務器和存儲知識入門
          什么叫SSH？原理詳解，看這一篇就夠了！
          Nginx面試40問(收藏吃灰)
          20 個 Linux 服務器性能調(diào)優(yōu)技巧
          超詳細！一文帶你了解LVS四層負載均衡企業(yè)級實踐！
          收藏 | Linux系統(tǒng)日志位置及包含的日志內(nèi)容介紹
          100 道 Linux 常見面試題，建議收藏，慢慢讀~
          服務器12種基本故障+排查方法
          IT運維管理常用工具大全，讓你成為真正的高手
          什么是QoS？
          Linux學習指南
          有收獲，點個在看 
          瀏覽
                    31
          點贊
    
          評論
    
          收藏
    
          分享
        
          手機掃一掃分享
          分享
    
          
        舉報
    
          評論
          圖片
          表情
          推薦
        
          點贊
    
          評論
    
          收藏
    
          分享
        
          手機掃一掃分享
          分享
    
          
        舉報
    
          

          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            2. 

            <del id="afajh"><form id="afajh"></form></del>
            

            5. 

                1. <th id="afajh"><progress id="afajh"></progress></th>

                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  

国精产品高潮呻吟久久久…
|
无码视频免费看
|
亚洲国产第一页
|
一级一片免费观看
|
国产AV 无码 乱噜噜
|