吳宇星

【摘要】 借鑒優(yōu)秀互聯(lián)網(wǎng)經(jīng)驗，大型企業(yè)CRM系統(tǒng)引入分布式數(shù)據(jù)存儲架構，采用分布式數(shù)據(jù)架構，將傳統(tǒng)的單節(jié)點數(shù)據(jù)存儲分布存放到多個數(shù)據(jù)節(jié)點，上層的應用如何保障事務一致性，對應用的建設提出很大的挑戰(zhàn)。本文主要就CRM采用分布式數(shù)據(jù)存儲，列舉了分布式事務一致性的技術解決方案，并提出CRM的關鍵場景的分布式存儲情況下的事務處理方案。

【關鍵詞】 分布式事務 事務一致性 冪等性

一、引言

CRM是企業(yè)的核心生產(chǎn)運營系統(tǒng)，在大型企業(yè)中數(shù)據(jù)量巨大，為提升系統(tǒng)的性能引入分布式數(shù)據(jù)存儲架構，采用分布式數(shù)據(jù)架構，將傳統(tǒng)的單節(jié)點數(shù)據(jù)存儲分布存放到多個數(shù)據(jù)節(jié)點，上層的應用如何保障事務一致性，對應用的建設提出很大的挑戰(zhàn)。

二、關鍵業(yè)務場景實現(xiàn)方案

目前對于一個分布式系統(tǒng)的事務處理有三種方式：分布式事務兩階段提交、基于Best Efforts 1PC模式的事務以及事務補償機制。

綜合比較分布式事務一致性技術特性，集中系統(tǒng)采用事務補償機制進行分布式事務處理。

2.1事務一致性場景

從事務完成后，跨庫數(shù)據(jù)同步達到數(shù)據(jù)最終一致時間，需要考慮時效要求類型如下：

立即生效

快速生效

允許時延：秒級（正常要1秒內(nèi)，最長1分鐘？）

較長時間時延

允許時延：分時級別（分鐘、小時及以上）

時間要求低

允許時延，小時級別，如：數(shù)據(jù)同步給ODS

典型業(yè)務場景要求數(shù)據(jù)最終一致的時效如下：

2.2關鍵業(yè)務場景實現(xiàn)方案

事務實現(xiàn)方案：（表2）

2.2.1訂單提交

調整數(shù)據(jù)保存方案，將一次訂單提交涉及的訂單數(shù)據(jù)、客戶資料數(shù)據(jù)保存到同一數(shù)據(jù)節(jié)點，將跨數(shù)據(jù)節(jié)點事務調整為單數(shù)據(jù)節(jié)點事務，規(guī)避分布式事務。

場景說明：

客戶訂單提交，作為一個整體提交

按現(xiàn)有數(shù)據(jù)存儲模式，訂單提交需保存的數(shù)據(jù)涉及訂單中心、客戶資料中心，存在跨數(shù)據(jù)節(jié)點事務

按現(xiàn)有模式處理，訂單提交需要作為一個整體，涉及的數(shù)據(jù)，最少考慮也涉及訂單表、檔案表的數(shù)據(jù)更新或狀態(tài)變化

提交數(shù)據(jù)的下級信息較豐富，可能做為后續(xù)的查詢、展示關鍵信息。如：訂單下級的訂單項等數(shù)據(jù)，可能做為后續(xù)展示的部分數(shù)據(jù)。

方案說明：

在訂單庫建立訂單過程表，將提交的數(shù)據(jù)都保存在訂單庫，并且以訂單ID分庫，規(guī)避為單庫內(nèi)事務。如：

受理直接保存訂單及檔案庫，需要保持的數(shù)據(jù)及分片：

訂單，保存在訂單數(shù)據(jù)中心訂單表，根據(jù)訂單ID散列的切片；

客戶，保存在客戶數(shù)據(jù)中心客戶表，根據(jù)客戶ID散列的切片；

產(chǎn)品實例，保存在客戶數(shù)據(jù)中心產(chǎn)品實例表，根據(jù)客戶ID散列的切片

一次訂單提交，需要保持不同的數(shù)據(jù)庫節(jié)點。

在訂單庫中建立過程表，將提交的過程數(shù)據(jù)存放到訂單中心，并以訂單ID作為分片標識：

訂單，保存在訂單數(shù)據(jù)中心訂單表，根據(jù)訂單ID散列的切片；

客戶，保存在訂單數(shù)據(jù)中心過程客戶表，根據(jù)訂單ID散列的切片；

產(chǎn)品實例，保存在訂單數(shù)據(jù)中心過程產(chǎn)品實例表，根據(jù)訂單ID散列的切片

達到一次訂單提交，數(shù)據(jù)保存在同一分片中，將多數(shù)據(jù)庫事務，規(guī)避為單數(shù)據(jù)庫事務。

2.2.2訂單竣工、歸檔

事務拆解，將事務分解為具有冪等性子執(zhí)行服務，通過應用進行異常補償，保證最終一致。

場景說明：

按現(xiàn)有的數(shù)據(jù)分片模式，訂單數(shù)據(jù)、客戶資料數(shù)據(jù)存儲的分片不同

訂單竣工，作為一個整體業(yè)務，需要保證該場景的訂單狀態(tài)、流程狀態(tài)、客戶資料數(shù)據(jù)一起更改

方案說明：

將訂單竣工服務，分解為：訂單節(jié)點服務、客戶節(jié)點服務、產(chǎn)品檔案節(jié)點服務，進行按順序處理，最終達到整個訂單竣工的完成。

對訂單表增加一些事務ID、事務狀態(tài)等控制字段，進行處理過程標記。

有單獨的隊列，對出現(xiàn)異常的訂單進行重復執(zhí)行，達到最后數(shù)據(jù)一致性。

2.2.3數(shù)據(jù)同步

較長時間時延，允許12小時及以上，并且不具有事務性數(shù)據(jù)，可以采用時間戳方式進行數(shù)據(jù)同步。

場景說明

如：數(shù)據(jù)同步給ODS，可以采用時間戳方式。每次數(shù)據(jù)更新，同時更新時間戳，定期通過輪詢等方式將數(shù)據(jù)抽取。

三、結束語

分布式事務是一個大話題，本文就CRM的關鍵場景的分布式存儲情況下的事務處理方案進行初步設計，對解決分布式事務一致性提供了參考方案，后續(xù)需要不斷的進行細化。

參 考 文 獻

[1]： Laurence.關于分布式事務、兩階段提交、一階段提交、Best Efforts 1PC模式和事務補償機制的研究[EB/OL].http：//blog.csdn.net/bluishglc/article/details/7612811