Java八股文——MySQL「架構篇」

MySQL主從復制了解嗎

面試官您好，我了解MySQL的主從復制。它是構建高可用、高可擴展數據庫架構的核心基石。

1. 主從復制的核心原理與流程

整個主從復制的過程，就是一場圍繞 binlog（二進制日志） 的“接力賽”。這個過程主要可以分為三個大的階段：

階段一：主庫記錄變更 (Master Writes Binlog)
- 當主庫（Master）執行一個寫操作（INSERT, UPDATE, DELETE）并提交事務時，它會按照兩階段提交的協議，將這次數據變更的邏輯操作記錄到自己的binlog文件中。
階段二：從庫同步日志 (Slave Fetches Binlog)
- 從庫（Slave）上有一個專門的I/O線程。它的唯一任務就是與主庫建立一個長連接，并請求主庫的binlog。
- 主庫上有一個對應的 log dump線程，它在接收到從庫的請求后，會源源不斷地把新的binlog內容推送給從庫的I/O線程。
- 從庫的I/O線程在接收到binlog數據后，并不是直接執行，而是先將其原封不動地寫入到本地的一個叫做“中繼日志”（relay log）的文件中。
- 為什么需要relay log？ 這是一種解耦設計。它將“網絡數據接收”和“本地數據重放”這兩個步驟分離開。即使后續的重放操作比較慢，也不會影響I/O線程從主庫拉取數據的速度，提高了主從同步的穩定性和效率。
階段三：從庫重放日志 (Slave Replays Relay Log)
- 從庫上還有另一個專門的SQL線程（在MySQL 5.6之后可以是多線程的）。
- 它的任務就是不斷地讀取relay log，解析出其中的SQL語句或行變更事件，然后在從庫上原樣地、按順序地執行一遍，從而使得從庫的數據與主庫保持最終一致。

2. 主從復制的模式

默認情況下，主從復制是異步的。

異步復制 (Asynchronous)
- 主庫在執行完一個事務、寫完binlog后，不會等待從庫的任何響應，會立即返回成功給客戶端。
- 優點：性能最高，對主庫的性能影響最小。
- 缺點：數據可能不一致。如果主庫在binlog發送給從庫之前就宕機了，那么這個事務的數據就會在從庫上永久丟失，導致主從數據不一致。
半同步復制 (Semi-synchronous)
- 為了解決異步復制的數據丟失問題，MySQL引入了半同步復制。
- 工作模式：主庫在提交事務后，會阻塞等待，直到至少有一個從庫接收到binlog并寫入自己的relay log后，主庫才會返回成功給客戶端。
- 優點：在很大程度上保證了數據的高可用性。只要不是主從在同一時間點上一起宕機，數據就不會丟失。
- 缺點：增加了主庫的響應延遲，對性能有一定影響。

3. 主從復制的核心應用價值

讀寫分離：這是最常見的應用。我們可以讓主庫專門負責寫操作，而將大量的讀請求，分散到多個從庫上。這極大地分擔了主庫的壓力，提升了整個數據庫集群的查詢吞吐量。
高可用與災備：當主庫發生故障時，我們可以快速地將一個從庫提升為新的主庫，從而實現服務的快速恢復，保證了業務的連續性。
數據備份：我們可以在從庫上進行數據備份，而完全不影響主庫的正常服務。

4. 面臨的挑戰

主從延遲 (Replication Lag)：這是主從復制中最核心的挑戰。由于網絡延遲、從庫SQL線程執行慢等原因，從庫的數據可能會落后于主庫。我們需要對主從延遲進行持續的監控和告警，并通過優化SQL、提升從庫硬件、開啟并行復制等手段來緩解這個問題。

總結一下，MySQL主從復制通過一套精巧的、基于binlog的日志同步與重放機制，為我們構建可擴展、高可用的數據庫架構提供了強大的基礎。

主從延遲都有什么處理方法？

面試官您好，主從延遲是MySQL主從架構中一個非常常見、也必須重點關注的問題。解決它，需要一個 “監控、分析、優化、容忍” 相結合的系統性方案。

第一步：監控與發現 —— “讓延遲無所遁形”

在討論如何解決之前，我們首先得能準確地監控到延遲。我會通過SHOW SLAVE STATUS;命令，重點關注以下兩個指標：

Seconds_Behind_Master: 這是最直觀的指標，它表示從庫SQL線程執行的時間點，落后于主庫I/O線程接收到binlog的時間點有多少秒。我會對這個值設置一個合理的閾值（比如超過5秒）進行持續的監控和告警。

第二步：原因分析 —— “延遲到底發生在哪里？”

主從延遲的根本原因，是從庫消費binlog的速度，跟不上主庫生成binlog的速度。這可能發生在兩個環節：

網絡延遲：主庫和從庫之間的網絡狀況不佳，導致I/O線程拉取binlog就比較慢。
從庫執行慢（最常見的原因）：
- 從庫硬件配置差：從庫的磁盤I/O能力或CPU性能，遠低于主庫。
- 從庫是“單線程作戰”：在MySQL 5.6之前，從庫的SQL線程是單線程的。如果主庫上是多個線程在并行寫入，而從庫卻只能串行回放，延遲就很容易產生。
- 主庫上存在“大事務”或慢SQL：一個在主庫上執行了10分鐘的大事務，或者一條沒有索引的慢查詢，當它傳到從庫時，同樣會阻塞SQL線程10分鐘，造成巨大的延遲。
- 從庫上有其他查詢壓力：如果從庫除了要回放binlog，還承擔了大量的實時報表、數據分析等慢查詢任務，也會拖慢SQL線程的執行。

第三步：解決方案 —— “多管齊下”

針對以上原因，我會采用一整套組合拳來解決主從延遲。

1. 硬件與網絡優化（基礎保障）
- 保證從庫的硬件配置不低于主庫，特別是磁盤I/O性能。
- 優化主從之間的網絡連接，比如使用專線、萬兆網卡等。
2. 開啟并行復制（核心優化）
- 這是解決從庫執行慢的最核心、最有效的手段。
- MySQL 5.6：引入了基于庫（DATABASE） 的并行復制，即不同數據庫的更新可以并行回放。
- MySQL 5.7：引入了更強大的基于邏輯時鐘（LOGICAL_CLOCK） 的并行復制。它能做到在同一個庫內，只要是沒有數據沖突的事務，都可以并行回放，大大提升了復制效率。
- MySQL 8.0：進一步增強，引入了基于寫集合（WRITESET） 的并行復制，能更精準地判斷事務是否可以并行。
- 在生產環境中，開啟并合理配置并行復制是必須的操作。
3. 優化主庫的SQL（源頭治理）
- 避免大事務：在應用層，將大的DML操作，拆分成多個小事務分批執行。
- 杜絕慢查詢：所有在主庫上執行的SQL都必須經過EXPLAIN審核，確保都用上了合適的索引，避免全表掃描。
4. 架構層面的業務容忍方案

當上述優化都做了，但仍然可能存在無法完全消除的、秒級的延遲時，我們就需要從業務層面來設計一些容忍方案。

a. 讀寫分離的“半同步”讀取
- 場景：對于一些對實時性要求極高的讀請求，比如用戶剛支付完，立刻查詢訂單狀態。
- 方案：可以讓這個特定的讀請求，在執行SELECT之前，先執行一條SELECT MASTER_POS_WAIT(file, pos, timeout)命令。這個命令會阻塞當前會話，直到從庫的SQL線程追趕到指定的binlog位置（這個位置可以從寫操作成功后獲取），或者超時。這樣就能保證這次讀取，一定能讀到最新的數據。
b. 強制走主庫（最后的兜底方案）
- 這是最直接但代價也最大的方案。
- 做法：在應用代碼中，通過路由機制（比如使用特定的數據源注解），將那些絕對不能接受任何延遲的讀請求（比如金融交易的余額查詢），強制路由到主庫去執行。
- 權衡：這個方案能100%保證數據實時性，但會增加主庫的讀壓力，需要謹慎使用，只用于最關鍵的業務路徑。

總結一下，解決主從延遲，我會先通過并行復制和源頭SQL優化來盡可能地縮短延遲。對于仍然存在的、不可避免的微小延遲，再通過業務層面的“半同步讀”或“強制走主庫” 等方案，來滿足不同場景對數據實時性的要求。

分表和分庫是什么？有什么區別？

面試官您好，分庫和分表是當單一數據庫或單張數據表的性能或容量達到瓶頸時，我們為了提升系統的可擴展性（Scalability） 而采用的一種核心的數據庫架構演進策略。

它們解決問題的維度不同，可以看作是兩種不同方向的“拆分”：

1. 分表 (Sharding / Partitioning) —— “內部裝修，緩解單表壓力”

它是什么？
- 分表指的是，將一張數據量巨大的單表，按照某個規則，拆分成多張結構完全相同的小表。這些小表通常還在同一個數據庫實例中。
分表主要有兩種拆分方式：
- a. 垂直分表 (Vertical Partitioning)
  - 思路：“按列拆”。把一張字段非常多的“寬表”，拆分成多張“窄表”。
  - 原則：通常是把常用的、訪問頻繁的字段放在一張主表中，而把不常用的、或者字段本身很大（如TEXT, BLOB）的字段，拆分到另一張擴展表中。兩張表通過同一個主鍵關聯。
  - 解決了什么問題？
    - 提升I/O效率：核心表的單行數據變小，一個數據頁能容納更多行，查詢核心數據時I/O次數減少。
    - 緩存效率更高：Buffer Pool可以用有限的內存，緩存更多核心表的數據行。
- b. 水平分表 (Horizontal Partitioning)
  - 思路：這是我們通常意義上說的“分表”，即“按行拆”。把一張行數巨大（比如上億條）的表，按照某個規則，分散到多張物理表中。
  - 規則：常見的有按范圍（Range） 分片（如按月份、按ID區間）或按哈希（Hash） 分片（如按用戶ID取模）。
  - 解決了什么問題？
    - 緩解單表數據量瓶頸：單表數據量過大，會導致B+樹索引層高增加，查詢和寫入性能都會急劇下降。分表后，每張小表的索引樹都變得很小、很淺，性能得到極大提升。
    - 鎖競爭降低：對于高并發的寫操作，請求被分散到不同的物理表中，鎖的競爭也隨之減少。

2. 分庫 (Database Sharding) —— “另起爐灶，分散整體壓力”

它是什么？
- 分庫指的是，將一個數據庫實例，按照業務或功能，拆分成多個獨立的數據庫實例。這些實例可以部署在不同的物理服務器上。
分庫也有兩種拆分方式：
- a. 垂直分庫
  - 思路：“按業務拆”。將一個龐大的、耦合的數據庫，按照業務邊界，拆分成多個獨立的微服務數據庫。
  - 例子：一個電商系統，可以拆分成“用戶庫”、“商品庫”、“訂單庫”、“支付庫”等。
  - 解決了什么問題？
    - 業務解耦與隔離：不同業務線使用獨立的數據庫，互不影響。一個業務的數據庫出現問題，不會波及到其他業務。
    - 突破單機資源瓶頸：將壓力分散到多臺服務器上，解決了單臺服務器的CPU、內存、I/O、網絡帶寬的瓶頸。
- b. 水平分庫
  - 思路：當單個業務的數據庫（比如“訂單庫”）本身也遇到了性能瓶頸時，就需要對這個庫進行水平拆分。
  - 做法：將原先一個庫里的表，按照水平分表的方式，分散到多個數據庫實例中。比如，訂單表orders_0到orders_255，可能0-127的表在DB1，128-255的表在DB2。

3. 區別與聯系

對比維度	分表 (Table Sharding)	分庫 (Database Sharding)
拆分對象	單張大表	整個數據庫實例
物理位置	通常在同一個數據庫實例內	分散在多個數據庫實例/服務器上
解決問題	單表的查詢/寫入性能瓶頸	整個數據庫的并發壓力和數據容量瓶頸
實現復雜度	相對簡單	復雜，引入了分布式事務等問題
常見組合	通常與分庫結合使用	是更大范圍的拆分策略