1、介紹

在分布式系統(tǒng)中，樂(lè)觀鎖、冪等性設(shè)計(jì)和數(shù)據(jù)插入失敗處理是保障數(shù)據(jù)一致性和系統(tǒng)可靠性的三大核心機(jī)制，它們共同協(xié)作以解決并發(fā)沖突、重復(fù)請(qǐng)求和網(wǎng)絡(luò)異常等問(wèn)題。

1.樂(lè)觀鎖：
通過(guò)在數(shù)據(jù)庫(kù)中添加 version或 timestamp字段，確保并發(fā)更新時(shí)的數(shù)據(jù)一致性。每次更新時(shí)檢查版本號(hào)是否匹配。

若匹配則更新并遞增版本號(hào)，否則拋出異常（如 StaleObjectStateException）。適用于讀多寫(xiě)少的場(chǎng)景，減少鎖競(jìng)爭(zhēng)，但需業(yè)務(wù)層配合處理沖突重試。

2.冪等性設(shè)計(jì)：
確保同一請(qǐng)求多次執(zhí)行的結(jié)果與一次執(zhí)行相同，常用于支付、訂單等關(guān)鍵業(yè)務(wù)。通過(guò) 唯一業(yè)務(wù)標(biāo)識(shí)符（如訂單號(hào)）、請(qǐng)求ID、數(shù)據(jù)庫(kù)唯一約束或 緩存記錄來(lái)攔截重復(fù)請(qǐng)求。例如，插入訂單前先檢查 order_no是否已存在，若存在則直接返回結(jié)果，避免重復(fù)操作。

3.數(shù)據(jù)插入失敗的處理：

網(wǎng)絡(luò)宕機(jī)：

若插入操作未提交，數(shù)據(jù)庫(kù)事務(wù)會(huì)自動(dòng)回滾；若已提交部分?jǐn)?shù)據(jù)，需通過(guò)補(bǔ)償機(jī)制（如回滾或修復(fù)）修正。

重試機(jī)制：

在網(wǎng)絡(luò)恢復(fù)后，客戶端可結(jié)合 指數(shù)退避算法重試請(qǐng)求，但需確保重試操作是冪等的（如通過(guò)唯一約束或請(qǐng)求ID）。

異步隊(duì)列：

將請(qǐng)求放入消息隊(duì)列（如 Kafka、RabbitMQ），確保網(wǎng)絡(luò)中斷時(shí)消息不丟失，恢復(fù)后繼續(xù)處理。

典型場(chǎng)景示例：

用戶提交支付請(qǐng)求時(shí)，系統(tǒng)通過(guò) order_no的唯一約束防止重復(fù)訂單，使用樂(lè)觀鎖避免并發(fā)修改價(jià)格，若網(wǎng)絡(luò)中斷則通過(guò)重試機(jī)制重新提交（但依賴冪等性設(shè)計(jì)避免重復(fù)扣款）。

核心目標(biāo)：

通過(guò) 樂(lè)觀鎖保證數(shù)據(jù)一致性，冪等性防止重復(fù)操作，重試與補(bǔ)償應(yīng)對(duì)網(wǎng)絡(luò)異常，三者結(jié)合構(gòu)建高可用、可靠的分布式系統(tǒng)。

2、樂(lè)觀鎖

MySQL的樂(lè)觀鎖是一種并發(fā)控制機(jī)制，它假設(shè)數(shù)據(jù)沖突（多個(gè)事務(wù)同時(shí)修改同一數(shù)據(jù)）的概率較低，因此在讀取數(shù)據(jù)時(shí)不加鎖，而是在更新時(shí)檢查數(shù)據(jù)是否被其他事務(wù)修改過(guò)。如果沖突發(fā)生，事務(wù)會(huì)失敗并重試。

2.1、核心思想

• 讀取數(shù)據(jù)時(shí)：記錄數(shù)據(jù)的版本號(hào)（或時(shí)間戳）。
• 更新數(shù)據(jù)時(shí)：檢查版本號(hào)是否一致，如果一致則更新，否則拋出異常（沖突）。

2.2、實(shí)現(xiàn)方式

在MySQL中，樂(lè)觀鎖通常通過(guò)以下方式實(shí)現(xiàn)：

1. 使用 version字段（推薦）

• 在表中添加一個(gè) version字段（整數(shù)類型），每次更新時(shí)自動(dòng)遞增。
• 讀取數(shù)據(jù)時(shí)獲取當(dāng)前 version值。
• 更新時(shí)將 version作為條件，如果匹配則更新并遞增 version。

示例表結(jié)構(gòu)

CREATE TABLE product (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    price DECIMAL(10,2),
    version INT DEFAULT 0  -- 樂(lè)觀鎖版本號(hào)
);

示例操作

1.讀取數(shù)據(jù)：

SELECT id, name, price, version FROM product WHERE id = 1;
-- 假設(shè)返回: id=1, name='Apple', price=10.00, version=5

2.更新數(shù)據(jù)（帶版本號(hào)檢查）：

UPDATE product 
SET price = 12.00, version = version + 1 
WHERE id = 1 AND version = 5;

3.判斷是否更新成功：

如果 version=5的記錄還存在，則更新成功。

如果 version已經(jīng)被其他事務(wù)修改為 6，則更新失敗（影響行數(shù)為0），此時(shí)需要拋出異?；蛑卦嚒?/p>

2. 使用 timestamp字段

• 類似 version字段，但使用 TIMESTAMP或 DATETIME類型。
• 每次更新時(shí)自動(dòng)更新該字段。
• 更新時(shí)檢查 timestamp是否匹配。

1.讀取數(shù)據(jù)：

SELECT id, name, price, update_time FROM product WHERE id = 1;
-- 假設(shè)返回: id=1, name='Apple', price=10.00, update_time='2023-10-01 12:00:00'

2.更新數(shù)據(jù)（帶時(shí)間戳檢查）：

UPDATE product 
SET price = 12.00, update_time = NOW() 
WHERE id = 1 AND update_time = '2023-10-01 12:00:00';

3.判斷是否更新成功：

如果 update_time匹配，則更新成功。

否則更新失?。ㄓ绊懶袛?shù)為0）。

2.3、如何處理沖突

當(dāng)樂(lè)觀鎖檢測(cè)到?jīng)_突時(shí)（更新失?。?，應(yīng)用程序需要：

• 拋出異常（如 StaleObjectStateException）。
• 重試邏輯：重新讀取數(shù)據(jù)，重新嘗試更新（可能需要限制重試次數(shù)）。

代碼示例（Java）

int retryCount = 0;
while (retryCount < MAX_RETRIES) {
    Product product = getProductFromDatabase(productId); // 包含 version
    product.setPrice(newPrice);
    int rowsUpdated = updateProductInDatabase(product); // 使用 version 條件更新
    if (rowsUpdated == 1) {
        break; // 更新成功
    } else {
        retryCount++;
        // 可能需要等待一段時(shí)間再重試
    }
}
if (retryCount >= MAX_RETRIES) {
    throw new RuntimeException("樂(lè)觀鎖重試失敗");
}

小結(jié)：

它適用于讀多寫(xiě)少或沖突概率低的場(chǎng)景，能有效提高并發(fā)性能，但需要業(yè)務(wù)層配合實(shí)現(xiàn)沖突處理邏輯。

如下圖所示：

對(duì)比于悲觀鎖

2.4、樂(lè)觀鎖局限性

需要業(yè)務(wù)層配合：必須顯式實(shí)現(xiàn)版本號(hào)檢查和重試邏輯。

無(wú)法完全避免沖突：在極端高并發(fā)下仍可能發(fā)生沖突。

不適合復(fù)雜事務(wù)：如果事務(wù)涉及多個(gè)表，樂(lè)觀鎖可能難以維護(hù)一致性。

3、冪等性

通過(guò)上面對(duì)于樂(lè)觀鎖的介紹，感覺(jué)是不是可以作為冪等性的處理手段呢？

樂(lè)觀鎖可以作為處理冪等性問(wèn)題的一種手段，但它的作用和適用范圍需要結(jié)合具體場(chǎng)景來(lái)看。

3.1、什么是冪等性

冪等性（Idempotency）是指同一個(gè)操作多次執(zhí)行的結(jié)果與執(zhí)行一次的結(jié)果相同。

例如：

• 發(fā)送重復(fù)的支付請(qǐng)求，不會(huì)導(dǎo)致重復(fù)扣款。
• 提交重復(fù)的訂單，不會(huì)生成多個(gè)訂單。
• 更新資源時(shí)，多次相同請(qǐng)求不會(huì)改變最終狀態(tài)。

冪等性設(shè)計(jì)的核心目標(biāo)：防止因網(wǎng)絡(luò)重傳、用戶重復(fù)點(diǎn)擊、系統(tǒng)故障等原因?qū)е碌闹貜?fù)請(qǐng)求對(duì)業(yè)務(wù)邏輯產(chǎn)生副作用。

3.2、樂(lè)觀鎖與冪等性的關(guān)系

樂(lè)觀鎖（Optimistic Locking）主要用于解決并發(fā)更新時(shí)的數(shù)據(jù)一致性問(wèn)題，而冪等性解決的是重復(fù)請(qǐng)求對(duì)業(yè)務(wù)邏輯的影響。兩者的結(jié)合可以增強(qiáng)系統(tǒng)的健壯性。

1. 樂(lè)觀鎖如何輔助冪等性？

樂(lè)觀鎖通過(guò) 版本號(hào)（version）或時(shí)間戳（timestamp）保證數(shù)據(jù)更新的原子性，防止并發(fā)沖突。

在某些場(chǎng)景下，它可以間接支持冪等性：

• 場(chǎng)景：更新某個(gè)資源時(shí)，重復(fù)的請(qǐng)求可能因版本號(hào)不匹配而失敗，避免重復(fù)操作。
• 示例：用戶多次提交更新請(qǐng)求，若第一次請(qǐng)求已修改了數(shù)據(jù)版本號(hào)，后續(xù)重復(fù)請(qǐng)求會(huì)因版本號(hào)不一致而失敗，從而避免重復(fù)操作。

2. 樂(lè)觀鎖的局限性

樂(lè)觀鎖無(wú)法直接解決冪等性問(wèn)題，因?yàn)樗惶幚?ldquo;重復(fù)請(qǐng)求”的識(shí)別和過(guò)濾。

例如：

• 如果用戶多次提交相同的請(qǐng)求參數(shù)（如相同的訂單號(hào)、交易號(hào)），樂(lè)觀鎖無(wú)法識(shí)別這是重復(fù)請(qǐng)求，只會(huì)檢查版本號(hào)是否沖突。
• 如果請(qǐng)求參數(shù)不同（如不同的版本號(hào)），樂(lè)觀鎖可能允許更新，但業(yè)務(wù)邏輯可能需要拒絕重復(fù)操作。

3.3、如何設(shè)計(jì)

在實(shí)際開(kāi)發(fā)中，通常需要將樂(lè)觀鎖與其他冪等性策略結(jié)合使用，例如：

• 唯一業(yè)務(wù)標(biāo)識(shí)符（Business Key）
• 請(qǐng)求ID（Request ID）
• 數(shù)據(jù)庫(kù)唯一約束
• 緩存記錄已處理的請(qǐng)求

示例：支付接口的冪等性設(shè)計(jì)

假設(shè)用戶發(fā)起支付請(qǐng)求，接口需要確保同一筆訂單不會(huì)被重復(fù)扣款：

-- 表結(jié)構(gòu)
CREATE TABLE orders (
    id INT PRIMARY KEY,
    order_no VARCHAR(50) UNIQUE,  -- 唯一業(yè)務(wù)標(biāo)識(shí)符
    amount DECIMAL(10,2),
    status VARCHAR(20),
    version INT DEFAULT 0  -- 樂(lè)觀鎖版本號(hào)
);

處理流程：

• 客戶端發(fā)送請(qǐng)求，包含 order_no和 request_id（唯一請(qǐng)求ID）。
• 服務(wù)端處理：
  • 檢查緩存或數(shù)據(jù)庫(kù)，是否存在已處理的 order_no或 request_id。
    • 如果存在，直接返回結(jié)果（冪等性保障）。
    • 如果不存在，繼續(xù)處理。
  • 執(zhí)行支付操作時(shí)，使用樂(lè)觀鎖更新訂單狀態(tài)：

UPDATE orders 
SET status = 'PAID', version = version + 1 
WHERE id = ? AND version = ?;

如果更新失敗（版本號(hào)不匹配），說(shuō)明訂單狀態(tài)已被其他事務(wù)修改，需重試或報(bào)錯(cuò)。

關(guān)鍵點(diǎn)：

• 唯一業(yè)務(wù)標(biāo)識(shí)符（order_no）：直接過(guò)濾重復(fù)請(qǐng)求。
• 請(qǐng)求ID（request_id）：記錄已處理的請(qǐng)求，避免重復(fù)消費(fèi)。
• 樂(lè)觀鎖（version）：防止并發(fā)更新導(dǎo)致的數(shù)據(jù)不一致。

3.4、order_no 添加唯一約束

1、防止重復(fù)創(chuàng)建訂單

假設(shè)用戶點(diǎn)擊“提交訂單”按鈕多次，或網(wǎng)絡(luò)重傳導(dǎo)致相同請(qǐng)求被多次發(fā)送。如果沒(méi)有唯一約束，可能會(huì)導(dǎo)致以下問(wèn)題：

• 重復(fù)插入訂單：系統(tǒng)生成多個(gè)相同 order_no的訂單，浪費(fèi)資源。
• 業(yè)務(wù)邏輯混亂：例如，重復(fù)扣款、重復(fù)發(fā)貨等。

-- 假設(shè)沒(méi)有唯一約束
INSERT INTO orders (order_no, amount) VALUES ('20231001-001', 100);
-- 用戶重復(fù)提交相同訂單號(hào)
INSERT INTO orders (order_no, amount) VALUES ('20231001-001', 100); -- 會(huì)成功插入第二條數(shù)據(jù)！

后果：系統(tǒng)會(huì)認(rèn)為這是兩個(gè)不同的訂單，可能導(dǎo)致重復(fù)扣款、庫(kù)存異常等問(wèn)題。

2、保證業(yè)務(wù)邏輯的正確性

order_no是業(yè)務(wù)的核心標(biāo)識(shí)符，如果允許重復(fù)，會(huì)導(dǎo)致：

• 數(shù)據(jù)不一致：無(wú)法通過(guò) order_no準(zhǔn)確查詢或修改訂單。
• 冪等性失效：重復(fù)請(qǐng)求無(wú)法被攔截，破壞系統(tǒng)的一致性。

示例：

-- 有唯一約束后，第二次插入會(huì)失敗
INSERT INTO orders (order_no, amount) VALUES ('20231001-001', 100); -- 成功
INSERT INTO orders (order_no, amount) VALUES ('20231001-001', 100); -- 報(bào)錯(cuò)：Duplicate entry

3、支持冪等性設(shè)計(jì)

唯一約束是實(shí)現(xiàn)冪等性的關(guān)鍵手段之一：

• 冪等性：同一請(qǐng)求多次執(zhí)行的結(jié)果與執(zhí)行一次的結(jié)果相同。
• 唯一約束：通過(guò)數(shù)據(jù)庫(kù)層強(qiáng)制攔截重復(fù)請(qǐng)求，避免業(yè)務(wù)邏輯重復(fù)執(zhí)行。

示例：

-- 用戶多次提交相同的訂單號(hào)
BEGIN TRANSACTION;
  -- 嘗試插入訂單
  INSERT INTO orders (order_no, amount) VALUES ('20231001-001', 100);
COMMIT;
-- 如果已經(jīng)存在相同 order_no，會(huì)拋出異常，事務(wù)回滾，避免重復(fù)操作

4、節(jié)點(diǎn)故障場(chǎng)景

在插入數(shù)據(jù)的過(guò)程中如果發(fā)生網(wǎng)絡(luò)宕機(jī)，處理方式取決于數(shù)據(jù)庫(kù)的事務(wù)機(jī)制、應(yīng)用層的容錯(cuò)設(shè)計(jì)以及網(wǎng)絡(luò)恢復(fù)后的重試策略。

以下是詳細(xì)的分析和解決方案：

4.1. 數(shù)據(jù)庫(kù)層面

1、事務(wù)的原子性

如果插入操作被包裹在事務(wù)中（例如使用 BEGIN TRANSACTION和 COMMIT），且數(shù)據(jù)庫(kù)支持事務(wù)（如 MySQL 的 InnoDB 引擎）：

• 網(wǎng)絡(luò)中斷時(shí)：事務(wù)未提交，數(shù)據(jù)庫(kù)會(huì)自動(dòng)回滾未提交的更改。
• 恢復(fù)后：需要重新發(fā)送插入請(qǐng)求。
• 示例（MySQL）：

BEGIN;
INSERT INTO orders (order_no, amount) VALUES ('20231001-001', 100);
-- 網(wǎng)絡(luò)中斷，事務(wù)未提交，數(shù)據(jù)不會(huì)寫(xiě)入數(shù)據(jù)庫(kù)

2、自動(dòng)提交（Autocommit）

• 如果數(shù)據(jù)庫(kù)處于自動(dòng)提交模式（默認(rèn)開(kāi)啟），每次插入操作會(huì)立即提交：
  • 網(wǎng)絡(luò)中斷時(shí)：可能已部分提交數(shù)據(jù)（如部分字段寫(xiě)入），導(dǎo)致數(shù)據(jù)不一致。
  • 解決方案：在應(yīng)用層顯式關(guān)閉自動(dòng)提交，手動(dòng)控制事務(wù)邊界。

4.2. 應(yīng)用層

• 1、重試機(jī)制
  • 重試邏輯：在網(wǎng)絡(luò)恢復(fù)后，客戶端可以重試插入請(qǐng)求。
  • 關(guān)鍵點(diǎn)：需確保重試操作是冪等的（見(jiàn)下文）。
• 重試策略：
  • 指數(shù)退避（Exponential Backoff）：重試間隔逐漸增大（如 1s → 2s → 4s → ...），避免網(wǎng)絡(luò)擁塞。
  • 最大重試次數(shù)限制：防止無(wú)限循環(huán)重試（如最多重試 3 次）。
• 2、冪等性設(shè)計(jì)
  • 唯一約束：通過(guò)數(shù)據(jù)庫(kù)的 UNIQUE 約束（如訂單號(hào) order_no）防止重復(fù)插入。
  • 示例：即使重試，只要 order_no 唯一，重復(fù)插入會(huì)失敗，避免數(shù)據(jù)冗余。
  • 請(qǐng)求 ID（Request ID）：為每個(gè)請(qǐng)求生成唯一 ID，記錄已處理的請(qǐng)求。
  • 示例：在插入前檢查請(qǐng)求 ID 是否已存在，若存在則直接返回結(jié)果。
• 3、異步消息隊(duì)列
  • 可靠性隊(duì)列：將插入操作放入消息隊(duì)列（如 Kafka、RabbitMQ），確保網(wǎng)絡(luò)中斷時(shí)消息不丟失。
  • 生產(chǎn)者：將插入請(qǐng)求發(fā)送到隊(duì)列，即使網(wǎng)絡(luò)中斷，消息仍保留在隊(duì)列中。
  • 消費(fèi)者：網(wǎng)絡(luò)恢復(fù)后，繼續(xù)消費(fèi)消息并執(zhí)行插入操作。
  • 優(yōu)點(diǎn)：解耦生產(chǎn)與消費(fèi)，提高系統(tǒng)魯棒性。

4.3. 網(wǎng)絡(luò)恢復(fù)后的處理

1、客戶端檢測(cè)網(wǎng)絡(luò)狀態(tài)

• 心跳機(jī)制：客戶端定期檢測(cè)與數(shù)據(jù)庫(kù)的連接狀態(tài)。
• 自動(dòng)重連：網(wǎng)絡(luò)恢復(fù)后，客戶端自動(dòng)重新建立連接并重試未完成的請(qǐng)求。

2、服務(wù)端日志與監(jiān)控

• 記錄失敗請(qǐng)求：在服務(wù)端記錄失敗的插入請(qǐng)求（如日志或數(shù)據(jù)庫(kù)表），便于人工介入處理。
• 告警通知：通過(guò)監(jiān)控工具（如 Prometheus、Zabbix）檢測(cè)異常，及時(shí)通知運(yùn)維人員。

總結(jié)：

最新評(píng)論