汪添生, 尉雙梅, 崔 蔚, 劉 迪,4, 何金陵, 孫 琦

1(國(guó)網(wǎng)信息通信產(chǎn)業(yè)集團(tuán)有限公司, 北京 100761)

2(廈門(mén)億力吉奧信息科技有限公司, 廈門(mén) 361000)

3(安徽繼遠(yuǎn)軟件有限公司, 合肥 230088)

4(北京中電普華信息技術(shù)有限公司, 北京 100085)

5(國(guó)網(wǎng)江蘇省電力公司通信分公司, 南京 210008)

支持MongoDB的事務(wù)管理方案研究①

汪添生1,2, 尉雙梅3, 崔 蔚1, 劉 迪1,4, 何金陵5, 孫 琦5

1(國(guó)網(wǎng)信息通信產(chǎn)業(yè)集團(tuán)有限公司, 北京 100761)

2(廈門(mén)億力吉奧信息科技有限公司, 廈門(mén) 361000)

3(安徽繼遠(yuǎn)軟件有限公司, 合肥 230088)

4(北京中電普華信息技術(shù)有限公司, 北京 100085)

5(國(guó)網(wǎng)江蘇省電力公司通信分公司, 南京 210008)

MongoDB作為一個(gè)基于分布式文件存儲(chǔ)的數(shù)據(jù)庫(kù), 強(qiáng)大的單表查詢(xún)語(yǔ)言, 以及可擴(kuò)展的高性能數(shù)據(jù)存儲(chǔ)受很用戶(hù)喜愛(ài), 但其沒(méi)有對(duì)事務(wù)的完全支持, 使得用戶(hù)對(duì)MongoDB的使用處于被動(dòng)狀態(tài). 為改善MongoDB對(duì)事務(wù)管理方面的兼容性, 提出一種支持MongoDB事務(wù)管理, 完善MongoDB功能的方案. 利用MQ與守護(hù)進(jìn)程間的消息通信,使守護(hù)進(jìn)程對(duì)事務(wù)提交或者回滾后的臟數(shù)據(jù)進(jìn)行清理, 保證了MongoDB在事務(wù)管理方面的可用性與安全性.

分布式數(shù)據(jù)庫(kù); mongoDB; 事務(wù)管理; 守護(hù)進(jìn)程; MQ; 消息通信

隨著網(wǎng)絡(luò)快速普及發(fā)展, 信息資源的豐富和獲取方式的高效便捷, 使得人們對(duì)web信息資源的需求越來(lái)越大, 在需求量與日俱增的情況下[1,2], 一個(gè)安全穩(wěn)定高效的存儲(chǔ)總會(huì)受到人們的關(guān)注. 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù),在面對(duì)高并發(fā)讀寫(xiě)請(qǐng)求, 海量數(shù)據(jù)的高效存儲(chǔ)以及高擴(kuò)展性和可用性等需求時(shí), 關(guān)系型數(shù)據(jù)庫(kù)的瓶頸就會(huì)逐漸暴露出來(lái)[1], 此時(shí), 停機(jī)維護(hù)或者數(shù)據(jù)庫(kù)遷移可能普遍成為解決該問(wèn)題的通用方法. 非關(guān)系型數(shù)據(jù)庫(kù)提出的另一種概念, 靈活多變的數(shù)據(jù)字段, 結(jié)構(gòu)沒(méi)有固定,以鍵值或者面向文檔的形式存儲(chǔ)數(shù)據(jù)[2], 脫離關(guān)系型數(shù)據(jù)庫(kù)的一成不變的格式, 無(wú)需經(jīng)過(guò)SQL層的解析, 大大減少了部分時(shí)間和空間的開(kāi)銷(xiāo), 支持橫向擴(kuò)展, 從而支持海量數(shù)據(jù)的存儲(chǔ)等.

然而關(guān)系型數(shù)據(jù)庫(kù)支持對(duì)多表復(fù)雜查詢(xún)的功能以及對(duì)事務(wù)操作的高安全性的特點(diǎn)在非關(guān)系型數(shù)據(jù)庫(kù)領(lǐng)域卻沒(méi)有完全得到體現(xiàn). MongoDB作為一個(gè)基于分布式文件存儲(chǔ)的數(shù)據(jù)庫(kù)代表, 擁有支持使用高效的二進(jìn)制數(shù)據(jù)存儲(chǔ)(如視頻等), 支持完全索引, 面向集合, 模式自由由, 支持復(fù)制和故障恢復(fù)等等優(yōu)點(diǎn), 但也明確說(shuō)明了MongoDB并不適用高度事務(wù)性的系統(tǒng), 由于這個(gè)原因, 使得用戶(hù)在使用MongoDB這樣的非關(guān)系型數(shù)據(jù)庫(kù)的時(shí)候不得不慎重考慮. 本文旨在通過(guò)數(shù)據(jù)訪問(wèn)層對(duì)需要進(jìn)行事務(wù)控制數(shù)據(jù)更新至MongoDB數(shù)據(jù)庫(kù)的方式進(jìn)行針對(duì)性的處理, 同時(shí)開(kāi)啟守護(hù)進(jìn)程, 不管MongoDB數(shù)據(jù)庫(kù)是否發(fā)生異常, 事務(wù)最后的結(jié)果或者是成功提交, 又或者是數(shù)據(jù)回滾, 采用MQ與守護(hù)進(jìn)程間通信, 將事務(wù)處理的結(jié)果及相關(guān)信息傳遞給守護(hù)進(jìn)程, 讓守護(hù)進(jìn)程對(duì)事務(wù)操作后的臟數(shù)據(jù)進(jìn)行處理[3,4], 以達(dá)到保證事務(wù)在整個(gè)過(guò)程中保持原有的ACID特性[5].

1 MongoDB數(shù)據(jù)訪問(wèn)層

MongoDB是開(kāi)源、面向文檔、模式自由、可擴(kuò)展的分布式數(shù)據(jù)庫(kù)[2]. 利用MongoDB作為后臺(tái)數(shù)據(jù)存儲(chǔ)的服務(wù), 本節(jié)旨在解決MongoDB在事務(wù)控制方面的不足, 需要結(jié)合MongoDB對(duì)數(shù)據(jù)存儲(chǔ)的形式, 設(shè)計(jì)一個(gè)針對(duì)進(jìn)行事務(wù)操作時(shí)增刪改的接口.

1.1 具有事務(wù)標(biāo)識(shí)的PO類(lèi)

PO(persistant object)持久對(duì)象, 是一個(gè)與數(shù)據(jù)庫(kù)中的表相映射的java對(duì)象. 這里對(duì)MongoDB存儲(chǔ)的業(yè)務(wù)數(shù)據(jù)需要進(jìn)行一個(gè)和PO概念一樣的映射對(duì)象, 盡管MongoDB是模式自由的數(shù)據(jù)庫(kù), 為了更好完成事務(wù)控制的功能, 對(duì)于存儲(chǔ)的數(shù)據(jù)應(yīng)該規(guī)定滿足業(yè)務(wù)所需具體的字段是完全合理的, 但有個(gè)不同的是, PO中除了必要的業(yè)務(wù)字段, 還需要新增一個(gè)標(biāo)識(shí)字段, 如: transactionId,用來(lái)作為事務(wù)控制后, 清理數(shù)據(jù)的唯一標(biāo)識(shí), 此字段完全不會(huì)影響到對(duì)MongoDB數(shù)據(jù)的讀寫(xiě), 也不會(huì)影響到對(duì)前端界面的展示, 因?yàn)樗皇且粋€(gè)標(biāo)識(shí)字段, 展現(xiàn)時(shí)無(wú)需獲取該字段的值.

1.2 更新方法的處理

在進(jìn)行MongoDB事務(wù)增刪改的時(shí)候, 需要說(shuō)明的是, 對(duì)于修改和刪除的特殊處理. 這里修改的操作實(shí)際上在MongoDB數(shù)據(jù)訪問(wèn)層中處理方式是新增一條新數(shù)據(jù), 但是此數(shù)據(jù)是在原來(lái)舊數(shù)據(jù)與新改數(shù)據(jù)之間的合并而成的, 它將作為一條新的數(shù)據(jù)重新保存進(jìn)MongoDB數(shù)據(jù)庫(kù)中, 同時(shí)該條數(shù)據(jù)的transactionId字段將被賦予一個(gè)唯一值; 而刪除的操作則是給準(zhǔn)備刪除的數(shù)據(jù)添加transactionId字段的值, 此值和修改數(shù)據(jù)時(shí)分配的值是一樣, 因此對(duì)于刪除操作并非真正刪除, 而是修改它,給它分配一個(gè)transactionId值; 而完全新增的數(shù)據(jù)則是和修改一樣的操作, 就是在新增數(shù)據(jù)的transactionId字段賦予一個(gè)唯一值. 如果事務(wù)的操作序列中包含了新增和修改, 則新增和修改的數(shù)據(jù)的transactionId值是一樣的.

在事務(wù)開(kāi)始的前期, 開(kāi)發(fā)人員需要獲取即將操作的記錄的主鍵, 這里的操作指的是針對(duì)修改操作, 然后將主鍵保存進(jìn)BasicDBList這個(gè)集合中, 對(duì)于刪除操作,上述說(shuō)過(guò)要?jiǎng)h除的數(shù)據(jù)的主鍵值會(huì)保存到一個(gè)集合中,此集合即是BasicDBList. 此目的是在事務(wù)成功執(zhí)行提交時(shí), 可以作為清理無(wú)用數(shù)據(jù)時(shí)的主鍵, 如果事務(wù)由于MongoDB數(shù)據(jù)庫(kù)的異常發(fā)生回滾, 則上述中的transactionId則將作為清理數(shù)據(jù)的唯一值, 相當(dāng)于主鍵.更新方法與MongoDB數(shù)據(jù)訪問(wèn)層的交互過(guò)程如圖1所示.

圖1 增刪改方法與MongoDB數(shù)據(jù)訪問(wèn)層交互圖

1.3 事務(wù)控制

事務(wù)是由一組操作組成的可靠的獨(dú)立的工作單元[5].一個(gè)事務(wù)具有ACID4個(gè)基本的屬性, 原子性(Atomicity):是指事務(wù)是一個(gè)完整的工作單位, 事務(wù)中的操作要么都執(zhí)行, 要么都不執(zhí)行; 一致性(Consistency): 事務(wù)使數(shù)據(jù)庫(kù)從一個(gè)一致性狀態(tài)變換到另外一個(gè)一致性狀態(tài);隔離性(Isolation): 隔離性是指一個(gè)事務(wù)的執(zhí)行不能被其他并發(fā)事務(wù)所干擾, 即一個(gè)事務(wù)內(nèi)部的操作及使用的數(shù)據(jù)對(duì)并發(fā)的其他事務(wù)是隔離的, 并發(fā)執(zhí)行的各個(gè)事務(wù)之間不能互相干擾; 持久性(Durability): 指一個(gè)事務(wù)一旦被提交, 它對(duì)數(shù)據(jù)庫(kù)中數(shù)據(jù)的改變就是永久性的, 后面的其他操作或者數(shù)據(jù)庫(kù)故障不會(huì)對(duì)其有任何影響.

為保證盡量做到事務(wù)在關(guān)系型數(shù)據(jù)庫(kù)中原來(lái)的特性, 本方案中, 定義一個(gè)事務(wù)管理器, 該管理器的主要作用是對(duì)事務(wù)進(jìn)行提交和回滾時(shí)的操作, 在提交和回滾時(shí)將會(huì)利用消息通信機(jī)制與守護(hù)進(jìn)程進(jìn)行通信. 在事務(wù)開(kāi)始前期, 由要更新的數(shù)據(jù)主鍵值和transactionId都可以確定下來(lái), 因此會(huì)在前期將這些信息預(yù)告發(fā)送至MQ隊(duì)列中, 而事務(wù)提交時(shí)將會(huì)發(fā)送一個(gè)成功提交的標(biāo)識(shí)給守護(hù)進(jìn)程, 告訴守護(hù)進(jìn)程可以進(jìn)行事務(wù)成功后的臟數(shù)據(jù)清理工作; 在事務(wù)回滾時(shí)將會(huì)發(fā)送給一個(gè)事務(wù)失敗的標(biāo)識(shí)給守護(hù)進(jìn)程, 告訴守護(hù)進(jìn)程可以進(jìn)行事務(wù)失敗后的臟數(shù)據(jù)清理工作. 而在執(zhí)行提交或者回滾操作時(shí), 為保證一個(gè)事務(wù)的工作不被并發(fā)事務(wù)的干擾,對(duì)提交和回滾的操作需要加上同步鎖, 保證本事務(wù)在隊(duì)列中的消息被清除后, 釋放同步鎖, 讓其他的事務(wù)獲得該鎖以完成自己的工作.

2 MQ消息通信

Message Queue, 一種應(yīng)用程序與應(yīng)用程序間進(jìn)行消息交換的技術(shù)[6,7]. MQ使得消息在應(yīng)用程序間的傳送變得簡(jiǎn)單、安全、可靠, 它擺脫了程序間直接調(diào)用彼此來(lái)獲取信息的方式, 通過(guò)隊(duì)列管理器來(lái)管理隊(duì)列Queue, 應(yīng)用程序無(wú)需建立專(zhuān)用的鏈接來(lái)與之連接而獲得隊(duì)列中消息, 同時(shí)發(fā)送者程序只關(guān)心將消息傳送至MQ中, 處理消息的程序并不依賴(lài)于消息的發(fā)送者, 也沒(méi)有時(shí)間的限制, 這就將消息的發(fā)送者與處理者之間的耦合度降到了最低, 其實(shí)這也是MQ的異步處理機(jī)制, 所以MQ所扮演的角色是一個(gè)消息管理者, 除了消息雙方必須實(shí)現(xiàn)處理過(guò)程的接口外, 只負(fù)責(zé)接收管理消息并提供多種需要的服務(wù)機(jī)制, 對(duì)于什么時(shí)候需要消息、什么方式領(lǐng)取消息的另一方則是它自己的事.

在本方案中, 事務(wù)管理器可以獲取在事務(wù)執(zhí)行成功或者失敗后的需要發(fā)送的標(biāo)識(shí). MQ在規(guī)定的隊(duì)列接收到事務(wù)前期發(fā)送的主鍵值和transactionId時(shí), 將不再接收下一個(gè)消息, 需要等待此消息被處理后, 再接收下個(gè)事務(wù)發(fā)送的信息. 事務(wù)成功提交時(shí), MQ將會(huì)得到一個(gè)事務(wù)執(zhí)行成功標(biāo)識(shí); 事務(wù)執(zhí)行失敗時(shí), MQ將會(huì)得到一個(gè)事務(wù)執(zhí)行失敗的標(biāo)識(shí). 在MQ發(fā)送者端, 分發(fā)模式DeliveryMode設(shè)置成PERSISTENT, 以防發(fā)生故障, 導(dǎo)致存儲(chǔ)在內(nèi)存中的消息被清除, 所以設(shè)置成PERSISTENT模式可以將消息存儲(chǔ)在本地文件中, 當(dāng)隊(duì)列中的消息被消費(fèi)后, 此數(shù)據(jù)才有被清除的資格, 也保證了發(fā)送的消息在沒(méi)有被守護(hù)進(jìn)程讀取之前, 能夠一直存在直到任務(wù)完成.

另外, MQ在創(chuàng)建連接時(shí)使用同步方式, 消息在被守護(hù)進(jìn)程接收后需要發(fā)回一個(gè)確認(rèn)收到的消息, 而消息發(fā)送端在收到接收者發(fā)送的確認(rèn)標(biāo)識(shí)后, 知道事務(wù)操作結(jié)束, 可以釋放對(duì)提交和回滾操作的同步鎖給下一個(gè)等待的事務(wù), 這樣才算完成整個(gè)事務(wù)的過(guò)程,MQ的工作也就到此結(jié)束. MQ完成的交互如圖2所示.

圖2 事務(wù)標(biāo)識(shí)與MQ的交互圖

3 守護(hù)進(jìn)程

守護(hù)進(jìn)程(Daemon)是一種獨(dú)立于控制終端并周期性地執(zhí)行某種任務(wù)或者等待某些事件的發(fā)生而運(yùn)行于后臺(tái)的一種特殊進(jìn)程[8,9]. 而事務(wù)在執(zhí)行成功或者失敗后, 留在MongDB數(shù)據(jù)庫(kù)中的臟數(shù)據(jù), 借助守護(hù)進(jìn)程進(jìn)行清理[10]則是一個(gè)不錯(cuò)的選擇.

守護(hù)進(jìn)程在開(kāi)啟后, 定期的進(jìn)行請(qǐng)求MQ隊(duì)列中的消息[11,12], 如果接收到事務(wù)前期發(fā)送的相關(guān)數(shù)據(jù), 接著在規(guī)定的時(shí)間段定期請(qǐng)求的事務(wù)執(zhí)行成功或者失敗的標(biāo)識(shí), 如果在規(guī)定的時(shí)間內(nèi)沒(méi)有接收到標(biāo)識(shí), 則默認(rèn)為事務(wù)執(zhí)行失敗, 將按失敗事務(wù)的處理方式處理數(shù)據(jù); 如果在規(guī)定的時(shí)間內(nèi)接收到標(biāo)識(shí), 則按標(biāo)識(shí)的定義來(lái)處理數(shù)據(jù). 守護(hù)進(jìn)程在不管事務(wù)成功還失敗情況下, 只要進(jìn)入到處理數(shù)據(jù), 守護(hù)進(jìn)程需心跳性監(jiān)測(cè)MongoDB數(shù)據(jù)庫(kù)的連接性, 在一次連接數(shù)據(jù)庫(kù)成功之后, 完成數(shù)據(jù)的清理. 事務(wù)成功提交時(shí), 獲取的主鍵值, 會(huì)作為清理的舊數(shù)據(jù)的標(biāo)識(shí); 事務(wù)執(zhí)行失敗回滾時(shí), 獲取的transactionId, 會(huì)作為清理新增的數(shù)據(jù)的標(biāo)識(shí). 這樣, 不管在事務(wù)端執(zhí)行的對(duì)MongoDB寫(xiě)操作有幾個(gè), 最后都將轉(zhuǎn)變?yōu)橐粋€(gè)對(duì)MongoDB刪除的操作, 而MongoDB單個(gè)執(zhí)行命令是保證原子性的, 執(zhí)行刪除操作后,MongoDB數(shù)據(jù)庫(kù)中的數(shù)據(jù)則保留了事務(wù)操作后的一致性狀態(tài). 后期, 守護(hù)進(jìn)程斷開(kāi)與MongoDB的連接, 清空隊(duì)列中的數(shù)據(jù)并給MQ隊(duì)列發(fā)送對(duì)消息接收的確認(rèn)標(biāo)識(shí), 接著再進(jìn)行周期性的請(qǐng)求MQ隊(duì)列中新的消息, 開(kāi)始下一個(gè)的事務(wù)的控制. 圖3是守護(hù)進(jìn)程在事務(wù)控制中的工作圖.

圖3 守護(hù)進(jìn)程工作圖

4 事務(wù)管理過(guò)程

現(xiàn)在結(jié)合一個(gè)轉(zhuǎn)賬的例子來(lái)講解本方案的一個(gè)大致事務(wù)管理的過(guò)程. 一個(gè)轉(zhuǎn)賬的操作涉及到的有賬戶(hù)類(lèi), 簡(jiǎn)單來(lái)說(shuō), 這個(gè)賬戶(hù)包括了賬號(hào)、姓名、余額; 現(xiàn)在涉及事務(wù)的操作共分成兩步: 一個(gè)賬戶(hù)是扣掉金額,另一個(gè)則是增加金額.

首先賬戶(hù)這個(gè)PO類(lèi)在進(jìn)行設(shè)計(jì)時(shí), 除了必要的字段外, 還需增加一個(gè)事務(wù)標(biāo)識(shí), 設(shè)為transationId, 所以現(xiàn)在這個(gè)賬戶(hù)類(lèi)共有4個(gè)字段: ID(賬號(hào))、NAME(姓名)、BALANCE(金額)、TRANSACTIONID(事務(wù)標(biāo)識(shí)), 此事務(wù)標(biāo)識(shí)字段在涉及到事務(wù)操作時(shí)才會(huì)保存在數(shù)據(jù)庫(kù)中.

假設(shè)現(xiàn)在張三李四兩個(gè)賬戶(hù)轉(zhuǎn)賬之前在MongoDB數(shù)據(jù)庫(kù)中的信息如表1所示.

表1 轉(zhuǎn)賬前張三李四賬戶(hù)信息

現(xiàn)在張三給李四轉(zhuǎn)賬200塊, 如果事務(wù)執(zhí)行成功,那么在業(yè)務(wù)邏輯層處理時(shí), 涉及事務(wù)的2個(gè)操作是: 1)張三余額扣200; 2) 李四余額增加200. 這兩個(gè)修改的操作在經(jīng)過(guò)了MongoDB數(shù)據(jù)訪問(wèn)層后, 實(shí)際的操作由修改兩個(gè)賬戶(hù)的余額的操作變成新增兩條記錄的操作,記錄中帶有事務(wù)標(biāo)識(shí), 此事務(wù)標(biāo)識(shí)完全不影響賬戶(hù)的信息, 只是這個(gè)標(biāo)識(shí)讓我們知道這兩條信息曾經(jīng)參與過(guò)了某個(gè)事務(wù)的控制過(guò)程而已. 因此通過(guò)MongoDB數(shù)據(jù)訪問(wèn)層之后, 現(xiàn)在張三李四兩個(gè)賬戶(hù)轉(zhuǎn)賬后在MongoDB數(shù)據(jù)庫(kù)中的信息如表2所示.

表2 轉(zhuǎn)賬后張三李四賬戶(hù)信息

從表2可以看出, 新增兩個(gè)賬戶(hù)的金額已經(jīng)修改了,同時(shí)帶有相同的事務(wù)標(biāo)識(shí)字段, 同時(shí)原來(lái)張三和李四在轉(zhuǎn)賬前的數(shù)據(jù)記錄保持不變. 在事務(wù)前期, 兩個(gè)賬戶(hù)的主鍵及生成的transactionId需預(yù)先發(fā)送至MQ隊(duì)列中,而在事務(wù)成功提交后, 發(fā)送給MQ的是個(gè)事務(wù)執(zhí)行成功的標(biāo)識(shí), 守護(hù)進(jìn)程定期監(jiān)測(cè)接收MQ中的事務(wù)處理標(biāo)識(shí), 最后守護(hù)進(jìn)程根據(jù)事務(wù)執(zhí)行成功的標(biāo)識(shí), 通過(guò)之前接收到的主鍵值刪除張三李四轉(zhuǎn)賬前的記錄, 此刪除操作是具有原子性的一個(gè)命令操作, 進(jìn)而銷(xiāo)毀了轉(zhuǎn)賬前的舊數(shù)據(jù), 保留了轉(zhuǎn)賬后的數(shù)據(jù).

如果現(xiàn)在張三余額在執(zhí)行扣錢(qián)操作之后發(fā)生了某個(gè)數(shù)據(jù)庫(kù)異常, 此時(shí)事務(wù)執(zhí)行失敗, 此時(shí)張三李四兩個(gè)賬戶(hù)在MongoDB數(shù)據(jù)庫(kù)中的信息如表3所示.

表3 轉(zhuǎn)賬異常后張三李四賬戶(hù)信息

從表3看出由于異常發(fā)生在了張三給李四轉(zhuǎn)賬的過(guò)程中, 數(shù)據(jù)庫(kù)只增加一條張三的信息, 異常導(dǎo)致事務(wù)將進(jìn)行回滾操作. 而新增的數(shù)據(jù)的transactionId在事務(wù)開(kāi)始前期已經(jīng)發(fā)送給守護(hù)進(jìn)程, 守護(hù)進(jìn)程將利用它對(duì)MongoDB數(shù)據(jù)庫(kù)中的臟數(shù)據(jù)進(jìn)行清理, 而原來(lái)的張三李四的賬戶(hù)信息還保留著, 回到了最初轉(zhuǎn)賬前賬戶(hù)的數(shù)據(jù)信息, 從而做到數(shù)據(jù)回滾.

5 結(jié)語(yǔ)

本文通過(guò)對(duì)MongoDB數(shù)據(jù)訪問(wèn)層的設(shè)計(jì), 規(guī)定了數(shù)據(jù)保存到MongoDB時(shí)的轉(zhuǎn)變模式, 事務(wù)控制類(lèi)獲取更新記錄相關(guān)數(shù)據(jù)后通過(guò)MQ消息中間件來(lái)與守護(hù)進(jìn)程進(jìn)行事務(wù)處理結(jié)果的通信, 從而將原本需要在MongoDB進(jìn)行多次的寫(xiě)操作轉(zhuǎn)變成了在MongoDB進(jìn)行一次性刪除數(shù)據(jù)的操作.

此方案將MongoDB對(duì)單個(gè)操作的原子特性用在最后的臟數(shù)據(jù)處理上, 而不是事務(wù)的操作序列上, 即將多個(gè)原子操作轉(zhuǎn)變成一個(gè)原子操作, 同時(shí)配合守護(hù)進(jìn)程與MQ的及時(shí)通信, 保證事務(wù)原有的ACID特性.

1徐娟娟, 朱成亮. NOSQL在WEB日志分析中的應(yīng)用. 中國(guó)新技術(shù)新產(chǎn)品, 2011, (10): 27. [doi: 10.3969/j.issn.1673-9957.2011.10.025]

2MongoDB Home. http://grokbase.com/t/gg/mongodb-user/12836feerg/locking-for-atomic-transactions.

3Plantikow S, Reinefeld A, Schintke F. Transactions for distributed wikis on structured overlays. Proc. Distributed Systems: Operations and Management 18th IFIP/IEEE International Conference on Managing Virtualization of Networks and Services. San José, CA, USA. 2007. 256–267.

4Bernstein PA, Newcomer E. Principles of transaction processing. San Francisco, California: Morgan Kaufmann Publishers, Inc., 1997. 56–59.

5Transaction Processing Performance Council. TPC BENCHMARKTMC, Standard Specification Revision 5.0,2001-02-26.

6Haase K. JavaTM message service API tutorial. Palo Alto,California: Sun Microsystems, Inc., 2002.

7周城, 葛斌, 蔣林承. 一種基于消息中間件的網(wǎng)頁(yè)實(shí)時(shí)處理技術(shù). 電腦知識(shí)與技術(shù), 2011, 7(10): 2269–2271. [doi: 10.3969/j.issn.1009-3044.2011.10.021]

8Tackett J Jr, Gunter D. Linux大全. 3版. 北京: 電子工業(yè)出版社, 1998: 25–26.

9張忠杰, 田質(zhì)廣. 編寫(xiě)Linux守護(hù)進(jìn)程. 山東輕工業(yè)學(xué)院學(xué)報(bào), 2001, 15(4): 5–9.

10張偉, 居悌. UNIX系統(tǒng)中常駐進(jìn)程的一個(gè)應(yīng)用實(shí)例. 微機(jī)發(fā)展, 1999, (5): 50–52.

11彭勇. Delphi 5.0網(wǎng)絡(luò)與通信開(kāi)發(fā)應(yīng)用. 北京: 中國(guó)水利水電出版社, 2000: 36–38.

12Zhang YT, Liao JX, Zhang TY, et al. A novel method for the short message or multimedia message synchronization. Proc.International Conference on Wireless and Mobile Communications. Bucharest, Romania. 2006. 75.

Analysis of Scheme Supporting MongoDB Transaction Management

WANG Tian-Sheng1,2, YU Shuang-Mei3, CUI Wei1, LIU Di1,4, HE Jin-Ling5, SUN Qi5

1(State Grid Information &Telecommunication Co. Ltd., Beijing 100761, China)
2(Xiamen Great Power Geo Information Technology Co. Ltd., Xiamen 361000, China)
3(Anhui Jiyuan Software Co.Ltd., Hefei 230088, China)
4(Beijing China-Power Information Technology Co. Ltd., Beijing 100085, China)
5(State Grid Jiangsu Electric Power Company &Telecommunication Branch, Nanjing 210008, China)

As a database based on distributed file storage, with powerful single table query language, and extensible high performance data storage, MongoDB is very popular among users. But is does not fully support the transaction, leaving the uses of the MongoDB passive. In order to improve the mongo compatibility of transaction management, a solution of supportting MongoDB transaction management and perfecting its function is proposed. The communication between daemon processes and MQ are utilized to make daemon processes clean up the dirty data after a transaction commits or rolls back, ensuring the availability and security of MongoDB in terms of transaction management.

distributed database; mongoDB; transaction management; daemon processes; MQ; message communication

汪添生,尉雙梅,崔蔚,劉迪,何金陵,孫琦.支持MongoDB的事務(wù)管理方案研究.計(jì)算機(jī)系統(tǒng)應(yīng)用,2017,26(7):278–282. http://www.c-sa.org.cn/1003-3254/5926.html

2016-11-09; 收到修改稿時(shí)間: 2017-01-04