CRM基于分布式數據存儲事務處理方案

吳宇星

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

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

一、引言

CRM是企業的核心生產運營系統，在大型企業中數據量巨大，為提升系統的性能引入分布式數據存儲架構，采用分布式數據架構，將傳統的單節點數據存儲分布存放到多個數據節點，上層的應用如何保障事務一致性，對應用的建設提出很大的挑戰。

二、關鍵業務場景實現方案

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

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

2.1事務一致性場景

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

立即生效

快速生效

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

較長時間時延

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

時間要求低

允許時延，小時級別，如：數據同步給ODS

典型業務場景要求數據最終一致的時效如下：

2.2關鍵業務場景實現方案

事務實現方案：（表2）

2.2.1訂單提交

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

場景說明：

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

按現有數據存儲模式，訂單提交需保存的數據涉及訂單中心、客戶資料中心，存在跨數據節點事務

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

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

方案說明：

在訂單庫建立訂單過程表，將提交的數據都保存在訂單庫，并且以訂單ID分庫，規避為單庫內事務。如：

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

訂單，保存在訂單數據中心訂單表，根據訂單ID散列的切片；

客戶，保存在客戶數據中心客戶表，根據客戶ID散列的切片；

產品實例，保存在客戶數據中心產品實例表，根據客戶ID散列的切片

一次訂單提交，需要保持不同的數據庫節點。

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

訂單，保存在訂單數據中心訂單表，根據訂單ID散列的切片；

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

產品實例，保存在訂單數據中心過程產品實例表，根據訂單ID散列的切片

達到一次訂單提交，數據保存在同一分片中，將多數據庫事務，規避為單數據庫事務。

2.2.2訂單竣工、歸檔

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

場景說明：

按現有的數據分片模式，訂單數據、客戶資料數據存儲的分片不同

訂單竣工，作為一個整體業務，需要保證該場景的訂單狀態、流程狀態、客戶資料數據一起更改

方案說明：

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

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

有單獨的隊列，對出現異常的訂單進行重復執行，達到最后數據一致性。

2.2.3數據同步

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

場景說明

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

三、結束語

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

參 考 文 獻

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