俄羅斯：將審查iPhone等外國公司設備 保數據安全
iPhone和特斯拉都屬于在各自領域領頭羊的品牌，推出的產品也也都是數一數二的，但對于一些國家而言，它們的產品可靠性和安全性還是在限制范圍內。近日，俄羅斯聯邦通信、信息技術
在互聯網大廠，有個普遍的現象：某種程度上，只要是比較重要的系統，都需要考慮系統的容災問題。
通過實施容災方案，將系統部署兩套或者多套，并且這套系統或者多套系統可以部署到不同的機房，如果其中一套系統出現故障導致不可用，則可以迅速切換到另一套系統，提供7*24小時不間斷服務。
同城雙活和異地多活都是典型的系統容災部署方案，對于企業來說，尤其是大型互聯網公司，比較重要的系統一般都會做容災，采用同城雙活，甚至異地多活的架構方案進行部署。
對于同城雙活和異地多活來說，都是容災的不同方案，它們對技術、部署成本、運維成本、網絡帶寬、網絡穩定性等的要求都不一樣。
多多少少都會增加部署的復雜度和部署成本，但是，容災在某套系統出現故障時，能夠迅速切換到另一套系統，保證系統的高可用。
企業的核心系統和比較重要的系統應該也必須考慮容災問題，這里的容災主要是通過部署兩套或者多套系統實現，這兩套或者多套系統一般是部署在不同的機房，避免只部署一套系統或者在同一機房部署多套系統出現宕機事故。
在實際場景中，哪怕我們部署了兩套或者多套系統，但是這些系統是部署在同一個機房內，此時系統的可用性是受限于機房的可用性，如果機房出現網絡不通或者其他事故，就會影響到系統的可用性，甚至造成系統長時間宕機。
這種系統事故不是人為造成的，但是如果不考慮容災問題，或者容災問題考慮不充分，將兩套或者多套系統部署在同一個機房內就可能出現這種問題。
舉個例子，如果已經考慮到容災的問題，只是將兩套或者多套系統部署在同一個機房中，如果這個機房的網絡或者服務器出現了故障，機房發生了火災，甚至機房所在的城市發生了地震、海嘯、洪水等不可抗力的災難時，哪怕部署在同一個機房內的多套系統之間實現的可用性再高，整個系統也是不可用的。
跨機房部署，顧名思義就是將兩套或者多套系統部署在多個機房，跨機房部署其實并沒有想象中的那么簡單和美好，實際上，將兩套或者多套系統部署在多個機房是有一定的復雜度和挑戰的。
以數據庫為例，假設目前有兩個機房，分別為機房A和機房B，數據庫主庫A和從庫B都在A機房，那么B機房的應用如何讀取到數據呢？此時，總體上有兩種方案：跨機房讀取數據和本機房內讀取數據。
如果是跨機房讀取數據的話，B機房中的應用就會跨機房讀取A機房的數據，如下圖所示。
可以看到，此時B機房的應用會跨機房讀取A機房的數據。
如果是本機房內讀取數據，則可以在B機房中部署一個從庫，B機房中的從庫跨機房同步A機房的數據，隨后，B機房的應用讀取本機房中從庫的數據，如下圖所示。
可以看到，在B機房中部署一個從庫，跨機房同步A機房數據，B機房中的應用就可以讀取本機房內從庫的數據。
無論是B機房內的應用跨機房讀取數據，還是讀取本機房內的數據，都會存在跨機房數據的傳輸問題，跨機房讀取數據是B機房的應用直接讀取A機房數據時，產生的跨機房傳輸數據問題。
而讀取本機房內的數據，是數據庫同步數據產生的跨機房傳輸數據問題。只要涉及到跨機房傳輸數據的問題，就會對機房之間的數據延遲有比較高的要求。
根據以往的經驗來說，機房之間的數據延遲，與機房之間的物理距離有直接的關系，這里，給大家列舉幾個經驗數據。
一般情況下，同城雙機房專線延遲在1ms~3ms之間。
假設接口的響應時間要求控制在200ms之內，而一次接口調用可能會觸發一些RPC服務或者其他服務，如果是同城雙機房專線網絡良好的情況下，跨機房調用服務，接口的響應時間可能會增加幾毫秒，再有就是跨機房讀寫數據，接口響應時間增加幾毫秒，都是可以接受的。
但是，如果跨機房調用服務，讀寫數據的次數比較多，來來回回耗費了幾十、上百毫秒，此時就不能接受了。
一般情況下，就國內的異地雙機房專線延遲在50ms之內。
具體還是要根據機房之前的物理距離來確定，比如北京到上海的專線延遲一般在30ms左右，而北京到廣州的專線延遲在50ms左右，機房的物理距離不同，延遲也不盡相同。
在異地雙機房專線的數據延遲影響下，如果要將接口的響應時間控制在200ms之內，就要避免頻繁的跨機房調用服務和跨機房讀寫數據。
一般情況下，國際異地雙機房專線的網絡延遲會比國內異地雙機房專線延遲高，一般會在100ms~200ms。
在這種場景下，就需要避免跨機房進行數據的同步處理，只考慮異步同步跨機房數據。
同城雙活方案是將系統部署在同一個城市的不同機房中，這種方案能夠做到機房級別的容災，而不能做到城市級別的容災。
在同城雙活方案中，同城的兩個機房中，每個機房會承擔一部分流量，涉及到服務的調用和數據讀寫時，盡量在本機房內完成，如果是RPC調用，不同機房的RPC服務可以向注冊中心注冊不同的服務分組，不同機房的RPC消費者只訂閱本機房內的服務分組。
這樣就可以實現RPC調用盡量發生在本機房內。如果是寫數據，則可以向一個機房寫數據，而實時同步到另一個機房，如下圖所示。
可以看到，在實施同城雙活方案時，主庫可以部署在A機房中，A機房和B機房的數據都寫到A機房的主庫中，主庫會將數據同步到A、B機房的從庫。一旦A機房發生故障，可以將B機房的從庫提升為主庫，B機房繼續對外提供服務。
在A機房和B機房同時部署了緩存，緩存中的數據可以由本機房內的從庫進行同步，也可以由本機房的服務進行讀寫。
如果本機房的緩存中沒有需要的數據，就到本機房的從庫中進行查詢，當然這里查詢數據庫的操作，要考慮緩存擊穿、穿透和雪崩的問題。
當更新數據時，可以同時更新每個機房的數據。
不同機房的RPC服務可以向注冊中心注冊不同的服務分組，不同機房的RPC消費者只訂閱本機房內的服務分組，這樣就可以實現RPC調用盡量發生在本機房內。
一般情況下，系統做同城雙活容災方案就夠了，如果系統的業務發展到了淘寶級別，就需要考慮異地多活了。
如果是采用異地多活方案，機房之間的距離不宜太近，部署到同一個城市就不太合適了，所以，起碼是要做跨城市級別的異地多活，甚至是跨國異地多活，在這種場景下，顯然不能跨機房寫數據了。
在異地多活場景下，數據同步可以采取主從同步+消息異步復制的方式來同步，也就是說，對于像MySQL、Redis這種數據，可以采用主從復制的方式，由一個機房同步到另一個機房。像緩存數據和一些NoSQL數據庫的數據，可以使用消息異步復制的方式來同步數據，如下圖所示。
可以看到，在異地多活場景下，對于像MySQL、Redis這種數據，可以采用主從復制的方式，由一個機房同步到另一個機房。像緩存數據和一些NoSQL數據庫的數據，可以使用消息異步復制的方式來同步數據。
在異地多活場景下，還有一些要注意的問題：讀取用戶相關的數據時，盡量保證在同一個機房內處理，這時，就需要對用戶的數據做分片處理，對同一個用戶數據的讀寫操作，路由到同一個機房內。
對數據的讀取和服務的調用，也盡量在同一個機房內完成。
另外，還有一種場景是在電商業務中，用戶相關的數據，例如用戶查詢自己的訂單數據時，用戶自己的訂單數據與用戶數據在同一個機房內，但是訂單數據中的店鋪數據和商家的一些基本信息，可能就存儲在另外的機房了。
此時，對于服務的調用和數據的讀取，優先保證在本機房內進行，如果不得已發生跨機房讀取數據的操作，有一定的延遲，也可以接受。
還有一點需要說明的是：如果同城雙活架構方案能夠滿足需求，就不要輕易嘗試異地多活架構，實際上，異地多活架構過于復雜，很少有公司能夠搭建出真正的異地多活架構。
本文鏈接：http://m.www897cc.com/showinfo-26-100992-0.html超級加倍：互聯網大廠的容災架構設計與落地方案（跨機房部署、同城雙活、異地多活）
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
下一篇： 帶你了解垃圾收集算法實現細節
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號