海量數據冷熱分離方案與實踐

背景

隨着財經支付業務的快速發展，考慮到未來訂單量持續增長，在線存儲遇到更大的挑戰，需提前做好規劃。目前財經支付主要業務都是使用 mysql（InnoDB）作爲數據存儲，因歷史訂單信息訪問頻率低並佔用了大量數據庫存儲空間，期望將歷史數據跟生產最新交易數據進行分離，當前數據庫保留最近一段時間的數據作爲熱庫，歷史交易存入另一個數據庫壓縮存儲作爲冷庫 (rocksdb)，即數據庫冷熱分離。此舉將會極大的節省數據庫設備成本，減少因在線存儲空間不足擴容導致停服不可用的時長，以下基於財經支付的統一交易系統現狀做的相關案例分析僅供大家參考。

方案

技術選型

架構圖

方案分析

因業務場景比較複雜，如果按照業務場景梳理工作量將幾何倍的增長，換種維度，數據庫相關的操作無非就是查詢、插入、更新，只要能在數據庫交互層實現保證查詢、插入、更新這些數據庫基本操作在增加冷熱分離後功能不受影響即可。財經支付代碼有統一的分層規範，對數據庫操作全部收斂封裝至數據庫交互層，因此比較好改造，不擴容的情況下，熱庫預計保留最近 X 天（時間可調）數據， X 天前的數據歸檔到冷庫。

方案對比

方案選擇

交易： 交易表負責記錄商戶訂單與財經支付內部訂單的映射、交易金額、買方和賣方等重要信息，最重要的功能是防止重複交易。但是冷庫相比熱庫性能較低，商戶訂單號無固定規則，無法根據單號判斷時間過濾減少冷庫壓力，而熱庫 cpu 使用率很低，熱庫數據庫計算不是瓶頸，因此交易選用方案二。交易歸檔表主要意義在於減少在線交易對冷庫的依賴。

支付： 支付表負責保存交易單用了什麼支付方式、該支付方式需要扣多少錢、從哪裏扣、扣到哪裏去等信息，涉及的訂單查詢、更新、插入都可以根據交易單號或者支付單號進行判斷時間減少對冷庫的查詢，因此支付選擇方案一。

基本原則

爲了充分的保證 0 事故，0 資損，方案設計時，提出了以下基本原則，在研發、測試、代碼評審時均參考以下基本原則進行層層把控，可以有效的避免生產事故的發生。

數據插入唯一性：

數據更新一致性：

數據查詢準確性：

具體細節

歸檔表結構

歸檔表狀態流轉

一致性刪除

使用冷庫記錄的所有字段當作刪除熱庫的 where 條件（包含自增 id）, 刪除熱庫和更新熱庫歸檔狀態爲冷庫需在一個事物，任一失敗則回滾。

交易及支付任務（數據歸檔、刪除、兜底）

歸檔任務

查詢熱庫訂單表 X （時間可調）天前的訂單，同步熱庫訂單到冷庫，插入熱庫歸檔表，歸檔狀態爲處理中，放入延遲刪除 mq 消息。

歸檔刪除 TASK

常駐服務 TASK 消費刪除 mq 消息，rpc 調用交易支付提供的刪除接口，支持本地限流能力。

兜底任務：

主要功能： 查詢熱庫歸檔表中處理中修改時間超過規定時間的訂單強制執行刪除操作。主要用來防止 mq 異常或者日常丟失消息時，使用兜底任務可以補償消化處理中的歸檔記錄。

執行邏輯

數據歸檔任務（每天啓動一次）
for {
   初始化查詢時間範圍和分頁
   for{
        查詢 X 天前交易單 limit 1000(索引排序，滾動時間查詢)
        if 記錄存在 並且 條數=1000 {
           for 對於每條記錄 {
            // 啓用x個協程處理
            交易單冪等寫入冷庫（不保證最新，只保證冷庫數據存在性）
            冪等寫歸檔記錄表（type: PROCESSING，熱庫數據刪除時再更新爲COLD，歸檔記錄已存在HOT狀態更新爲PROCESSING ）
            發MQ延遲消息，X min（可配置）後刪除熱庫數據
            }
        }
        if 條數=1000 {
            continue
        }
        時間範圍往下推進
        //記錄不存在
        if 結束時間超過規定時間{
            break (跳出循環，任務結束)
        }
        redis記錄當前查詢條件，方便後續任務重跑恢復繼續
       }
}

刪除熱庫數據，消費MQ
消費MQ記錄 {
    查詢冷庫
    數據一致性刪除（開啓事務 條件刪除熱庫數據，更新歸檔記錄表狀態爲COLD 結束事務）
    一致性刪除熱庫失敗，同步熱庫數據到冷庫，數據一致性刪除
}

兜底補償任務（每30分鐘啓動一次）
{
    查詢歸檔記錄表中狀態爲PROCESSING，修改時間爲X +Y min前的記錄 limit 1000
    if 不存在 {
        break
    }
    for 對於每條記錄
        查詢冷庫
        數據一致性刪除（開啓事務 條件刪除熱庫數據，更新歸檔記錄表狀態爲COLD 結束事務）
        一致性刪除熱庫失敗，同步熱庫數據到冷庫，數據一致性刪除
    }
}

歸檔任務查詢時間滾動機制： 時間範圍第一次起始時間爲固定日期（財經支付訂單最早點日期），結束時間爲指定日期，下次開始時間等於上次結束時間，結束時間爲上次結束時間加上指定時間範圍）。每次查詢下一個時間窗口時 redis 保存信息，指定日期，當天任務的時間範圍，分頁數。

歸檔任務併發處理： 需支持多任務分片併發處理

提升全天歸檔訂單量： 爲了不影響在線交易，全天 24 小時 區分 交易高峯、低峯、日常 三個不同時間段，歸檔速度不同。

交易 - 有歸檔表（查詢、新增、更新）

特點: 唯一鍵有外部單號，訂單規則隨機無法根據單號判斷時間，因此必須有歸檔表。

查詢

邏輯在數據庫交互層統一實現處理

存在以下部分情況可做特殊處理減少數據庫冷庫依賴。

更新

邏輯在數據庫交互層統一實現處理

插入

邏輯在數據庫交互層統一實現處

支付 - 無歸檔表（查詢、新增、更新）

特點: 唯一鍵都爲內部單號，現有主要查詢可以根據單號判斷時間，不需要歸檔表，可以徹底解決熱庫數據庫存儲問題。

查詢

邏輯在數據庫交互層統一實現處理

存在以下部分情況可做特殊處理減少數據庫冷庫依賴。

更新

邏輯在數據庫交互層統一實現處理

插入

邏輯在數據庫交互層統一實現處

總結

  1. 支付因沒有歸檔表徹底解決了數據庫存儲壓力問題，大大的節省了數據庫存儲資源。

  2. 交易因新增了歸檔表，大大延緩了熱庫數據庫存儲壓力，爲交易數據庫又額外提供了緩衝擴容時間，爲後續再次優化徹底交易解決數據庫存儲問題提供了充足的時間。

成果

  1. 徹底解決了支付數據庫存儲壓力問題，有效的緩解了交易數據庫熱庫的存儲壓力。

  2. 數據庫熱庫保留天數可靈活調控，可以根據後續訂單量進行合理調整存儲可用天數。

缺點

  1. 交易採用方案二新增了歸檔表，並且歸檔表裏的存儲的全量數據，僅能減緩交易和支付數據庫的存儲空間緊張情況，無法徹底解決數據庫存儲問題。

  2. 交易表釋放的 datafree 存儲空間無法提供給歸檔表使用，僅能交易表使用，需要不定期釋放交易表的 datafree 空間。

加入我們

財經支付作爲公共的支付服務，爲業務提供穩定、高效、豐富的資金相關服務；抖音支付作爲字節自己的支付產品，能夠幫助用戶更好地消費購物，歡迎大家加入字節跳動財經團隊。

字節跳動技術團隊 字節跳動的技術實踐分享

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ZKRkZP6rLHuTE1wvnqmAPQ

猜你喜歡