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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.1 具有事務(wù)標(biāo)識的PO類

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

1.2 更新方法的處理

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

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

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

1.3 事務(wù)控制

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

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

2 MQ消息通信

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

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

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

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

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

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

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

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

4 事務(wù)管理過程

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

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

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

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

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

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

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

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

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

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

5 結(jié)語

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

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

1徐娟娟, 朱成亮. NOSQL在WEB日志分析中的應(yīng)用. 中國新技術(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)頁實時處理技術(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ì)廣. 編寫Linux守護(hù)進(jìn)程. 山東輕工業(yè)學(xué)院學(xué)報, 2001, 15(4): 5–9.

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

11彭勇. Delphi 5.0網(wǎng)絡(luò)與通信開發(fā)應(yīng)用. 北京: 中國水利水電出版社, 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ī)系統(tǒng)應(yīng)用,2017,26(7):278–282. http://www.c-sa.org.cn/1003-3254/5926.html

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