主持人 > 博客 > 管理 > 為什麼需要半同步複製？

為什麼需要半同步複製？

大家好。弗拉迪斯拉夫·羅丹正在聯繫。我目前在 OTUS 教授軟體架構和高壓力軟體架構課程。 期待新課程的開始 “高負載架構師” 我決定寫一篇簡短的原創資料，想與大家分享。

為什麼需要半同步複製？

介紹

由於HDD每秒只能執行約400-700次操作（這與高負載系統的典型rps無法相比），因此經典磁碟資料庫是該架構的瓶頸。因此，有必要特別注意該儲存的擴充模式。

目前，有兩種資料庫擴展模式：複製和分片。分片可讓您擴展寫入操作，從而減少叢集中每台伺服器每次寫入的 rps。複製允許您執行相同的操作，但使用讀取操作。本文主要討論的就是這種模式。

複寫

如果你從一個非常高的層面來看待複製，這是一件簡單的事情：你有一台伺服器，上面有數據，然後這台伺服器無法再應對讀取這些數據的負載。您新增更多伺服器，在所有伺服器之間同步數據，並且使用者可以從叢集中的任何伺服器讀取資料。

儘管其表面上很簡單，但有多種選項可用於對該方案的各種實作進行分類：

  • 按集群中的角色（主-主或主-從）
  • 按下發送的物件（基於行、基於語句或混合）
  • 根據節點同步機制

今天我們將討論第3點。

事務提交是如何發生的？

這個主題與複製沒有直接關係；可以單獨寫一篇文章來討論它，但由於如果不了解事務提交機制，進一步閱讀是沒有用的，所以讓我提醒您最基本的事情。事務提交分 3 個階段進行：

  1. 將交易記錄到資料庫日誌中。
  2. 在資料庫引擎中使用交易。
  3. 向客戶端傳回交易已成功應用的確認訊息。

在不同的資料庫中，這個演算法可能會有細微差別：例如，在MySQL 資料庫的InnoDB 引擎中，有2 個日誌：一個用於複製（二進位日誌），另一個用於維護ACID（undo/redo 日誌） ，而在PostgreSQL 中有一個日誌可以執行這兩種功能（預寫日誌 = WAL）。但上面提出的正是一般概念，允許不考慮這些細微差別。

同步（sync）複製

讓我們添加邏輯以將收到的更改複製到事務提交演算法：

  1. 將交易記錄到資料庫日誌中。
  2. 在資料庫引擎中使用交易。
  3. 將資料傳送到所有副本。
  4. 從所有副本接收交易已完成的確認。
  5. 向客戶端傳回交易已成功應用的確認訊息。

這種方法有很多缺點：

  • 客戶端等待變更應用於所有副本。
  • 隨著叢集中節點數量的增加，我們會降低寫入操作成功的可能性。

如果第一點的內容或多或少都清楚了，那麼第二點的原因就值得解釋了。如果在同步複製期間我們沒有收到至少一個節點的回應，我們就會回滾事務。因此，透過增加叢集中的節點數量，會增加寫入操作失敗的可能性。

我們可以只等待一定比例的節點（例如 51%（法定人數））的確認嗎？是的，可以，但是在經典版本中，需要所有節點的確認，因為這樣才能保證叢集中資料的完全一致性，這也是這種複製方式無疑的優勢。

異步（async）複製

我們來修改一下之前的演算法。我們將“稍後”將資料傳送到副本，並且“稍後”變更將應用於副本：

  1. 將交易記錄到資料庫日誌中。
  2. 在資料庫引擎中使用交易。
  3. 向客戶端傳回交易已成功應用的確認訊息。
  4. 將資料傳送到副本並對它們套用變更。

這種方法導致叢集運行速度很快，因為我​​們不需要讓客戶端等待資料到達副本，甚至被提交。

但是“稍後”將資料轉儲到副本上的情況可能會導致事務丟失，並導致用戶確認的事務丟失，因為如果資料沒有時間複製，則向客戶端發送的確認關於操作成功發送，並且更改到達的節點崩潰了HDD，我們遺失了事務，這可能會導致非常不愉快的後果。

半同步複製

最後我們討論半同步複製。這種類型的複製並不是很為人所知或很常見，但它引起了相當大的興趣，因為它可以結合同步和非同步複製的優點。

讓我們試著結合前面的兩種方法。我們不會長期保留客戶端，但我們會要求複製資料：

  1. 將交易記錄到資料庫日誌中。
  2. 在資料庫引擎中使用交易。
  3. 將資料傳送到副本。
  4. 從副本收到更改已收到的確認（它們將“稍後”應用）。
  5. 向客戶端傳回交易已成功應用的確認訊息。

請注意，使用此演算法，僅當接收變更的節點和副本節點都發生故障時，才會發生交易遺失。這種失敗的可能性被認為很低，而且這些風險是可以接受的。

但這種方法可能有幻讀的風險。讓我們想像以下場景：在步驟 4 中，我們沒有收到任何副本的確認。我們必須回滾該交易並且不向客戶端回傳確認。由於資料是在步驟2中應用的，因此在步驟2結束和事務回滾之間存在時間間隔，在此期間並行事務可以看到不應該在資料庫中的變更。

無損半同步複製

如果你稍微想一下，你可以反轉演算法的步驟並修復這種情況下的幻讀問題：

  1. 將交易記錄到資料庫日誌中。
  2. 發送副本資料。
  3. 從副本收到更改已收到的確認（它們將“稍後”應用）。
  4. 在資料庫引擎中使用交易。
  5. 向客戶端傳回交易已成功應用的確認訊息。

現在，只有當變更已複製時，我們才會提交變更。

產量

一如既往，不存在理想的解決方案；存在一組解決方案，每個解決方案都有自己的優點和缺點，適合解決不同類別的問題。對於選擇同步複製資料庫中的資料的機制來說，這絕對是正確的。半同步複製所具有的一系列優點足夠紮實和有趣，儘管其普及率較低，但仍值得關注。

就這樣。見 課程!

來源： www.habr.com

添加評論