一個簡單的跨庫事務(wù)問題

最近在做一個項目，其中一個方案涉及到跨庫事務(wù)一致性問題，是一個簡單的場景。這個項目是對老的業(yè)務(wù)進(jìn)行性能提升，業(yè)務(wù)邏輯基本上保持不變。主要是在于新項目采用了分庫分表的設(shè)計，從而提升了性能。考慮到項目發(fā)布之后可能存在風(fēng)險，采取了新老系統(tǒng)的并行方案。這個系統(tǒng)的業(yè)務(wù)比較簡單：接收來自外部的數(shù)據(jù)，然后對數(shù)據(jù)進(jìn)行核對處理。為了保證新老系統(tǒng)能夠并行，在接收數(shù)據(jù)的時候必須實現(xiàn)雙寫方案，從而導(dǎo)致了跨庫事務(wù)的一致性問題。

下面一幅圖展示這一簡單的場景

這里面會存在一個小問題，就是可能存在寫入老庫成功，但是寫入新庫失敗的場景。

我們假設(shè)出現(xiàn)這種概率的情況是百萬分之一，在系統(tǒng)發(fā)布的情況下，這種概率可能更高。從目前我們的數(shù)據(jù)量來看，一天大概5000W，那么出現(xiàn)不一致的數(shù)據(jù)量在500條。考慮到這個是數(shù)據(jù)核算系統(tǒng)，不能有一條丟失的情況，否則兩邊比對結(jié)果可能會不一致。所以需要保證一致性。

這種問題，有以下幾種解決方案

1 考慮使用JTA等支持分布式事務(wù)的事務(wù)管理器

這種方案的優(yōu)勢就是直接有現(xiàn)成的解決方案，一般的j2ee服務(wù)器都提供了JTA的相關(guān)的實現(xiàn)。比較明顯的問題就是解決方案太重量級。一般JTA除了服務(wù)器要支持，對應(yīng)的數(shù)據(jù)庫服務(wù)廠商一般也要提供相應(yīng)的商業(yè)支持，主要是提供基于 XAResource  JDBC驅(qū)動，這一些商業(yè)上的支持，部分是需要付費的。而且使用XA 數(shù)據(jù)庫驅(qū)動，本身可能導(dǎo)致一些潛在的問題，尤其是基于不同的數(shù)據(jù)庫廠商的時候。而XA是基于兩階段提交協(xié)議，事務(wù)管理器為了完成一個事務(wù)，需要多次和數(shù)據(jù)庫通信，效率上比較低。

2 考慮使用數(shù)據(jù)庫自身的數(shù)據(jù)同步機(jī)制

如果新老庫的結(jié)構(gòu)基本一樣，這種方案還是比較靠譜的。也是比較簡單的方案。這種方案的局限性也再次。在本項目中，新庫不是一個物理庫，而是多個物理庫，而老庫是一個物理庫。如果要用數(shù)據(jù)庫自身的同步機(jī)制，涉及到多個庫和一個庫之間的數(shù)據(jù)復(fù)制。同時由于分表的方案也不一樣，導(dǎo)致兩邊做一個映射的配置，而這個需要在數(shù)據(jù)庫層面進(jìn)行，邏輯相當(dāng)?shù)膹?fù)雜，解決方案成本也比較高。相當(dāng)于把重要的分庫分表的邏輯在數(shù)據(jù)庫這一層重新實現(xiàn)了一份。

其實這個也帶來一個維護(hù)問題，一旦我們覺得新系統(tǒng)已經(jīng)足夠穩(wěn)定。應(yīng)用程序可以之間在寫入庫進(jìn)行切換，把老庫的邏輯切掉，從而實現(xiàn)了只寫新庫的需求。整個過程也不需要進(jìn)行再次發(fā)布。而數(shù)據(jù)庫的方案則需要停掉腳本，在多個地方進(jìn)行配置。

3 在old庫存放相同的兩張模型表，一張表用于old庫的持久化表，另外一張作為臨時表，主要是作為需要同步到到新庫的數(shù)據(jù)。如果已經(jīng)同步到新庫，就刪除。如果沒有同步到新庫就同步到新庫。這個過程采用定時機(jī)制，每分鐘定時提取臨時表一定數(shù)據(jù)量的數(shù)據(jù)，批量導(dǎo)入到新庫。通過努力重試，來保證一致性。而新庫則需要保證冪等性，保證數(shù)據(jù)只會同步過一次。一般情況下，則是通過數(shù)據(jù)特征標(biāo)識符來識別，這個一般都是數(shù)據(jù)的唯一性主鍵。

下面是簡單的實現(xiàn)：

這三種方案的主要思想就是 采取重試機(jī)制，這個只是分布式事務(wù)里面的一種模型，相應(yīng)的還有兩階段提交，異常恢復(fù)補(bǔ)償?shù)葯C(jī)制。