吳宇星

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

【關(guān)鍵詞】 分布式事務(wù) 事務(wù)一致性 冪等性

一、引言

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

二、關(guān)鍵業(yè)務(wù)場景實(shí)現(xiàn)方案

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

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

2.1事務(wù)一致性場景

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

立即生效

快速生效

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

較長時(shí)間時(shí)延

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

時(shí)間要求低

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

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

2.2關(guān)鍵業(yè)務(wù)場景實(shí)現(xiàn)方案

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

2.2.1訂單提交

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

場景說明：

客戶訂單提交，作為一個(gè)整體提交

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

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

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

方案說明：

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

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

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

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

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

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

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

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

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

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

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

2.2.2訂單竣工、歸檔

事務(wù)拆解，將事務(wù)分解為具有冪等性子執(zhí)行服務(wù)，通過應(yīng)用進(jìn)行異常補(bǔ)償，保證最終一致。

場景說明：

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

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

方案說明：

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

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

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

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

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

場景說明

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

三、結(jié)束語

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

參 考 文 獻(xiàn)

[1]： Laurence.關(guān)于分布式事務(wù)、兩階段提交、一階段提交、Best Efforts 1PC模式和事務(wù)補(bǔ)償機(jī)制的研究[EB/OL].http：//blog.csdn.net/bluishglc/article/details/7612811