OLTP類系統數據結轉最佳實踐

一、 背景介紹

業務系統在長期運行的過程中會積累大量的數據，這些數據有些是需要長期保存的，例如一些訂單數據，有些只需要短期保存，例如一些日志信息。業務數據一般都會有一個生命周期，生命周期內的我們叫生產數據，生命周期之外(即業務已經關閉)的叫歷史數據，我們這里提到的數據結轉，指的是將需要長期保存的歷史數據從生產庫遷移到歷史庫(轉)，而將需要短期保存的數據定期刪除(結)。

我們已經進入了大數據時代，但在OLTP類系統中，關系型數據庫依然占據主導地位，在關系型數據庫中，如果不及時進行數據結轉，會嚴重影響系統的性能。

關系型數據庫單機容量有限，因此業界普遍的做法是進行垂直分庫和水平分片，一些大型互聯網企業由于業務量龐大，僅分片的集群規模就能達到上千節點，再加上分庫的集群，規模非常巨大。傳統的數據歸檔方法往往針對單庫操作，難以處理如此大規模集群的數據歸檔。

同時，在大型互聯網企業，每日的數據增長量非常大，數據結轉的頻率遠大于傳統行業，這些行業的IT系統往往是7*24小時不間斷提供服務，而且全天24小時的并發量都很大，因此數據結轉操作必須盡量減少對生產庫的性能影響。

為此，我們自主研發了數據結轉平臺，以解決大數據背景下的數據結轉問題。

二、 技術架構

2.1 設計要點

(1)盡量減少對生產庫的影響

數據結轉操作沒有復雜的業務邏輯，因此對數據庫性能的影響主要體現在IO方面，減少對生產庫的影響，最主要的就是減少對生產庫的IO操作。目前我們采用的方案是通過從庫查詢數據，將數據插入歷史庫，然后再從主庫中刪除，如圖1數據結轉邏輯圖所示，將查詢的IO操作轉嫁到從庫上，可以大大減輕對主庫的影響。為了保障數據庫的高可用，業內基本都采用了主從部署模式，因此這個方案具有很高的通用性。

圖1 數據結轉邏輯圖

(2)支持分庫分片集群

我們希望數據結轉平臺的配置足夠簡單并且易于理解。在和用戶的溝通過程中，我們發現他們最強烈的需求就是分庫分片集群的數據結轉。傳統的單機數據結轉操作可以抽象描述為：將數據庫實例A中表B的歷史數據結轉到歷史庫C，用戶的配置主要有4個元素：生產庫實例A、結轉表B、結轉條件和歷史庫。對于大規模的分庫分片集群規模，如果采用傳統單機數據結轉的配置方式，每一個數據庫實例都要配置4個元素，配置量非常大。

在我們的方案中，按照圖2所示對數據庫集群進行劃分，將主庫、從庫、歷史庫作為一個結轉單元，對于分片的數據庫集群，表結構相同，我們將其作為一個分組，對于分庫的集群，表結構不同則劃分為不同的分組。用戶進行配置的時候不是面向一個數據庫實例，而是面向一個分組，數據結轉操作抽象為：結轉分組X中表B的歷史數據，用戶的配置元素有3個：分組X、結轉表B和結轉條件。分組信息僅需配置一次。這樣大大簡化了用戶的配置工作。

(3)支持水平擴展

由于數據庫集群規模較大，數據結轉平臺應該具備水平擴展能力。我們采用的方案是將數據結轉最核心的組件定時任務和數據庫操作(數據結轉執行器)獨立出來，進行分布式部署。如下圖3所示，

圖2 數據庫集群模型

配置中心為用戶的入口，用戶通過配置中心定義數據結轉任務，任務的關鍵屬性包括：觸發條件、執行條件、目標分組等，配置中心將結轉任務分發給代理程序，同時對代理程序的執行狀態進行監控。結轉任務的觸發條件配置在代理程序中的定時任務中，而執行條件和目標分組則作為數據結轉執行器的執行參數。通過水平擴展代理程序，我們對更多的數據庫進行結轉。

圖3 數據結轉組件關系圖

2.2 總體架構

綜合上面提到的3個設計要點，我們得到圖4所示的總體架構，需要特別說明的是，對于水平分片的分組，我們采用的是多線程結轉，對于不同結轉單元不存在數據共享問題，所以無需考慮并發鎖等問題。

三、 一些經驗總結

a) 配置中心與代理程序之間的信息同步

圖4 數據結轉總體架構圖

配置中心和代理程序在我們的方案中被設計為一種松耦合結構：在系統的運行過程中，代理程序宕機不會影響配置中心的運行，同樣配置中心短暫的不可用也不會影響代理程序的運行。松耦合結構可以大大增強系統的可用性，而且配置中心、代理程序升級的時候不會影響整個系統的正常運行。

為了實現松耦合的結構，配置中心與代理程序之間的信息同步我們都是采用的異步處理，比如配置中心向代理程序分發結轉任務，實際處理的時候我們采用的是拉的方式，而不是推的方式，我們在配置中心和代理程序之間維持了一個心跳，心跳的內容是代理程序負載的所有結轉任務的校驗碼(該校驗碼在代理程序向配置中心發送心跳信息時由配置中心計算)，當代理程序發現從配置中心得到的校驗碼和本地校驗碼不同時，則說明用戶對結轉任務進行了修改(包括新增、修改、刪除)，此時代理程序主動向配置中心發起同步結轉任務的請求。這樣做的好處是，代理程序在發生宕機重啟后，會自動進行任務的同步。

b) 進度可視化

結轉任務的進度在我們的方案中是實時匯總到配置中心的，我們稱為進度可視化，代理程序通過一個獨立的線程來異步處理進度可視化，一方面這樣可以降低對結轉任務性能的干擾，另一方面可以避免由于網絡問題、配置中心暫時不可用等問題導致結轉任務異常。進度可視化對于用戶來說非常重要，用戶在第一次定義結轉任務并執行該任務的時候，進度可視化信息是用戶和系統互動的唯一窗口，對用戶來說是莫大的心理安慰。

c) 異?？梢暬?

代理程序在執行數據結轉任務時，會遇到各種異常信息，比如數據庫URL配置錯誤，歷史庫生產庫表結構不一致等，對于這些異常信息，除了在本地記錄日志外，我們還將它們發送到了配置中心。將這些異?？梢暬?，而不是讓用戶在大量的日志中去檢索，這種方式非常便于在線問題的診斷。

d) 事務一致性

將生產庫數據轉到歷史庫本身是一個分布式的事務，在我們的方案中，不能保證數據的強一致性，比如在歷史數據Insert到歷史庫的瞬間，用戶修改了生產庫的數據，我們的方案不會檢測這種變化，會導致用戶的修改并不會反映到歷史庫中，造成數據不一致。雖然在生產庫中刪除歷史數據時，可以增加強一致性的校驗，以解決這種問題，但是這樣會對生產庫造成一定的壓力，同時考慮到這種情況發生的概率極低，因此并沒有進行特殊處理。

歷史數據Insert到歷史庫后，可能由于某種異常導致生產庫執行Delete操作時失敗，此時會造成數據冗余(生產庫和歷史庫存在相同數據)。對于這種問題，我們的方案是利用Redo Log(重做日志)機制，在結轉任務重新執行時根據Redo Log恢復異?，F場，糾正異常數據。

e) 結轉數據的回滾

我們提供了一個數據回滾功能，可以將已經結轉到歷史庫的數據逆向回滾到生產庫，用戶可以配置Where條件精確指定需要回滾的數據。有些特殊情況，業務上需要對已經結轉的歷史數據進行修改，該功能主要用于處理這種情況。同時在測試階段，我們可以通過該功能快速恢復測試數據，方便對數據結轉平臺的測試。

f) 代理程序的自動升級

代理程序和配置中心本質上是一種典型的C/S(客戶端/服務端)結構，客戶端是多實例部署，服務器端是集群部署，為了系統能夠平滑地進行升級，我們需要對客戶端的版本進行統一管理，同時我們提供了代理程序的自動升級功能，系統管理員可以通過配置中心對代理程序部署實例進行升級。自動升級功能，統一了代理程序的版本，使得我們可以不用被兼容性問題羈絆，是我們能夠進行快速迭代開發有力支撐。