隨著業務量的增加，一次大區故障可能影響幾億人的使用，所以公司對於故障的容忍率越來越低。對了避免出現由於由於乙個機房入口光纜被挖斷或者機房停電導致服務不可用，所以很多公司做了多活。
多活目前分：
1.同城/異地多活
2.單元化部署
還有一種單元化的概念，把使用者按照id或者地理圍欄分段，每個段內的使用者資料是完備的-本區內的服務有所有依賴的元件，資料庫，服務部署能力，mq等等。
1.簡單的同城多活部署
說明：1.m1,s1互為主備，m2和s2互為主備，在m1故障時，流量自動切換到s1。m2，s2同理。
2.入口流量隨機分配
3.每個機房的服務都需要連線所有的db
容災操作:
如果義橋機房出現大規模的故障，那麼將主db全部切換到建德機房，同時將入口流量全部切換到建德機房。此時所有流量在單個區工作，義橋機房恢復後切換回來
優點：部署和實現簡單，目前大部分db本身就有高可用，例如mongo和大部分公司的mysql高可用方案，只需要在閘道器層做一次使用者的分配。
缺點：1.系統的可擴充套件性差，由於db的連線數有限，訪問所有db的情況下，很容易導致連線數瓶頸，系統無法擴充套件。
2.跨機房訪問耗時增加，導致服務吞吐量下降
2.同城雙機房
說明：1.m1,s1互為主備，m2和s2互為主備，在m1故障時，流量自動切換到s1。m2，s2同理。同時，寫入只發生在本機房，即0-xx區間使用者的資料都在（m1，s1）上。
2.由閘道器分配流量，義橋機房的使用者分配到義橋機房，建德機房的使用者分配到建德機房，此時有跨機房的訪問，但是同城多機房的延遲比較有限，通常為3-10ms，屬於可以接受的範圍內。如果對於一致性要求不高，可以訪問做讀寫分離，由從庫讀取資料，可以避免跨機房的訪問。
3.每個機房的服務都需要連線所有的db
容災操作:
如果義橋機房出現大規模的故障，那麼將主db全部切換到建德機房，同時將入口流量全部切換到建德機房。此時所有流量在單個區工作，義橋機房恢復後切換回來
優點：和前乙個方案對比，減少了跨級房的呼叫，但是在主庫宕機時依然少不了跨機房的呼叫
缺點：系統相對比較複雜，需要每個中介軟體支援多活部署
系統的可擴充套件性差，由於db的連線數有限，訪問所有db的情況下，很容易導致連線數瓶頸，系統無法擴充套件。
mysql異地多活方案 對於異地多活的實踐與思考
對於異地多活的實踐與思考 瀏覽次數 707 一 引 異地多活是近幾年比較熱門的乙個話題，那麼在實際業務中什麼時候需要去做這件事？如何去做？做的時候需要考慮什麼？1 何時去做？個人感覺取決於以下幾個方面 業務發展 基礎設施狀況 技術積澱 2 如何做？目前在網上搜尋到的異地多活方案來看，基本都是阿里 餓...
mysql異地多活方案 資料庫異地多活解決方案
異地多活指分布在異地的多個站點同時對外提供服務的業務場景。異地多活是高可用架構設計的一種，與傳統的災備設計的最主要區別在於 多活 即所有站點都是同時在對外提供服務的。以乙個簡單的業務單元的it系統為例，整個it系統的異地多活方案如下圖所示。整個方案將各站點分為 分流量層 應用層和資料層。單元封閉 應...
異地多活（異地雙活）實踐經驗
異地多活 異地雙活 是最近業界討論比較多的話題，特別是前一陣子支付寶機房光纖故障和攜程網資料庫丟失之後，更加喚起了技術人員們對異地容災的考慮。而異地多活比異地容災更高一級，因為異地容災僅僅是乙個冷備的概念，而異地多活卻是指有兩個或者多個可以同時對外服務的節點，任意乙個點掛了，也可以迅速切換到其他節點...