基于變化數(shù)據(jù)捕獲機(jī)制的分布式緩存一致性策略①

江 勇, 苗宗利, 王 偉, 段世凱, 劉財(cái)政, 支孟軒

1(中國(guó)科學(xué)院大學(xué), 北京 100049)2(中國(guó)科學(xué)院軟件研究所 軟件工程技術(shù)研究開(kāi)發(fā)中心, 北京 100190)3(中國(guó)電子技術(shù)標(biāo)準(zhǔn)化研究院, 北京 100007)

基于變化數(shù)據(jù)捕獲機(jī)制的分布式緩存一致性策略①

江 勇1,2, 苗宗利3, 王 偉2, 段世凱1,2, 劉財(cái)政1,2, 支孟軒2

1(中國(guó)科學(xué)院大學(xué), 北京 100049)2(中國(guó)科學(xué)院軟件研究所 軟件工程技術(shù)研究開(kāi)發(fā)中心, 北京 100190)3(中國(guó)電子技術(shù)標(biāo)準(zhǔn)化研究院, 北京 100007)

分布式緩存被廣泛應(yīng)用于解決傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的性能瓶頸問(wèn)題, 但是當(dāng)不能感知分布式緩存的第三方應(yīng)用直接更新后臺(tái)數(shù)據(jù)庫(kù)時(shí), 緩存數(shù)據(jù)會(huì)獲得不一致的狀態(tài), 存在過(guò)時(shí)緩存問(wèn)題. 本文提出一種基于變化數(shù)據(jù)捕獲機(jī)制的分布式緩存一致性策略, 集成了基于觸發(fā)器和基于日志的兩種變化數(shù)據(jù)捕獲機(jī)制實(shí)時(shí)捕獲后臺(tái)數(shù)據(jù)庫(kù)更新, 實(shí)現(xiàn)了數(shù)據(jù)模型自動(dòng)轉(zhuǎn)換方法和SQL翻譯引擎, 實(shí)時(shí)更新緩存, 從而保障分布式緩存的一致性. 實(shí)驗(yàn)?zāi)MTPC-W測(cè)試基準(zhǔn)中的關(guān)鍵操作, 驗(yàn)證了基于日志的變化數(shù)據(jù)捕獲機(jī)制相比基于觸發(fā)器的變化數(shù)據(jù)捕獲機(jī)制有更好的數(shù)據(jù)庫(kù)性能和緩存一致性效果.

分布式緩存; 變化數(shù)據(jù)捕獲; 模型轉(zhuǎn)換; SQL翻譯

1 引言

為了應(yīng)對(duì)海量數(shù)據(jù)與大規(guī)模用戶請(qǐng)求帶來(lái)的挑戰(zhàn),解決傳統(tǒng)數(shù)據(jù)庫(kù)面臨的大規(guī)模數(shù)據(jù)訪問(wèn)瓶頸問(wèn)題, 分布式緩存被廣泛應(yīng)用, 為用戶提供高性能、高可用、可伸縮的數(shù)據(jù)緩存服務(wù). 但是, 當(dāng)不能感知緩存的第三方應(yīng)用程序直接更新后臺(tái)數(shù)據(jù)庫(kù)數(shù)據(jù)時(shí), 緩存會(huì)獲得不一致的狀態(tài), 存在過(guò)時(shí)緩存問(wèn)題[1], 如圖1所示.

保持緩存和后臺(tái)數(shù)據(jù)庫(kù)數(shù)據(jù)的數(shù)據(jù)一致性一直是開(kāi)發(fā)人員重點(diǎn)關(guān)注的問(wèn)題. 現(xiàn)有的典型分布式緩存方案, 如Memcached[2], Redis[3], Hazelcast[4]等, 主要通過(guò)基于過(guò)期的緩存一致性策略來(lái)保持緩存和后臺(tái)數(shù)據(jù)庫(kù)的數(shù)據(jù)一致性. 每個(gè)動(dòng)態(tài)的緩存條目都會(huì)創(chuàng)建一個(gè)默認(rèn)的存在時(shí)間清除器, 在預(yù)定義的時(shí)間間隔后會(huì)清除相應(yīng)的數(shù)據(jù)條目, 但是過(guò)期時(shí)間的設(shè)定是一條經(jīng)驗(yàn)規(guī)則, 需要開(kāi)發(fā)人員對(duì)數(shù)據(jù)的準(zhǔn)確性需求和對(duì)數(shù)據(jù)過(guò)時(shí)程度的容忍度有足夠的了解, 然后才能做出合適的決策. IBM的WebSphere eXtreme Scale[5]實(shí)現(xiàn)了基于輪詢的緩存一致性策略, 由緩存定期查詢數(shù)據(jù)庫(kù)以確定自上次加載以來(lái)數(shù)據(jù)是否發(fā)生了變更, 已在后臺(tái)數(shù)據(jù)庫(kù)中更新的條目失效或者使用新的數(shù)據(jù)更新緩存. 但是,這些定期查詢會(huì)給后臺(tái)數(shù)據(jù)庫(kù)帶來(lái)較大的負(fù)載壓力,輪詢機(jī)制也會(huì)消耗額外的CPU資源.

針對(duì)現(xiàn)有緩存方案的特點(diǎn)以及緩存一致性策略存在的問(wèn)題, 本文提出一種基于變化數(shù)據(jù)捕獲機(jī)制[6](Change Data Capture, CDC)的緩存一致性策略, 主要包括以下三個(gè)方面內(nèi)容:

(1) 變化數(shù)據(jù)捕獲機(jī)制. 設(shè)計(jì)實(shí)現(xiàn)關(guān)系型數(shù)據(jù)庫(kù)的數(shù)據(jù)變化捕獲機(jī)制, 實(shí)時(shí)監(jiān)聽(tīng)后臺(tái)數(shù)據(jù)庫(kù)的數(shù)據(jù)變化, 捕獲數(shù)據(jù)更新并傳送到分布式緩存, 支持基于觸發(fā)器和基于日志兩種方式.

(2) 數(shù)據(jù)模型自動(dòng)轉(zhuǎn)換方法. 實(shí)現(xiàn)關(guān)系型數(shù)據(jù)模型向key-value數(shù)據(jù)模型的自動(dòng)轉(zhuǎn)換, 將數(shù)據(jù)庫(kù)表中的行數(shù)據(jù)自動(dòng)轉(zhuǎn)換為分布式緩存的對(duì)象數(shù)據(jù).

(3) SQL翻譯引擎. 將變化數(shù)據(jù)捕獲機(jī)制捕獲到的SQL更新操作翻譯為緩存的key-value操作, 從而將更新同步到緩存.

2 相關(guān)工作

文獻(xiàn)[7,8]較為全面的介紹了變化數(shù)據(jù)捕獲技術(shù),主要有基于表記錄、復(fù)制、基于觸發(fā)器、基于日志等多種方法, 并比較了不同方法的條件、優(yōu)點(diǎn)、缺點(diǎn)和適用場(chǎng)合. 文獻(xiàn)[9]和文獻(xiàn)[10]分別介紹了基于觸發(fā)器和基于日志的變化數(shù)據(jù)捕獲技術(shù), 但是文獻(xiàn)[9]面向的是ETLM過(guò)程的數(shù)據(jù)倉(cāng)庫(kù), 文獻(xiàn)[10]面向?qū)崟r(shí)商業(yè)智能系統(tǒng).

在緩存一致性策略方面, 文獻(xiàn)[11]介紹了同步進(jìn)制實(shí)現(xiàn)分布式緩存的強(qiáng)一致性, 每次更新數(shù)據(jù)時(shí), 會(huì)同步更新所有緩存結(jié)點(diǎn), 然后返回. 這種機(jī)制適用于以讀請(qǐng)求為主的應(yīng)用場(chǎng)景, 而當(dāng)數(shù)據(jù)更新操作頻繁時(shí),強(qiáng)一致性的同步機(jī)制會(huì)顯著增加系統(tǒng)響應(yīng)時(shí)間. 文獻(xiàn)[12]實(shí)現(xiàn)了在緩存增強(qiáng)的SQL系統(tǒng)上的緩存強(qiáng)一致性,并提出了IQ框架, 同時(shí)滿足ACID屬性, 但是分布式緩存受到CAP理論的約束, 該方法并不能夠在分布式緩存中適用; 文獻(xiàn)[13]將基于觸發(fā)器的數(shù)據(jù)捕獲技術(shù)應(yīng)用到緩存, 保障緩存的一致性, 提出了一種面向ORM框架的緩存中間件, 是數(shù)據(jù)捕獲技術(shù)的一次成功應(yīng)用. 但是該文獻(xiàn)重點(diǎn)在于緩存的ORM訪問(wèn)方式, 對(duì)數(shù)據(jù)捕獲技術(shù)在緩存中的應(yīng)用討論得并不夠細(xì)致.

上述相關(guān)工作中, 有將CDC應(yīng)用到數(shù)據(jù)倉(cāng)庫(kù)和智能系統(tǒng)的, 但是仍缺少將CDC技術(shù)與分布式緩存的集成; 有的實(shí)現(xiàn)了緩存的強(qiáng)一致性, 但是存在場(chǎng)景限制,只適合讀請(qǐng)求為主的場(chǎng)景; 有的提出創(chuàng)新的緩存一致性框架, 但并不適合分布式緩存. 本文重點(diǎn)關(guān)注將變化數(shù)據(jù)捕獲技術(shù)應(yīng)用到分布式緩存中需解決的模型轉(zhuǎn)換, SQL翻譯等問(wèn)題, 并用兩種方式實(shí)現(xiàn)變化數(shù)據(jù)捕獲.

針對(duì)現(xiàn)有緩存方案的特點(diǎn)以及緩存一致性策略存在的問(wèn)題, 本文提出一種基于變化數(shù)據(jù)捕獲機(jī)制的緩存一致性策略, 通過(guò)在源系統(tǒng)中添加觸發(fā)器和獲取關(guān)系型數(shù)據(jù)庫(kù)日志兩種方式實(shí)現(xiàn)變化數(shù)據(jù)捕獲機(jī)制, 然后實(shí)現(xiàn)關(guān)系型數(shù)據(jù)模型向key-value數(shù)據(jù)模型的自動(dòng)轉(zhuǎn)換, 最后解析SQL, 更新緩存, 實(shí)現(xiàn)數(shù)據(jù)從關(guān)系型數(shù)據(jù)庫(kù)到分布式緩存的自動(dòng)同步.

3.1 變化數(shù)據(jù)捕獲機(jī)制

變化數(shù)據(jù)捕獲技術(shù)是基于對(duì)數(shù)據(jù)源改變部分的數(shù)據(jù)識(shí)別、數(shù)據(jù)獲取和數(shù)據(jù)傳送技術(shù)來(lái)實(shí)現(xiàn)的, 在數(shù)據(jù)源數(shù)據(jù)發(fā)生變化時(shí), 將實(shí)時(shí)捕獲變更的數(shù)據(jù)并同步更新到分布式緩存中, 從而保障分布式緩存的一致性.本文實(shí)現(xiàn)基于觸發(fā)器和基于日志兩種變化數(shù)據(jù)捕獲機(jī)制, 并對(duì)比其優(yōu)缺點(diǎn).

3.1.1 基于觸發(fā)器的變化數(shù)據(jù)捕獲

通過(guò)在關(guān)系型數(shù)據(jù)庫(kù)中設(shè)置觸發(fā)器并設(shè)計(jì)一張日志表與源數(shù)據(jù)表相關(guān)聯(lián), 當(dāng)源數(shù)據(jù)表數(shù)據(jù)發(fā)生變化時(shí),通過(guò)觸發(fā)器機(jī)制自動(dòng)記錄數(shù)據(jù)變化到日志表. 同時(shí),監(jiān)聽(tīng)線程實(shí)時(shí)監(jiān)聽(tīng)日志表信息, 獲取最新的數(shù)據(jù)變化,并通過(guò)數(shù)據(jù)傳送渠道將變更數(shù)據(jù)更新到緩存.

3 面向分布式緩存的變化數(shù)據(jù)捕獲機(jī)制

該方法的重點(diǎn)在于觸發(fā)器的設(shè)計(jì). 觸發(fā)器一共有三種類(lèi)型, 分別對(duì)應(yīng)數(shù)據(jù)庫(kù)的插入, 刪除, 更新操作,任何數(shù)據(jù)表的變更操作, 都會(huì)觸發(fā)觸發(fā)器, 從而在觸發(fā)器日志表產(chǎn)生記錄. 圖2是針對(duì)數(shù)據(jù)庫(kù)test中的orders表插入操作時(shí)創(chuàng)建的觸發(fā)器.

圖2 觸發(fā)器實(shí)例

3.1.2 基于日志的變化數(shù)據(jù)捕獲

關(guān)系型數(shù)據(jù)庫(kù)都管理著一個(gè)事務(wù)日志, 其中記錄了對(duì)數(shù)據(jù)庫(kù)內(nèi)容和元數(shù)據(jù)所做的更改. 基于日志的變化數(shù)據(jù)捕獲, 以關(guān)系型數(shù)據(jù)庫(kù)的事務(wù)日志為基礎(chǔ), 并對(duì)其進(jìn)行實(shí)時(shí)監(jiān)控, 一旦源數(shù)據(jù)庫(kù)發(fā)生數(shù)據(jù)變化, 就進(jìn)行實(shí)時(shí)捕獲, 對(duì)需要實(shí)時(shí)同步的數(shù)據(jù)進(jìn)行捕獲, 如圖3所示.

圖3 基于日志的變化數(shù)據(jù)捕獲

基于日志的變化數(shù)據(jù)捕獲需要訪問(wèn)關(guān)系型數(shù)據(jù)庫(kù)的事務(wù)日志, 并解析日志產(chǎn)生對(duì)應(yīng)的更新SQL操作.但是事務(wù)日志通常以二進(jìn)制的形式存在, 如果沒(méi)有官方文檔, 我們很難理解事務(wù)日志的內(nèi)容. 本文利用開(kāi)源工具open-replicator[14]實(shí)現(xiàn)基于日志的變化數(shù)據(jù)捕獲, open-replicator可以高效地解析Mysql的二進(jìn)制日志, 并實(shí)時(shí)產(chǎn)生監(jiān)聽(tīng)事件.

3.1.3 變化數(shù)據(jù)捕獲機(jī)制比較

表1從應(yīng)用條件、編程代價(jià)、性能, 移植性等方面比較了基于觸發(fā)器的變化數(shù)據(jù)捕獲機(jī)制和基于日志的變化數(shù)據(jù)捕獲機(jī)制.

表1 兩種不同變化數(shù)據(jù)捕獲機(jī)制對(duì)比

3.2 數(shù)據(jù)模型轉(zhuǎn)換方法

分布式緩存以key/value形式存儲(chǔ)數(shù)據(jù), 有利于緩存節(jié)點(diǎn)的橫向擴(kuò)展, 其中key和value均為數(shù)據(jù)對(duì)象,而在關(guān)系型數(shù)據(jù)庫(kù)中, 數(shù)據(jù)以表的形式進(jìn)行存儲(chǔ), 因此要實(shí)現(xiàn)數(shù)據(jù)庫(kù)向分布式緩存數(shù)據(jù)的自動(dòng)同步, 首先要實(shí)現(xiàn)關(guān)系型數(shù)據(jù)模型向key/value數(shù)據(jù)模型的自動(dòng)轉(zhuǎn)換, 圖4是數(shù)據(jù)模型轉(zhuǎn)換實(shí)例.

圖4 數(shù)據(jù)模型轉(zhuǎn)換實(shí)例

(1) 分布式緩存key的生成方法

生成分布式緩存的key, 首先要考慮兩個(gè)問(wèn)題: ①key的唯一性: 由于分布式緩存一般以Map的結(jié)構(gòu)存在, key的唯一性是Map存儲(chǔ)數(shù)據(jù)的必要條件; ②key的易用性: 分布式緩存中, 會(huì)計(jì)算key的哈希值從而確定數(shù)據(jù)的具體分布, 一個(gè)合理的key需保障哈希值的易計(jì)算, 同時(shí), 分布式緩存的數(shù)據(jù)讀取都以key為基礎(chǔ), 如果key的生成過(guò)于復(fù)雜, 在數(shù)據(jù)讀取時(shí)都會(huì)帶來(lái)不必要的性能開(kāi)銷(xiāo). 為了保證key的唯一性和易用性, 本文中的key都以字符串的形式存在, 對(duì)于數(shù)據(jù)庫(kù)中的單一主鍵情形, 直接選取數(shù)據(jù)庫(kù)表中的主鍵作為數(shù)據(jù)對(duì)象的key, 對(duì)于數(shù)據(jù)庫(kù)表中的多主鍵情況,將多列主鍵通過(guò)特殊間隔符組合拼接, 生成單一的key, 對(duì)數(shù)據(jù)庫(kù)表中沒(méi)有明確指定主鍵的情況, 采用主鍵自增方式, 為每個(gè)value對(duì)象維護(hù)一個(gè)整數(shù)自增變量作為對(duì)應(yīng)的key值.

(2) value的生成方法

生成分布式緩存的value, 重點(diǎn)需考慮的是value的通用性. 由于關(guān)系型數(shù)據(jù)庫(kù)中不同表的數(shù)據(jù)含有不同的結(jié)構(gòu), 如何將不同表數(shù)據(jù)統(tǒng)一生成Map中的value,是本文重點(diǎn)考慮的問(wèn)題. 本文將一張數(shù)據(jù)庫(kù)表映射轉(zhuǎn)換成一個(gè)Map, 數(shù)據(jù)庫(kù)表中的一條記錄對(duì)應(yīng)Map中的一組key/value鍵值對(duì). 通過(guò)數(shù)據(jù)庫(kù)表的元信息為每個(gè)表動(dòng)態(tài)生成一個(gè)數(shù)據(jù)對(duì)象類(lèi), 類(lèi)中屬性的類(lèi)型和關(guān)系型數(shù)據(jù)庫(kù)屬性的類(lèi)型一一對(duì)應(yīng), 所有數(shù)據(jù)對(duì)象類(lèi)含有同一父類(lèi), 這樣, 為數(shù)據(jù)庫(kù)表的每條記錄生成的每個(gè)對(duì)象實(shí)例, 都能存儲(chǔ)到同一結(jié)構(gòu)的Map中.

(3) Map的索引

關(guān)系型數(shù)據(jù)庫(kù)中的索引信息是提供高效數(shù)據(jù)訪問(wèn)的正確手段. 本文為了將關(guān)系型數(shù)據(jù)庫(kù)的索引信息同步到分布式緩存, 專(zhuān)門(mén)設(shè)計(jì)了索引管理器. 在數(shù)據(jù)同步到緩存之前, 首先會(huì)利用數(shù)據(jù)庫(kù)表的元信息創(chuàng)建對(duì)應(yīng)的分布式Map, 同時(shí)會(huì)提取數(shù)據(jù)庫(kù)列索引信息, 在Map中加入對(duì)應(yīng)的索引. 在基于索引的查詢過(guò)程中,加入索引的Map可以快速尋址到對(duì)應(yīng)的value對(duì)象.

3.3 SQL翻譯引擎

通過(guò)變化數(shù)據(jù)捕獲機(jī)制獲得的監(jiān)聽(tīng)事件往往以SQL的形式存在, 而分布式緩存的操作是基于key/value存儲(chǔ)的操作, SQL翻譯引擎負(fù)責(zé)將SQL翻譯成基于key/value存儲(chǔ)的可執(zhí)行序列.

對(duì)數(shù)據(jù)庫(kù)的更新主要來(lái)源于Insert, Delete, Update三類(lèi)語(yǔ)句, 本文主要翻譯這三類(lèi)語(yǔ)句. SQL作為一種結(jié)構(gòu)化查詢語(yǔ)言, 具有復(fù)雜的語(yǔ)法和完備的事務(wù)能力,使用key/value存儲(chǔ)結(jié)構(gòu)難以完整兼容所有SQL, 并且對(duì)于復(fù)雜的嵌套、統(tǒng)計(jì)等語(yǔ)法效率會(huì)很低下. 本文目前支持的SQL語(yǔ)法如下:

(1) INSERT INTO ＜表名＞[(＜屬性列1＞[, ＜屬性列2＞…])] VALUES (＜常量1＞[, ＜常量2＞…]);

(2) DELETE FROM ＜表名＞ [WHERE ＜條件＞];

(3) UPDATE ＜表名＞ SET ＜列名＞=＜表達(dá)式＞[, ＜列名＞=＜表達(dá)式＞…] [WHERE ＜條件＞];

其中, 表達(dá)式支持常量的任意算術(shù)運(yùn)算組成的表達(dá)式, 條件支持BETWEEN, IN, LIKE, EXISTS, IS NULL, 布爾條件表達(dá)式, 等式表達(dá)式等.

為了在key-value存儲(chǔ)系統(tǒng)上執(zhí)行SQL, 本文定義了3種謂詞: 基本謂詞(basic_predicate)、關(guān)系謂詞(relation_predicate)、執(zhí)行謂詞(execute_predicate), 如表2所示. 基本謂詞表示查詢條件, 如大于, like, exists等,每個(gè)基本謂詞是一系列基本k-v操作的封裝, 可直接在分布式緩存中執(zhí)行; 關(guān)系謂詞表示多個(gè)謂詞之間的與/或關(guān)系; 執(zhí)行謂詞分成插入謂詞(insert_predicate)、更新謂詞(update_predicate)、刪除謂詞(delete_predicate), 表示三種不同的基于鍵值對(duì)的數(shù)據(jù)更新操作.

表2 謂詞定義

在增刪改三類(lèi)數(shù)據(jù)更新請(qǐng)求中, 更新語(yǔ)句的解析與執(zhí)行相對(duì)來(lái)說(shuō)較為復(fù)雜, 算法1描述了更新語(yǔ)句的解析執(zhí)行過(guò)程. 首先, SQL解析后會(huì)生成一顆抽象語(yǔ)法樹(shù), 同時(shí)生成關(guān)系謂詞列表(relation_predicate_list),然后從關(guān)系謂詞列表中順序提取基本謂詞, 依據(jù)基本謂詞可從分布式緩存中獲取對(duì)應(yīng)的Value對(duì)象: map[table].getValue(basic_predicate), 再依據(jù)關(guān)系謂詞中的邏輯關(guān)系和基本謂詞獲得的Value對(duì)象, 獲得更新語(yǔ)句過(guò)程中的查詢結(jié)果, 更新謂詞會(huì)對(duì)該查詢結(jié)果對(duì)應(yīng)的數(shù)據(jù)進(jìn)行更新.

算法1 更新語(yǔ)句執(zhí)行算法

4 實(shí)驗(yàn)與分析

本文從兩個(gè)方面來(lái)對(duì)比基于觸發(fā)器的變化數(shù)據(jù)捕獲機(jī)制和基于日志的變化數(shù)據(jù)捕獲機(jī)制, 一是比較不同的變化數(shù)據(jù)捕獲機(jī)制對(duì)數(shù)據(jù)庫(kù)性能的影響程度, 二是比較不同的變化數(shù)據(jù)捕獲機(jī)制在保證分布式緩存一致性時(shí), 不一致窗口的大小.

4.1 實(shí)驗(yàn)設(shè)計(jì)

本文使用TPC-W[15]基準(zhǔn)中的關(guān)鍵業(yè)務(wù)對(duì)比驗(yàn)證基于觸發(fā)器的變化數(shù)據(jù)捕獲和基于日志的變化數(shù)據(jù)捕獲. TPC-W是一款以真實(shí)電子商務(wù)應(yīng)用為用例的測(cè)試基準(zhǔn), 可以模擬用戶訪問(wèn)電子商務(wù)圖書(shū)網(wǎng)站時(shí)的查詢、購(gòu)買(mǎi)等行為, 包括根據(jù)查詢書(shū)籍, 用戶注冊(cè), 訂單管理等. 本文選取TPC-W基準(zhǔn)中與訂單管理相關(guān)的關(guān)鍵SQL語(yǔ)句來(lái)進(jìn)行測(cè)試, 觀察變化數(shù)據(jù)捕獲的性能特點(diǎn), 選取的SQL語(yǔ)句為: INSERT INTO order_line (ol_id, ol_o_id, ol_i_id, ol_qty, ol_discount, ol_comments) VALUES (?, ?, ?, ?, ?, ?), , 記為SQLX, SQLX的參數(shù)使用隨機(jī)值.

實(shí)驗(yàn)的負(fù)載發(fā)生端使用YCSB[16]性能測(cè)試工具,數(shù)據(jù)庫(kù)采用MySQL, 對(duì)比測(cè)試不同變化數(shù)據(jù)捕獲技術(shù)應(yīng)用到分布式緩存時(shí), 給數(shù)據(jù)庫(kù)帶來(lái)的性能影響和緩存不一致窗口的大小. 實(shí)驗(yàn)環(huán)境的軟硬件配置如表3所示.

表3 實(shí)驗(yàn)環(huán)境軟硬件配置

4.2 實(shí)驗(yàn)結(jié)果與分析

(1) 比較兩種變化數(shù)據(jù)捕獲機(jī)制下的數(shù)據(jù)庫(kù)性能

本次實(shí)驗(yàn)中, 每個(gè)線程執(zhí)行SQLX 10000次, 隨機(jī)向數(shù)據(jù)庫(kù)插入10000條記錄, 通過(guò)改變線程數(shù)量, 從而改變對(duì)數(shù)據(jù)庫(kù)的壓力, 分別測(cè)試線程數(shù)為1,2,5,10時(shí), 每個(gè)線程向數(shù)據(jù)庫(kù)插入10000條記錄所需要的時(shí)間, 即數(shù)據(jù)庫(kù)的響應(yīng)時(shí)間. 實(shí)驗(yàn)結(jié)果如圖5所示, 其中,橫軸代表線程的數(shù)量, 縱軸代表每個(gè)線程插入10000條記錄的平均時(shí)間, 即數(shù)據(jù)庫(kù)的響應(yīng)時(shí)間. 實(shí)驗(yàn)結(jié)果表明, 隨著線程數(shù)的增大, 數(shù)據(jù)庫(kù)的響應(yīng)時(shí)間逐漸增大. 但是, 由于觸發(fā)器對(duì)數(shù)據(jù)庫(kù)性能的影響, 在基于觸發(fā)器的變化數(shù)據(jù)捕獲下, 數(shù)據(jù)庫(kù)的響應(yīng)時(shí)間增大更明顯, 基于日志的變化數(shù)據(jù)捕獲下的數(shù)據(jù)庫(kù)性能是基于觸發(fā)器的變化數(shù)據(jù)捕獲下數(shù)據(jù)庫(kù)性能的11到21倍.

圖5 不同變化數(shù)據(jù)捕獲機(jī)制下數(shù)據(jù)庫(kù)性能對(duì)比

(2) 比較兩種變化數(shù)據(jù)捕獲機(jī)制下的緩存一致性

根據(jù)CAP理論, 在一個(gè)分布式系統(tǒng)中, 一致性、可用性和分區(qū)容忍性三者不可得兼. 本文中分布式緩存的一致性不是強(qiáng)一致性, 數(shù)據(jù)庫(kù)數(shù)據(jù)更新和緩存數(shù)據(jù)同步更新之間存在一定的不一致窗口, 不一致窗口的大小是衡量系統(tǒng)性能的一個(gè)重要指標(biāo).

本次實(shí)驗(yàn)中, 單線程執(zhí)行SQLX 10000次, 隨機(jī)向數(shù)據(jù)庫(kù)插入10000條記錄, 通過(guò)改變兩次SQL執(zhí)行之間的間隔時(shí)間來(lái)改變數(shù)據(jù)的更新頻率, SQL間隔執(zhí)行間隔時(shí)間越長(zhǎng), 數(shù)據(jù)更新頻率越低. 分別測(cè)試SQL執(zhí)行間隔時(shí)間為0,1,2,5,10毫秒時(shí), 緩存捕獲到最新數(shù)據(jù)和數(shù)據(jù)庫(kù)插入數(shù)據(jù)間的不一致時(shí)間窗口. 實(shí)驗(yàn)結(jié)果如圖6所示, 其中, 橫軸代表兩次SQL執(zhí)行的時(shí)間間隔,縱軸代表緩存與數(shù)據(jù)庫(kù)之間的數(shù)據(jù)不一致時(shí)間窗口.從圖6可以看到如下現(xiàn)象: (1)數(shù)據(jù)更新頻率越低, 緩存的一致性效果越好. 由圖可知, 隨著間隔時(shí)間的增大, 也即數(shù)據(jù)更新頻率減小, 對(duì)變化數(shù)據(jù)捕獲模塊的壓力相對(duì)也減小, 從而在更短的響應(yīng)時(shí)間內(nèi)將數(shù)據(jù)同步到緩存. (2)基于日志的變化數(shù)據(jù)捕獲相比基于觸發(fā)器的變化數(shù)據(jù)捕獲有更好的一致性效果. 由圖可知,在不同的時(shí)間間隔下, 基于日志的變化數(shù)據(jù)捕獲的不一致窗口都要明顯小于基于觸發(fā)器的變化數(shù)據(jù)捕獲.

圖6 不同變化數(shù)據(jù)捕獲機(jī)制下緩存一致性對(duì)比

5 總結(jié)與展望

本文首先分析了第三方應(yīng)用不能感知分布式緩存時(shí)存在的過(guò)時(shí)緩存問(wèn)題, 然后提出了一種基于數(shù)據(jù)捕獲機(jī)制的緩存一致性策略, 主要包括面向分布式緩存的兩種變化數(shù)據(jù)捕獲機(jī)制, 數(shù)據(jù)模型的自動(dòng)轉(zhuǎn)換方法和SQL翻譯引擎. 通過(guò)實(shí)驗(yàn)對(duì)比驗(yàn)證了基于日志的變化數(shù)據(jù)捕獲技術(shù)在數(shù)據(jù)庫(kù)性能和緩存一致性效果方面的性能優(yōu)勢(shì), 但是基于觸發(fā)器的變化數(shù)據(jù)捕獲技術(shù)有其通用性, 易用性, 編程代價(jià)低等優(yōu)勢(shì).

本文中基于變化數(shù)據(jù)捕獲機(jī)制的緩存一致性策略的設(shè)計(jì)與實(shí)現(xiàn)并不完善, 需要在未來(lái)工作中針對(duì)以下方面進(jìn)行研究與改進(jìn): (1)由于關(guān)系型數(shù)據(jù)模型的復(fù)雜性, 關(guān)系型數(shù)據(jù)的外鍵約束等尚不支持; (2)運(yùn)行時(shí)動(dòng)態(tài)對(duì)數(shù)據(jù)表結(jié)構(gòu)的修改并不能實(shí)時(shí)映射到分布式緩存數(shù)據(jù)結(jié)構(gòu).

1 Dreibholz T, Rathgeb E P. On the performance of reliable server pooling systems. The IEEE Conference on Local Computer Networks, 2005. 30th Anniversary. IEEE. 2005. 200–208.

2 Memcached. http://memcached.org/. [2016-03-29].

3 Redis. http://redis.io/. [2016-03-29].

4 Hazelcast. http://hazelcast.org/. [2016-03-29].

5 WebSphere Extreme Scale. http://www-03.ibm.com/software/ products/en/websphere-extreme-scale/. [2016-03-29].

6 Eccles M. Pragmatic Development of Service Based Real-Time Change Data Capture[Thesis]. Aston University, 2013.

7 徐富亮,周祖德.變化數(shù)據(jù)捕獲技術(shù)研究.武漢理工大學(xué)學(xué)報(bào):信息與管理工程版,2009,31(5):740–743.

8 林子雨,楊冬青,宋國(guó)杰,等.實(shí)時(shí)主動(dòng)數(shù)據(jù)倉(cāng)庫(kù)中的變化數(shù)據(jù)捕獲研究綜述.計(jì)算機(jī)研究與發(fā)展,2007,44(z3):447–451.

9 Rocha RLA, Cardoso LF, de Souza JM. Performance tests in data warehousing ETLM process for detection of changes in data origin. Data Warehousing and Knowledge Discovery. Springer Berlin Heidelberg, 2003: 129–139.

10 Shi JG, Bao YB, Leng FL, et al. Study on log-based change data capture and handling mechanism in real-time data warehouse. 2008 International Conference on Computer Science and Software Engineering. IEEE. 2008, 4. 478–481. 11 Amza C, Soundararajan G, Cecchet E. Transparent caching with strong consistency in dynamic content web sites. International Conference on Supercomputing. 2005. 264–273.

12 Ghandeharizadeh S, Yap J, Nguyen H. Strong consistency in cache augmented SQL systems. Proc. of the 15th International Middleware Conference. ACM. 2014. 181–192.

13 Gupta P, Zeldovich N, Madden S. A trigger-based middleware cache for ORMs. Acm/ifip/usenix International Conference on MIDDLEWARE. Springer-Verlag. 2011. 329-349.

14 Open-replicator. https://github.com/whitesock/open- replicator. [2016-03-29].

15 TPC-W. http://www.tpc.org/tpcw/. [2016-03-29].

16 YCSB. https://github.com/brianfrankcooper/YCSB. [2016-03-29].

Distributed Cache Coherency Strategy Based on Change Data Capture Mechanism

JIANG Yong1,2, MIAO Zong-Li3, WANG Wei2, DUAN Shi-Kai1,2, LIU Cai-Zheng1,2, ZHI Meng-Xuan212
(University of Chinese Academy of Sciences, Beijing 100049, China)3(Technology Center of Software Engineering, Institute of Software, Chinese Academy of Sciences, Beijing 100190, China) (China Electronics Standardization Institute, Beijing 100007, China)

Distributed cache is widely used to solve the performance bottleneck problem in traditional relational database, but when third-party applications that are not cache-aware update the back-end database, the distributed cache will end up in an inconsistent state, which has the problem of stale cache data. This paper proposes a distributed cache consistency strategy based on change data capture mechanism. The work integrates trigger-based and log-based change data capture mechanism that can get the real-time data from backend database, and implements data model transformation and SQL translation engine, which can update cache in real-time to guarantee distributed cache coherence. The experiment simulates the key operation in TPC-W benchmark, which verifies that the change data capture based on log has the better database performance and cache consistency effects compared with the change data capture based on trigger.

distributed cache; change data capture; model transforming; SQL translation

2016-03-21;收到修改稿時(shí)間:2016-04-08

10.15888/j.cnki.csa.005450