肖冰,郭進(jìn)偉,錢衛(wèi)寧

(華東師范大學(xué)數(shù)據(jù)科學(xué)與工程研究院,上海200062)

可擴(kuò)展數(shù)據(jù)管理系統(tǒng)中的網(wǎng)絡(luò)請求服務(wù)機(jī)制

肖冰,郭進(jìn)偉,錢衛(wèi)寧

(華東師范大學(xué)數(shù)據(jù)科學(xué)與工程研究院,上海200062)

請求服務(wù)機(jī)制涉及請求的傳輸和處理,是分布式數(shù)據(jù)管理系統(tǒng)中各組件交互并完成任務(wù)的重要前提.本文以可擴(kuò)展數(shù)據(jù)管理系統(tǒng)為背景,抽象系統(tǒng)中的網(wǎng)絡(luò)服務(wù)模型,介紹系統(tǒng)中的網(wǎng)絡(luò)請求服務(wù)機(jī)制.從數(shù)據(jù)庫的主要實(shí)現(xiàn)出發(fā),分析不同類型的請求在傳輸以及處理上的不同要求.以O(shè)ceanBase為例,統(tǒng)計(jì)各機(jī)制在一個可擴(kuò)展數(shù)據(jù)管理系統(tǒng)中的服務(wù)比重,并進(jìn)行相關(guān)的分析.

可擴(kuò)展數(shù)據(jù)管理系統(tǒng);網(wǎng)絡(luò)請求;OceanBase

0 引言

傳統(tǒng)單機(jī)模式數(shù)據(jù)庫有限的存儲能力及其縱向擴(kuò)展方式已經(jīng)不適合互聯(lián)網(wǎng)應(yīng)用對海量數(shù)據(jù)的存儲和處理所帶來的需求.隨著計(jì)算機(jī)網(wǎng)絡(luò)與通信技術(shù)的發(fā)展,越來越多的分布式數(shù)據(jù)庫系統(tǒng)應(yīng)運(yùn)而生,如Megastore[1],Cassandra[2]等.這些分布式數(shù)據(jù)管理系統(tǒng)采用橫向擴(kuò)展的方式,通過向系統(tǒng)中添加機(jī)器,來達(dá)到系統(tǒng)支持更高并發(fā)服務(wù)的目的[3].與集中式數(shù)據(jù)庫相比,分布式數(shù)據(jù)庫系統(tǒng)包含多個在地理上分離而在邏輯上集中的節(jié)點(diǎn),通過網(wǎng)絡(luò)互連通信.每個節(jié)點(diǎn)在網(wǎng)絡(luò)上都是獨(dú)立的服務(wù)器(也可以引申為數(shù)據(jù)庫進(jìn)程),能夠自主存儲并管理本地?cái)?shù)據(jù),但同時所有節(jié)點(diǎn)通過系統(tǒng)能夠作為整體對外服務(wù)[4].

在互聯(lián)網(wǎng)高速發(fā)展的今天,數(shù)據(jù)量呈指數(shù)增長,數(shù)據(jù)類型也展現(xiàn)出多樣性,大量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)需要更加高效地存儲和處理[5].這不僅使得集中式數(shù)據(jù)庫系統(tǒng)愈加難以滿足需求,甚至傳統(tǒng)架構(gòu)的分布式數(shù)據(jù)庫也不再適應(yīng).為了應(yīng)對這些挑戰(zhàn),很多企業(yè),特別是互聯(lián)網(wǎng)企業(yè)開始尋求新的解決方案,提出新的分布式存儲架構(gòu)和管理方式,并實(shí)現(xiàn)了成熟的、適應(yīng)海量數(shù)據(jù)應(yīng)用需求的分布式數(shù)據(jù)庫[6].新型分布式數(shù)據(jù)庫是一種集群式架構(gòu)的系統(tǒng),內(nèi)部通過高速網(wǎng)絡(luò)互連,數(shù)據(jù)以多副本形式分布存儲于部分節(jié)點(diǎn)中,其最重要的特征是高可擴(kuò)展性,因此又被稱為可擴(kuò)展數(shù)據(jù)管理系統(tǒng),如HBase[7],Spanner[8],OceanBase[9-10]等.

而對于這樣的可擴(kuò)展數(shù)據(jù)管理系統(tǒng)而言,請求服務(wù)機(jī)制真正將系統(tǒng)中的各個功能節(jié)點(diǎn)聯(lián)系起來形成一個整體對外服務(wù),是系統(tǒng)功能的前提和性能的保證.圖1所示為一個可擴(kuò)展數(shù)據(jù)管理系統(tǒng)中的各功能節(jié)點(diǎn),其中,主控節(jié)點(diǎn)MNode(Master-Node)負(fù)責(zé)管理集群內(nèi)所有節(jié)點(diǎn)的狀態(tài)信息,幫助各個節(jié)點(diǎn)協(xié)同工作,管理集群、數(shù)據(jù)分布以及副本;事務(wù)處理節(jié)點(diǎn)TNode(Transaction-Node)負(fù)責(zé)處理寫事務(wù),并存儲增量更新的數(shù)據(jù),是數(shù)據(jù)庫集群中負(fù)載較高的節(jié)點(diǎn)之一;基線數(shù)據(jù)存儲節(jié)點(diǎn)SNode(Storage-Node)存儲大部分的用戶數(shù)據(jù),提供對數(shù)據(jù)的讀訪問支持,能夠自動合并基線數(shù)據(jù)和事務(wù)處理節(jié)點(diǎn)上的增量數(shù)據(jù)返回給用戶;客戶端管理器CMgr(Client-Manager)用來管理客戶端通信,對外提供服務(wù)接口(此處的客戶端指系統(tǒng)用戶,不同于后文中提到的網(wǎng)絡(luò)模型中的客戶端).

圖1 可擴(kuò)展數(shù)據(jù)管理系統(tǒng)架構(gòu)圖Fig.1Architecture of a scalable database management system

為了更好地理解可擴(kuò)展數(shù)據(jù)管理系統(tǒng)中的請求服務(wù)機(jī)制,本文基于系統(tǒng)架構(gòu),抽象了系統(tǒng)中網(wǎng)絡(luò)請求服務(wù)的Client/Server模型,并基于該模型概括了3種請求傳輸機(jī)制和4種請求處理機(jī)制.以O(shè)ceanBase為例統(tǒng)計(jì)分析了TPC-C各類型事務(wù)負(fù)載下各機(jī)制所占的比重,并總結(jié)了不同的請求類型對系統(tǒng)的不同要求.

本文的后續(xù)內(nèi)容組織如下:第1節(jié)介紹網(wǎng)絡(luò)請求服務(wù)基礎(chǔ),以及可擴(kuò)展數(shù)據(jù)管理系統(tǒng)在經(jīng)典的Client/Server模型下包含的幾種請求的傳輸和處理機(jī)制;第2節(jié)在TPC-C多類型的事務(wù)負(fù)載下,以O(shè)ceanBase為例,統(tǒng)計(jì)可擴(kuò)展數(shù)據(jù)管理系統(tǒng)中各機(jī)制處理的請求占整個系統(tǒng)的比重,分析其與系統(tǒng)架構(gòu)的關(guān)系;最后,第3節(jié)總結(jié)全文.

1 網(wǎng)絡(luò)請求服務(wù)基礎(chǔ)

1.1 網(wǎng)絡(luò)請求服務(wù)模型

最原始的網(wǎng)絡(luò)請求服務(wù)使用的是阻塞型接口,需要等待調(diào)用結(jié)果的返回,這樣的模型一次只能響應(yīng)一個客戶端請求,無法滿足多客戶端的應(yīng)用帶來的網(wǎng)絡(luò)要求.對此最簡單的解決方式是在服務(wù)端使用多線程,讓每一個連接都有獨(dú)立的線程,這樣任何一個連接的阻塞都不會影響到其他的連接.但是多線程模型會嚴(yán)重占用系統(tǒng)資源,降低系統(tǒng)對外界的響應(yīng)效率.也就是說,多線程模型中每個線程依然只能處理一路I/O,適合處理短連接,而且是連接的打開關(guān)4非常頻繁的情形,并不適合處理長連接.因?yàn)檫^多的線程依然會使服務(wù)器的性能下降.一般系統(tǒng)的底層網(wǎng)絡(luò)服務(wù)選用Linux select或epoll等I/O多路復(fù)用接口[11],使用句柄操作,可以同時從多個客戶端接收數(shù)據(jù),同時對多個句柄進(jìn)行讀、寫和異常狀態(tài)的檢測,保證并發(fā).這個環(huán)節(jié)只管收,不處理任務(wù),把句柄放到一個緩沖區(qū)里面,然后業(yè)務(wù)處理模型對接線程池,可以使復(fù)雜業(yè)務(wù)處理上的負(fù)擔(dān)被分擔(dān).但當(dāng)句柄值較大時,接口本身需要消耗大量時間去輪詢各個句柄.

如果選擇異步的方式,需要在業(yè)務(wù)處理里使用完全的異步API(Application Programming Interface),如OceanBase底層使用了開源的事件驅(qū)動庫libev[12].很多業(yè)務(wù)要保障流程的正確是需要同步操作的.異步回調(diào)和4包在編程實(shí)現(xiàn)上帶來了一定的復(fù)雜度和風(fēng)險(xiǎn). UNIX平臺下多進(jìn)程模型擅長處理并發(fā)長連接,但不適用于連接頻繁產(chǎn)生和關(guān)4的情形.最高效的模型是異步非阻塞I/O,而且不用select/epoll接口,因?yàn)檫@兩個接口都有著O(n)的時間復(fù)雜度[11].異步非阻塞I/O模型下的編程是有一定難度的,由于I/O操作不再阻塞,需要親自管理維護(hù)每個連接的狀態(tài).為了充分利用CPU,還應(yīng)結(jié)合線程池,避免在輪詢線程中處理業(yè)務(wù)邏輯.

圖2 可擴(kuò)展數(shù)據(jù)管理系統(tǒng)中的網(wǎng)絡(luò)服務(wù)模型圖Fig.2Network server model of a scalable database management system

圖2抽象了可擴(kuò)展數(shù)據(jù)管理系統(tǒng)中的網(wǎng)絡(luò)服務(wù)模型,我們說當(dāng)一臺服務(wù)機(jī)S1向另外一臺服務(wù)機(jī)S2請求服務(wù)時,S1就被稱為客戶端,S2被稱為服務(wù)端.服務(wù)端接收客戶端發(fā)送的網(wǎng)絡(luò)包,通常會將網(wǎng)絡(luò)包加入到任務(wù)隊(duì)列中[13].接著,工作線程會從任務(wù)隊(duì)列中不斷獲取網(wǎng)絡(luò)包進(jìn)行處理,處理完成后應(yīng)答客戶端.而系統(tǒng)中一臺服務(wù)機(jī)在不同的任務(wù)當(dāng)中往往會充當(dāng)不同的角色.系統(tǒng)中的各個節(jié)點(diǎn)往往會同時封裝客戶端和服務(wù)端,在不同的處理流程中,節(jié)點(diǎn)會首先定位自己的角色然后調(diào)用相關(guān)的處理方法.

1.2 可擴(kuò)展數(shù)據(jù)管理系統(tǒng)中的請求服務(wù)機(jī)制

可擴(kuò)展數(shù)據(jù)管理系統(tǒng)中的請求傳輸機(jī)制主要分為兩種:一種是客戶端發(fā)送請求并需要服務(wù)端回復(fù)請求,如查詢內(nèi)存表;另一種是客戶端發(fā)送消息不需要服務(wù)端回復(fù),如異步日志回放.如圖3,我們將只響應(yīng)不回復(fù)的服務(wù)端稱為響應(yīng)端.其中,需要回復(fù)的請求又分為同步請求和異步請求.同步請求需等待服務(wù)端返回響應(yīng),如獲取元數(shù)據(jù)[14],而異步請求則不需要,如心跳.異步請求時,客戶端將請求包加入到網(wǎng)絡(luò)發(fā)送隊(duì)列后立即返回,不等待應(yīng)答.同步請求時,客戶端將請求包加入到網(wǎng)絡(luò)發(fā)送隊(duì)列后開始阻塞等待,直到網(wǎng)絡(luò)線程接收到服務(wù)端的應(yīng)答后才喚醒客戶端,從而執(zhí)行后續(xù)處理邏輯.而不需要回復(fù)的請求表現(xiàn)為單向通信,對方接到消息后立即執(zhí)行處理邏輯,請求的發(fā)送即為請求的結(jié)束.

圖3 請求的傳輸機(jī)制Fig.3Request transmitting mechanism

在生產(chǎn)者/消費(fèi)者模型中,往往有一個全局任務(wù)隊(duì)列,生產(chǎn)者將任務(wù)加入到任務(wù)隊(duì)列,消費(fèi)者從任務(wù)隊(duì)列中取出任務(wù)進(jìn)行處理[6].圖4展示了請求處理機(jī)制對于不同的任務(wù)有不同的處理[15].對于處理時間比較短的任務(wù),采用I/O線程直接處理的方式,可以減少上下文切換.基于事件循環(huán)的多I/O線程能夠增加網(wǎng)絡(luò)的收發(fā)能力[16].將處理時間比較長的任務(wù)加入隊(duì)列,工作線程不斷地從任務(wù)隊(duì)列取出任務(wù)進(jìn)行處理.所有的網(wǎng)絡(luò)I/O線程和工作線程操作全局任務(wù)隊(duì)列都需要首先獲取獨(dú)占鎖,這種方式的鎖沖突嚴(yán)重,將導(dǎo)致大量操作系統(tǒng)上下文切換.為了解決這個問題,給每個工作線程分配一個任務(wù)隊(duì)列,網(wǎng)絡(luò)I/O線程按照一定的策略選擇一個任務(wù)隊(duì)列并加入任務(wù).選擇策略如隨機(jī)選擇,通過全局任務(wù)計(jì)數(shù)計(jì)算出任務(wù)所屬的任務(wù)隊(duì)列,或者選擇一個任務(wù)個數(shù)最少的任務(wù)隊(duì)列.如果某個任務(wù)的處理時間很長,就有可能出現(xiàn)任務(wù)不均衡的情況,即某個線程的任務(wù)隊(duì)列中還有很多任務(wù)未被處理,其他線程卻處于空閑狀態(tài).可以采取一個很簡單的策略應(yīng)對這種情況:每個工作線程首先嘗試從對應(yīng)的任務(wù)隊(duì)列中獲取任務(wù),如果由于隊(duì)列為空獲取任務(wù)失敗,則遍歷所有工作線程的任務(wù)隊(duì)列,直到獲取任務(wù)成功或者遍歷完所有的任務(wù)隊(duì)列為止.

圖4 請求的處理機(jī)制Fig.4Request processing mechanism

這樣的任務(wù)隊(duì)列在后文歸類中我們稱之為普通隊(duì)列.

2 OceanBase的請求服務(wù)統(tǒng)計(jì)分析

本節(jié)以第1節(jié)中抽象的可擴(kuò)展數(shù)據(jù)管理系統(tǒng)中的網(wǎng)絡(luò)請求服務(wù)模型為基礎(chǔ),在TPC-C不同類型的事務(wù)負(fù)載下分析請求類型和服務(wù)機(jī)制,總結(jié)不同請求類型對應(yīng)的傳輸機(jī)制和處理機(jī)制,探索它們之間的關(guān)系.

2.1 傳輸機(jī)制與請求類型

表1列出了系統(tǒng)中的傳輸機(jī)制與請求類型的對應(yīng)關(guān)系.首先,系統(tǒng)中每個節(jié)點(diǎn)通過心跳檢測其他節(jié)點(diǎn)是否存活,心跳發(fā)出后不必阻塞等待節(jié)點(diǎn)的回復(fù),心跳響應(yīng)會以不需要回復(fù)的方式返回給請求節(jié)點(diǎn).如MNode向TNode發(fā)送一個心跳請求以確認(rèn)該事務(wù)處理節(jié)點(diǎn)仍然存活,請求發(fā)送后立即返回,TNode隨后會向MNode發(fā)送一個心跳響應(yīng)的信號,來告訴MNode自己仍然存活.這一類用來維護(hù)節(jié)點(diǎn)間關(guān)系的請求,通常是通過異步的方式來發(fā)送.

在集群啟動時,其他節(jié)點(diǎn)需要向主控節(jié)點(diǎn)注冊自己的角色,這樣的注冊請求需要阻塞等待回復(fù)方可進(jìn)行后續(xù)的操作.當(dāng)節(jié)點(diǎn)需要獲取描述系統(tǒng)或系統(tǒng)中用戶對象的元數(shù)據(jù)時,也需要同步等待數(shù)據(jù)的返回結(jié)果加入輸出緩沖區(qū).如MNode獲取SNode成員鏈表時,主控節(jié)點(diǎn)的客戶端管理器會向其服務(wù)端管理器發(fā)送請求,服務(wù)端管理器接到請求后立即進(jìn)行相關(guān)的處理,將SNode成員鏈表信息加入輸出緩沖區(qū),隨后立即喚醒I/O線程響應(yīng)客戶端管理器.又如SNode向MNode獲取模式信息時,SNode的客戶端管理器向MNode的服務(wù)端管理器發(fā)送獲取模式信息的請求,MNode接受該類型的請求后立即處理,將相關(guān)模式信息加入輸出緩沖區(qū)后喚醒I/O線程響應(yīng)SNode.同樣的同步傳輸機(jī)制還應(yīng)用于操作SQL、獲取版本、執(zhí)行事務(wù)、處理觸發(fā)事件等.

表1 客戶端傳輸機(jī)制及請求類型Tab.1Transmitting mechanisms and request types in client

還有一類請求是不需要回復(fù)的,客戶端發(fā)出后即結(jié)束,服務(wù)端接收到請求后進(jìn)行響應(yīng)即可.這里我們稱服務(wù)端為響應(yīng)端.通常情況下這一類的請求是不帶數(shù)據(jù)的請求,而且請求包傳輸?shù)巾憫?yīng)端后生命周期立即終止,響應(yīng)端的后續(xù)處理由此觸發(fā)但并不會延續(xù)請求的生命周期.如事務(wù)處理節(jié)點(diǎn)TNode在啟動時需要異步回放提交日志,此時TNode客戶端管理器會向其服務(wù)端管理器發(fā)送不帶輸入輸出緩沖區(qū)的空請求,服務(wù)端管理器接到請求后立即回放日志,響應(yīng)過程結(jié)束.這一個過程與異步傳輸機(jī)制中的服務(wù)端向客戶端返回結(jié)果十分類似,但是場景不同,因而這里做一個區(qū)分,并將只處理不回復(fù)的服務(wù)端稱為響應(yīng)端.

2.2 處理機(jī)制與請求類型

服務(wù)端接受一個請求后就要進(jìn)行相應(yīng)的處理或者響應(yīng),在不同的服務(wù)端對應(yīng)不同類型的請求有不同的請求處理機(jī)制.系統(tǒng)常常使用隊(duì)列作為客戶端和服務(wù)器之間的請求和應(yīng)答的緩沖區(qū)[17].在一個可擴(kuò)展的數(shù)據(jù)管理系統(tǒng)中,事務(wù)處理節(jié)點(diǎn)往往處理較核心的業(yè)務(wù)任務(wù),也承擔(dān)著一定比重的負(fù)載,因此TNode上的處理機(jī)制有多種,而SNode不需要維護(hù)隊(duì)列來管理請求, MNode只需要簡單的隊(duì)列來管理請求.

對于SNode而言,不管是異步的心跳請求,同步的獲取元數(shù)據(jù)的請求,還是建表的請求都直接在I/O線程就地處理,因?yàn)檫@些請求往往不帶數(shù)據(jù)只帶報(bào)頭,處理時間通常在幾十微秒的數(shù)量級,結(jié)束后B將結(jié)果返回給客戶端.而MNode作為主控節(jié)點(diǎn)管理元數(shù)據(jù),會區(qū)分請求的類型用不同的隊(duì)列進(jìn)行管理,如數(shù)據(jù)讀取類請求歸讀隊(duì)列管理,數(shù)據(jù)修改類請求歸寫隊(duì)列管理,節(jié)點(diǎn)間協(xié)調(diào)關(guān)系類請求歸租約隊(duì)列來管理.由于這些請求在MNode上的到達(dá)和處理順序隨機(jī),所以這里的隊(duì)列類型均為普通隊(duì)列.然而對于事務(wù)處理節(jié)點(diǎn)TNode而言,復(fù)雜的事務(wù)處理和較高的任務(wù)負(fù)載決定該節(jié)點(diǎn)的請求處理機(jī)制不僅僅是I/O線程就地處理和普通隊(duì)列+工作線程的方式就能很好地應(yīng)對的.OceanBase的TNode為了保證事務(wù)的提交順序,采用FIFO(First-In-First-Out)的隊(duì)列來處理事務(wù)提交的請求,而在事務(wù)的執(zhí)行上采用優(yōu)先級隊(duì)列的方式,因?yàn)槠胀?duì)列和FIFO隊(duì)列都不能滿足事務(wù)并發(fā)控制可能帶來的優(yōu)先級要求.而對于短任務(wù)比如異常狀態(tài)下請求的直接退出、提交異步任務(wù)時的日志回訪請求,TNode都會在I/O線程直接處理,不會排隊(duì).對于節(jié)點(diǎn)間協(xié)調(diào)關(guān)系類的請求如心跳,TNode會同MNode一樣采用普通隊(duì)列來構(gòu)建租約隊(duì)列進(jìn)行管理.我們將服務(wù)端的請求處理機(jī)制與請求類型歸納總結(jié)為表2.

表2 服務(wù)端處理機(jī)制及請求類型Tab.2Processing mechanisms and request types in server

可以看出,對于請求的處理機(jī)制,首要的區(qū)別是請求是否需要排隊(duì),其次是對于需要排隊(duì)的請求,針對不同的請求類型和節(jié)點(diǎn)處理的特點(diǎn),選擇不同類型的隊(duì)列.

2.3 ?類型事務(wù)下的請求服務(wù)統(tǒng)計(jì)分析

TPC-C是數(shù)據(jù)庫管理系統(tǒng)在線事務(wù)處理(OLTP)性能測試的國際標(biāo)準(zhǔn)[18],已得到廣泛認(rèn)可.為了在一定程度上反應(yīng)可擴(kuò)展數(shù)據(jù)管理系統(tǒng)中各個請求服務(wù)機(jī)制的分布情況,本小節(jié)統(tǒng)計(jì)了TPC-C多類型事務(wù)下各機(jī)制服務(wù)的請求占比.并進(jìn)行相關(guān)的簡要分析.

圖5 2種傳輸機(jī)制的比例分布情況Fig.5Proportional distribution of the two transmitting mechanisms

圖5所示為同步和異步兩種請求傳輸機(jī)制的占比情況,這里沒有考慮無回復(fù)的請求,因?yàn)榇蟛糠诌@一類的請求均表現(xiàn)為節(jié)點(diǎn)內(nèi)部的信號,很大程度上不構(gòu)成網(wǎng)絡(luò)I/O的開銷.從圖5可以看出,在TPC-C所有的5種事務(wù)類型中,同步傳輸機(jī)制所服務(wù)的請求要比異步傳輸機(jī)制服務(wù)的請求量高出1.5倍到4倍.其中,對于Delivery的事務(wù)類型,同步傳輸機(jī)制服務(wù)的請求比重在所有的TPC-C事務(wù)類型中為最高,這跟該類型負(fù)載中大量的批處理直接相關(guān).而OrderStatus更多的是處理用戶的查詢,所以異步傳輸機(jī)制服務(wù)的請求量相對較高.

可以看出,對于可擴(kuò)展的數(shù)據(jù)管理系統(tǒng)而言,同步機(jī)制是網(wǎng)絡(luò)請求傳輸?shù)闹饕绞?

由于OceanBase底層使用了libev事件驅(qū)動庫,所以它的同步處理機(jī)制是基于底層的異步I/O實(shí)現(xiàn)的,這在一定程度上也優(yōu)化了系統(tǒng)同步機(jī)制的發(fā)送性能.

而對于網(wǎng)絡(luò)請求的處理機(jī)制而言,如圖6所示,我們可以看到,FIFO的隊(duì)列管理方式在一個數(shù)據(jù)庫管理系統(tǒng)中不可或缺[19],但是在一個可擴(kuò)展數(shù)據(jù)管理系統(tǒng)中所能處理的請求已經(jīng)不再占有較大的比重.取而代之的是優(yōu)先級隊(duì)列.對于一些對執(zhí)行順序不敏感的請求,系統(tǒng)還采用了隨機(jī)出入隊(duì)的普通隊(duì)列,進(jìn)而降低一部分維護(hù)成本.系統(tǒng)中還有大量的短任務(wù)可以在I/O線程就地處理,主要表現(xiàn)在SNode對請求的轉(zhuǎn)發(fā)和系統(tǒng)內(nèi)各節(jié)點(diǎn)的心跳信號.

圖6 4種處理機(jī)制的比例分布情況Fig.6Proportional distribution of the four processing mechanisms

如果將TNode節(jié)點(diǎn)視為一個內(nèi)存數(shù)據(jù)庫,當(dāng)所有的讀寫操作都可以在內(nèi)存上直接進(jìn)行時,不阻塞的事務(wù)讀取請求可以在I/O線程就地處理,這將提升數(shù)據(jù)庫的請求服務(wù)性能.

3 結(jié)論

網(wǎng)絡(luò)請求服務(wù)機(jī)制是可擴(kuò)展數(shù)據(jù)管理系統(tǒng)底層支持的重要部分.本文從系統(tǒng)的架構(gòu)出發(fā),抽象網(wǎng)絡(luò)服務(wù)的Client/Server模型,分別以客戶端和服務(wù)端的角度總結(jié)概括了模型中網(wǎng)絡(luò)請求的傳輸機(jī)制和處理機(jī)制,并將請求傳輸機(jī)制分為3種,將請求處理機(jī)制分為4種,關(guān)聯(lián)不同的請求類型進(jìn)行具體介紹.以O(shè)ceanBase為例,文章在TPC-C不同類型的事務(wù)負(fù)載下統(tǒng)計(jì)了各機(jī)制所處理的請求占系統(tǒng)所有請求的比重,并分析了不同的請求類型對系統(tǒng)帶來的不同要求,及其與服務(wù)機(jī)制的關(guān)系.

可擴(kuò)展數(shù)據(jù)管理系統(tǒng)除了實(shí)現(xiàn)集群規(guī)模的伸縮性,也需要提供高性能事務(wù).為事務(wù)類型的請求進(jìn)行恰當(dāng)?shù)姆?wù)機(jī)制的選擇是事務(wù)處理性能得以保證的前提.網(wǎng)絡(luò)請求的發(fā)送機(jī)制主要分為同步機(jī)制和異步機(jī)制.對于數(shù)據(jù)庫而言,大部分事務(wù)相關(guān)或者寫任務(wù)相關(guān)的請求都需要采用同步機(jī)制.網(wǎng)絡(luò)請求處理機(jī)制的多樣性主要體現(xiàn)在系統(tǒng)的事務(wù)處理節(jié)點(diǎn).傳統(tǒng)的先入先出服務(wù)類型已經(jīng)無法滿足可擴(kuò)展架構(gòu)下的事務(wù)請求,因此,多種隊(duì)列各自配合工作線程的服務(wù)模型被應(yīng)用到可擴(kuò)展數(shù)據(jù)管理系統(tǒng)中.

［1］BAKER J,BOND C,CORBETT J.C,et al.Megastore:Providing scalable,highly available storage for interactive services[C]//Proceedings of CIDR.2011,11:223-234.

［2］LAKSHMAN A,MALIK P.Cassandra:A decentralized structured storage system[J].Operating Systems Review, 2010,44(2):35-40.

［3］COULOURIS G,DOLLIMORE J,KINDBERG T,et al.Distributed Systems:Concept and Design[M].Addison-Wesley,2012.

［4］?ZSU M T,VALDURIEZ P.Principles of Distributed Database Systems[M].New York:Springer-Verlag,2011.

［5］MARYANSKI F J.A survey of developments in distributed data base management systems[J].IEEE Computer, 1978,11(2):28-38.

［6］楊傳輝.大規(guī)模分布式是存儲系統(tǒng):原理解析與架構(gòu)實(shí)戰(zhàn)[M].北京:機(jī)械工業(yè)出版社,2013.

［7］Apache.Apache HBase[EB/OL].[2016-06-10].https://hbase.apache.org.

［8］CORBETT J C,DEAN J,EPSTEIN M,et al.Spanner:Google’s globally distributed database[J].ACM Trans Comput Syst,2013,31(3):8.

［9］陽振坤.Oceanbase關(guān)系數(shù)據(jù)庫架構(gòu)[J].華東師范大學(xué)學(xué)報(bào)(自然科學(xué)版),2014,6(5):141-148.

［10］OceanBase[EB/OL].[2016-06-10].https://github.com/alibaba/oceanbase.

［11］STEVENS W R,FENNER B,RUDOFF A M.UNIX Network Programming,Volume 1:The Sockets Networking API[M].Addison-Wesley Professional.2003.

［12］Libev[EB/OL].[2016-06-10].http://software.schmorp.de/pkg/libev.html.

［13］GARCIS-MOLINA H,ULLMAN J D,WIDOM J.Database System Implementation[M].New Jersey Prentice Hall,2009.

［14］CHANG L,WANG Z,MA T,et al.A massively parallel processing SQL engine in hadoop[C]//Proceedings of the 2014 ACM SIGMOD International Conference on Management of Data.New York:ACM,2014.

［15］STONEBRAKER M.Technical perspective-one size fits all:An idea whose time has come and gone[J].Commun ACM,2008,51(12):76.

［16］JOHNSON R,PANDIS I,AILAMAKI A.Eliminating unscalable communication in transaction processing[J]. VLDB Journal,2014,23(1):1-23.

［17］BERNSTEIN P A,NEWCOMER E.Principles of Transaction Processing[M].Morgan Kaufmann,2009.

［18］Transaction Processing Performance Council(TPC).TPC Benchmark C:Standard Specification[EB/OL].[2016-06-10].http://www.tpc.org/tpcc/.

［19］HELLERSTEIN J M,STONEBRAKER M,HAMILTON J.Architecture of a Database System[M].Hanover: Now Publishers Inc,2007.

(責(zé)任編輯:林磊)

Network request service mechanisms in a scalable database management system

XIAO Bing,GUO Jin-wei,QIAN Wei-ning
(Institute for Data Science and Engineering,East China Normal University,Shanghai200062,China)

Network request service mechanism involves the transmitting and processing of the requests.It plays an important role for interactive components to cooperate in a distributed database management system.Taking scalable database management systems as background,this paper introduces the inside network service model and the network request service mechanisms.On the basis of the primary implementation in database systems,we analyze different demands from different requests in terms of transmitting and processing.The service distribution of each mechanism and associative analysis are presented based on OceanBase.

scalable database management system;network request;OceanBase

TP391

A

10.3969/j.issn.1000-5641.2016.05.018

1000-5641(2016)05-0165-08

2016-05

國家863計(jì)劃項(xiàng)目(2015AA015307);國家自然科學(xué)基金(61432006)

肖冰,女,碩士研究生,研究方向?yàn)榉植际綌?shù)據(jù)庫.E-mail:bingxiao@stu.ecnu.edu.cn.

錢衛(wèi)寧,男,教授,研究方向?yàn)榭蓴U(kuò)展事務(wù)處理和海量數(shù)據(jù)管理與分析. E-mail:wnqian@sei.ecnu.edu.cn.