一、一些概念
雙機熱備（Active - Standby）是指兩臺機器都在運行，但並不是兩臺機器都同時提供服務。當提供服務的一臺機器出現故障的時候，另外一臺機器會馬上自動接管並且提供服務，並且切換的時間非常短。
HA，即高可用（High availability）。
二、數據庫架構
在項目中，當業務規模越來越大，數據越來越多時，隨之而來的就是數據庫壓力會越來越大，數據庫層慢慢成爲了整個系統的關鍵點和性能瓶頸，因此實現數據層的高可用就成了項目中經常要解決的問題。在保障數據層的高性能與高穩定方面，最常用的方式就是對數據進行分片、多份、冗餘等，很多架構的本質其實也是基於這幾點來實現的。因爲無論底層是關係型數據庫，還是NoSQL數據庫，無論是 Mysql 還是 Redis、MongoDB，在架構設計上都是相通的。大體上，單中心雙機的常見方案有以下這些：
● 主備架構（Primary - Standby Architecture）
● 主從的架構（Master-Slave Architecture）
● 雙主架構（Master-Master Architecture）
以上方案從上至下，依次是從簡單到複雜，從基礎到豐富。
1.1 主備架構（主備式）
主備架構是雙機部署中最簡單的一種架構，幾乎市面上所有的數據庫系統都會自帶這個主備功能。
其思路是：將數據庫部署到兩臺機器，其中一臺機器（代號M）作爲日常提供數據讀寫服務的機器，稱爲「主機」。另外一臺機器（代號S）並不提供線上服務，但會實時的將「主機」的數據同步過來，稱爲「備機」。一旦「主機」出了故障，通過人工的方式，手動的將「主機」踢下線，將「備機」改爲「主機」來繼續提供服務。
優點：幾乎不需要做什麼開發改造，各類數據庫就支持這種模式，部署維護起來也簡單，並沒有引入額外的系統複雜度和瓶頸。
缺點：1）當「主機」出現故障的時候，需要人工去幹預啊，運維很辛苦且處理不一定及時。
2）主備架構會造成嚴重浪費資源，需要一臺與「主機」同等配置的「備機」長期備着，但又不作爲線上服務來使用。
爲了解決這個資源浪費問題，出現了一個把「備機」也用起來的方案：主從式架構。
1.2主從架構（主從式）
主從式架構大體上與主備式架構差不多。區別是主備式的「備機」平時是用的，主要起到備份的作用，而主從式的「備機」改爲了「從機」，平時也要提供「讀」服務，但不提供「寫」服務。。
主從架構中，「主機」提供「讀」、「寫」服務，並實時的將線上數據同步到「從機」，以保證「從機」能夠正常的提供「讀」服務。
這種架構相比較主備式，對資源是一種節約，並且在「主機」出現故障時，在人工介入之前，「從機」能夠提供數據的「讀」操作的，由於大多數業務都是「讀」多「寫」少，因此對穩定性又提高了一個層次。
缺點：1）架構稍微複雜了一點，畢竟「主機」和「從機」都有「讀」服務，那麼前端業務系統就需要用一定策略去判斷該路由到哪一臺去讀取數據。
2）延遲問題，「主機」的數據同步到「從機」難免會有一定程度的延遲，這個延遲可能會對數據實時性要求較高的業務有一定影響。
綜上，雖然主從架構一定程度解決了資源浪費，但是並沒有解決人工干預的問題，當出現了故障後還是需要人工去處理。如果想讓架構更智能一點，就需要引入「主從雙機自動切換」的功能。
主從雙機自動切換：是指當主機出現故障後，從機能夠自動檢測發現。同時從機將自己迅速切換爲主機，將原來的主機立即下線服務，或轉換爲從機狀態。
要實現「主從雙機自動切換」，有幾個關鍵點需要考慮：
● 「雙機互連模式」
● 「第三方中介模式」
「雙機互連模式」：是指在主機和從機之間建立一條用於狀態通訊的通道。通過這個通道，主機和從機之間可以共享服務狀態，一旦發現對方宕機或者停止服務了，就可以立即將自己切換爲主服務。不過這種方式需要關注通道的健壯性，一旦通道自身不穩定了，可能會導致假消息出現，比如主機並沒有宕機，但是通道壞了，導致從機以爲出現了異常，就將自己切換爲了主機，那就出現了2個主機了，因此通道本身也是一個可能的故障點。
「第三方中介模式」：是指在主機和從機之外，再建立一箇中介機器，這個中介機器專門用來維護各節點（主機/從機）狀態的，主機/從機實時的將自身狀態上報給中介機器，中介機器來決定是否應該切換、何時切換。MongoDB的Replica Set就是採用的這種模式。
-
除了狀態判斷，還需要考慮切換的策略是什麼？ 即發生異常幾次/多久後開始切換，是否有緩衝機制等。另外切換完成後，當原主機又恢復正常之後是否需要自動再切換回來等策略。
-
另外就是需要注意在切換過程中雙機數據如果發生衝突時，以哪個爲準？處理機制是什麼。
-
這些細節都是在設計主從自動切換架構時候，要提前規劃的。
1.3雙主架構（互爲主從式）
互爲主從的架構是指兩臺機器自己都是主機，並且也都是作爲對方的從機。兩臺機器都提供完整的讀寫服務，因此無需切換，客戶機在調用的時候隨機挑選一臺即可，當其中一臺宕機了，另外一臺還可以繼續服務。
互爲主從架構，因爲兩臺主機都接受寫數據，那就需要將寫的最新數據實時的同步給對方，需要將數據進行兩臺主機的雙向複製。而雙向複製不可避免的會在一定程度上帶來數據延遲、極端情況下甚至有數據丟失等問題。在實際業務中，有些業務數據對一致性要求是非常高的，並不能接受數據的延遲、丟失，因此這類業務也不適合互爲主從的模式，比如金融業務。
1.4據庫在多機集羣模式下的技術架構
三、數據庫一致性解決方案
一致性解決方案（Consistency Solution）：在分佈式數據庫系統中，一致性解決方案是指確保不同節點之間數據的一致性。
常見的一致性解決方案包括基於時間戳的複製、基於多版本併發控制（MVCC）的複製、基於Paxos協議的一致性算法、基於Raft協議的一致性算法等。這些算法都旨在保證不同節點之間數據的一致性和可靠性。
數據庫架構設計也是一個重要的任務，良好的設計可以提高數據庫的性能、可用性和可維護性。
1、 數據庫的範式化設計：通過範式化的設計，可以減少數據冗餘和數據不一致的問題。常見的範式包括第一範式（1NF）、第二範式（2NF）和第三範式（3NF）等。
2、數據庫的反範式化設計：有些情況下，反範式化的設計可以提高數據庫的性能。反範式化的設計包括將數據冗餘存儲、增加冗餘索引、分區表、分片等技術。
3、 合理分配數據和索引：合理的數據和索引分配可以提高數據庫的查詢性能。通常建議將索引分配到較小的表中，同時將數據均勻分配到各個節點中。
4、 優化數據庫查詢：通過對查詢進行優化，可以提高數據庫的查詢性能。包括對查詢進行優化，例如使用索引、避免全表掃描、使用優化的SQL語句等。
5、合理的分區和分片：分區和分片是分佈式數據庫中常用的技術，可以提高數據庫的可擴展性。合理的分區和分片可以減少網絡開銷、提高查詢性能、降低數據庫負載等。
6、 安全性和可靠性：在數據庫架構設計中，安全性和可靠性是非常重要的。包括對數據庫進行備份、數據加密、訪問控制、防火牆等技術的應用。
6、監控和調優：在數據庫架構設計中，監控和調優也是非常重要的。包括實時監控數據庫的性能、調整數據庫配置參數、調整應用程序、優化數據庫查詢等。
四、MySQL主備應用和原理
4.1MySQL主備
如圖 1 所示就是基本的主備切換流程。
binlog 的特性確保了在備庫執行相同的 binlog，可以得到與主庫相同的狀態。因此，可以認爲正常情況下主備的數據是一致的。也就是說，圖 1 中 A、B 兩個節點的內容是一致的。
4.2MySQL雙主
節點 A 和 B 之間總是互爲主備關係。這樣在切換的時候就不用再修改主備關係。但是，雙 M 結構還有一個問題需要解決。業務邏輯在節點 A 上更新了一條語句，然後再把生成的 binlog 發給節點 B，節點 B 執行完這條更新語句後也會生成 binlog。那麼，如果節點 A 同時是節點 B 的備庫，相當於又把節點 B 新生成的 binlog 拿過來執行了一次，然後節點 A 和 B 間，會不斷地循環執行這個更新語句，也就是循環複製了。
這個要怎麼解決呢？從上面的圖 6 中可以看到，MySQL 在 binlog 中記錄了這個命令第一次執行時所在 實例的server id。因此，可以用下面的邏輯，來解決兩個節點間的循環複製的問題：
- 規定兩個庫的 server id 必須不同，如果相同，則它們之間不能設定爲主備關係；
- 一個備庫接到 binlog 並在重放的過程中，生成與原 binlog 的 server id 相同的新的 binlog；
- 每個庫在收到從自己的主庫發過來的日誌後，先判斷 server id，如果跟自己的相同，表示這個日誌是自己生成的，就直接丟棄這個日誌。
原文鏈接：https://blog.csdn.net/qq_43284469/article/details/129017864
4.3MySQL+Keepalived雙主熱備高可用環境部署
MySQL雙主複製，即互爲Master-Slave(只有一個Master提供寫操作)，可以實現數據庫服務器的熱備，但是一個Master宕機後不能實現動態切換，實際生產上使用比較多的是雙 M 結構。
使用Keepalived，可以通過虛擬IP，實現雙主對外的統一接口以及自動檢查、失敗切換機制，從而實現MySQL數據庫的高可用方案。
環境概述：
1）先實施Master->Slave的主主同步。主主是數據雙向同步，主從是數據單向同步。一般情況下，主庫宕機後，需要手動將連接切換到從庫上。（但是用keepalived就可以自動切換）
2）再結合Keepalived的使用，通過浮動IP實現Mysql雙主對外連接的統一接口。即客戶端通過浮動IP連接數據庫；當其中一臺宕機後，浮動IP會漂移到另一臺上，這個過程對於客戶端的數據連接來說幾乎無感覺，從而實現高可用。
————————————————
版權聲明：本文爲CSDN博主「F_yinhai」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/fyh360345192/article/details/84620473
五、高可用淺析
高可用（High availability，即 HA）主要是針對架構而言，
第一步一般會採用分層的思想將一個龐大的應用系統拆分成應用層、中間件、數據存儲層等獨立的層，每一層再拆分成更細粒度的組件；
第二步就是讓每個組件對外提供服務，畢竟每個組件都不是孤立存在的，都需要互相協作，對外提供服務纔有意義；
第三步就是保證架構中所有組件以及對外暴露服務都要做到高可用，任何一個組件或其服務沒做高可用，都意味着系統存在風險。
5.1高可用方案
任何組件要做高可用，都離不開「冗餘」和「自動故障轉移」。
組件一般是以集羣（至少兩臺機器）的形式存在的，只要某臺機器出現問題，集羣中的其他機器就可以隨時頂替，這就是「冗餘」。
簡單計算一下，假設一臺機器的可用性爲 90%，則兩臺機器組成的集羣可用性爲 1-0.1*0.1 = 99%，所以顯然冗餘的機器越多，可用性越高。
但光有冗餘還不夠，如果機器出現問題，需要人工切換的話也是費時費力，而且容易出錯，所以我們還需要藉助第三方工具（即仲裁者）的力量來實現「自動」的故障轉移，以達到實現近實時的故障轉移的目的，近實時的故障轉移纔是高可用的主要意義。
在業界一般用幾個九來衡量系統的可用性，如下：
————————————————
版權聲明：本文爲CSDN博主「ldcaws」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/leijie0322/article/details/130948280
七、數倉 | 幾種常見的數據同步方式
數據倉庫的特性之一是集成，即首先把未經過加工處理的、不同來源的、不同形式的數據同步到ODS（Operational Data Store，原始數據）層，一般情況下，這些ODS層數據包括日誌數據和業務DB數據。
對於業務DB數據而言(比如存儲在MySQL中)，將數據採集並導入到數倉中(通常是Hive或者MaxCompute)是非常重要的一個環節。
那麼，該如何將業務DB數據高效準確地同步到數倉中呢?一般企業會使用兩種方案：直連同步與實時增量同步(數據庫日誌解析)。其中直連同步的基本思路是直連數據庫進行SELECT，然後將查詢的數據存儲到本地文件作爲中間存儲，最後把文件Load到數倉中。這種方式非常的簡單方便，但是隨着業務的發展，會遇到一些瓶頸，具體見下文分析。
爲了解決這些問題，一般會使用實時增量的方式進行數據同步，其基本原理是CDC (Change Data Capture) + Merge，即實時Binlog採集 + 離線處理Binlog還原業務數據這樣一套解決方案。
本文主要包括以下內容，希望對你有所幫助
-
- 常見數據同步方式
- 流式數據集成
二、高可用解決方案
參考資料