【正文】 或者刪除數(shù)據(jù))首先要寫入WriteLog中，然后才會在TabletServer的寫緩存(WriteBuffer) 中操作。圖表 43 TabletServer數(shù)據(jù)的寫操作流程WriteLog文件的管理在本系統(tǒng)中，每個(gè)TabletServer實(shí)例只會以追加的方式寫一個(gè)log文件。由于每個(gè)TabkletServer同時(shí)會管理很多的Tablet，因此在Log中需要有區(qū)分不同的Tablet的字段。這中寫log方式的好處是管理的TFS句柄較少(只有一個(gè))，并且這種append的方式寫數(shù)據(jù)可以高效地利用TFS。缺點(diǎn)是要想讀取某一個(gè)Tablet對應(yīng)的log需要讀取整個(gè)log文件，具體的問題見本文下一節(jié)的論述。另一種可選方案是為每個(gè)Tablet建立一個(gè)log文件，好處是恢復(fù)時(shí)只需要讀tablet對應(yīng)的log即可，缺點(diǎn)是每個(gè)TabletServer需要管理很多TFS文件句柄。對于TFS系統(tǒng)來說，這種多文件的并發(fā)寫將造成TFS系統(tǒng)維護(hù)大量的已打開文件表，在實(shí)現(xiàn)上不夠高效。文獻(xiàn)[1]中對此問題也有提及。當(dāng)每個(gè)Tablet被分配到一個(gè)TabletServer上時(shí)，這個(gè)TabletServer會將其在Debby上的元數(shù)據(jù)的LogPath項(xiàng)改成當(dāng)前TabletServer正在寫的Log文件的路徑。WriteLog文件的命名每個(gè)Log文件的名稱是以當(dāng)前TabletServer服務(wù)的IP地址加端口號(前綴)再加創(chuàng)建此日志文件時(shí)的時(shí)間戳(后綴)組成，形如“:”。每當(dāng)TabletServer啟動(dòng)或者是做完一次Checkpoint，就會按照此規(guī)則生成一個(gè)新的Log文件。很顯然，按照Log文件名的后綴時(shí)間戳排序就可以完整的得到Log的創(chuàng)建順序，這對于下一步通過Log文件來恢復(fù)Tablet的狀態(tài)具有重要的作用。Log ReplayWriteLog的主要目的就是為了恢復(fù)Tablet內(nèi)存部分的數(shù)據(jù)，保證系統(tǒng)的一致性。當(dāng)一個(gè)Tablet所在的TabletServer節(jié)點(diǎn)失效后，它被重新分配后，新接收的TabletServer會從TFS上下載這個(gè)Tablet對應(yīng)的TSFile文件，并且讀取這個(gè)Tablet對應(yīng)的元數(shù)據(jù)，根據(jù)元數(shù)據(jù)中記錄的Log位置，恢復(fù)該Tablet在內(nèi)存中的數(shù)據(jù)部分，這個(gè)過程之為Log Replay。注意，這里會被Replay的Log文件不僅僅包括元數(shù)據(jù)中記錄的Log文件本身，同時(shí)也包括那些有相同前綴(IP地址加端口號)，并且后綴時(shí)間戳比它大的所有Log文件。Log的Replay過程具有冪等性。一個(gè)Log文件被Replay一次和被Replay多次，所得到的內(nèi)存映像是完全一樣的。這是因?yàn)樵赥SFile語義中Column, Key, Timestamp三元組是不能有重復(fù)的。因此，在這個(gè)實(shí)現(xiàn)過程中，我們需要保證至少一次語義來實(shí)現(xiàn)數(shù)據(jù)的一致性。所謂保證至少一次的語義是指，若一個(gè)操作沒有被證明確實(shí)成功，那么就會再做一次這個(gè)操作。較典型的是RPC操作，它意味著這個(gè)操作的消息至少一次被送達(dá)，服務(wù)端也至少一次執(zhí)行了這個(gè)操作。WriteLog的文件格式WriteLog主要面向兩種操作，寫數(shù)據(jù)和刪除數(shù)據(jù)，格式如下所示。Seq IDTimestampTablet IDOperationKeyValue(if need)圖表 44 Log的格式l Seq ID：Log條目的編號，從0開始，加1遞增。l Timestamp：寫此Log條目時(shí)的時(shí)間戳。l Tablet ID：此Log條目對應(yīng)的Tablet。l Operation：表示操作類型(寫/刪除)。l Key/Value：操作的數(shù)據(jù)。CheckpointCheckpoint是數(shù)據(jù)庫系統(tǒng)中常用到的方法。在本系統(tǒng)中，Checkpoint的目的有兩個(gè)，一個(gè)是保證數(shù)據(jù)的一致性。系統(tǒng)在checkpoint點(diǎn)上的狀態(tài)和數(shù)據(jù)是一致的。另一個(gè)目的是縮短實(shí)例的恢復(fù)時(shí)間。正是由于系統(tǒng)在checkpoint點(diǎn)上數(shù)據(jù)和狀態(tài)是一致的，因此從最近的一個(gè)checkpoint點(diǎn)開始恢復(fù)可以大大縮短整個(gè)系統(tǒng)的恢復(fù)時(shí)間。在本系統(tǒng)中，checkpoint后會生成新的log文件，checkpoint之后的系統(tǒng)恢復(fù)只需讀取新的文件即可，讀取log時(shí)間較短。系統(tǒng)做Checkpoint的時(shí)機(jī)主要是依據(jù)當(dāng)前內(nèi)存中(寫緩存)WriteBuffer的大小。當(dāng)TabletServer中總的寫緩存占用內(nèi)存過大時(shí)，TabletServer需要開始做Checkpoint, 即把內(nèi)存數(shù)據(jù)寫到TSFile中，并對log做相應(yīng)的處理。此過程中出現(xiàn)若失敗，由于Log的路徑?jīng)]有改變，不會影響到系統(tǒng)的一致性。做完Checkpoint后，需要把Tablet的元數(shù)據(jù)中的Log路徑修改成當(dāng)前的Log路徑。Checkpoint流程在Checkpoint的實(shí)現(xiàn)過程中，為了保證系統(tǒng)的正常服務(wù)，checkpoint實(shí)現(xiàn)的首要目標(biāo)是不阻塞正常的讀寫操作。這主要是通過兩個(gè)WriteBuffer的交替實(shí)現(xiàn)的。所謂兩個(gè)WriteBuffer的交替，是指Tablet的實(shí)現(xiàn)中，存在著兩個(gè)WriteBuffer的數(shù)據(jù)結(jié)構(gòu)。一個(gè)作為主WriteBuffer，可讀并且可寫；另一個(gè)作為備WriteBuffer，可讀不可寫。假設(shè)每個(gè)Tablet中的兩個(gè)WriteBuffer分別命名為BufferA、BufferB。假設(shè)初始時(shí)，BufferA是主WriteBuffer，接受寫入得數(shù)據(jù)，BufferB為備WriteBuffer，數(shù)據(jù)為空。在開始做checkpoint時(shí)，BufferA和BufferB的角色互換，BufferA被成為備WriteBuffer，只提供數(shù)據(jù)的讀取，不在接受數(shù)據(jù)的寫入；BufferB被設(shè)置為主WriteBuffer，接受寫入的數(shù)據(jù)。隨后的checkpoint過程中，BufferA被寫成TSFile。Checkpoint結(jié)束時(shí)，BufferA被清空，等待下一次checkpoint。詳細(xì)的流程如下：1. 系統(tǒng)中的后臺線程定期檢測內(nèi)存中WriteBuffer的大小，當(dāng)發(fā)現(xiàn)WriteBuffer過大(超過閾值)并且系統(tǒng)中沒有正在進(jìn)行的Split操作時(shí)，開始進(jìn)入Checkpoint流程。2. 在開始寫數(shù)據(jù)之前，checkpoint線程抓住系統(tǒng)的全局狀態(tài)鎖，把系統(tǒng)設(shè)置成只讀狀態(tài)(ReadOnly)。3. 設(shè)置完成后，遍歷各個(gè)Tablet的WriteBuffer，若不為空，進(jìn)行WriteBuffer的交替(見上所述)。4. 為系統(tǒng)生成新log的文件(詳情請見本節(jié)上文所述)。5. 將系統(tǒng)設(shè)置成可讀寫狀態(tài)，釋放全局狀態(tài)鎖。6. 將各個(gè)Tablet中備WriteBuffer存放的數(shù)據(jù)寫成TSFile，并上傳到TFS上。釋放各個(gè)Tablet中備WriteBuffer的內(nèi)存。7. 更改各個(gè)Tablet元數(shù)據(jù)，將log路徑域的值設(shè)置成當(dāng)前的log路徑。由上面的詳細(xì)流程可見，在2~5步時(shí)系統(tǒng)是不可寫的。但有因?yàn)?~5步的操作都是內(nèi)存中的簡單操作，因此這個(gè)不可寫的時(shí)間段非常之短。 緩存管理由于每個(gè)TabletServer的內(nèi)存資源是有限的，如何使用有限的內(nèi)存發(fā)揮最大的效應(yīng)是一個(gè)重要的問題。在TabletServer中，存在著兩種類型的緩存。寫緩存第一種類型是寫緩存(Write Buffer)，它在邏輯上是Tablet的一部分，用于存放新寫入的Tablet數(shù)據(jù)。Tablet在沒有做Checkpoint之前，所有新寫入的數(shù)據(jù)都被放在Write Buffer中，而TabletServer何時(shí)做Checkpoint是由其分配給Write Buffer的內(nèi)存上限決定的。若寫緩存上限過小，會導(dǎo)致系統(tǒng)頻繁地做Checkpoint，占用系統(tǒng)資源，嚴(yán)重時(shí)會影響到前臺的服務(wù)。若寫緩存上限過大，雖然Checkpoint得次數(shù)大為減少，但是又會帶來另一個(gè)嚴(yán)重的問題。由于Tablet在寫入數(shù)據(jù)時(shí)，首先要把數(shù)據(jù)寫入Log中，再放入緩存里，顯然當(dāng)前Log的大小是和寫緩存的大小相關(guān)。若寫緩存內(nèi)存過大，意味著Log文件很大，假設(shè)此時(shí)TabletServer節(jié)點(diǎn)出錯(cuò)而停止服務(wù)，這些Tablet將會被分配到其他TabletServer上。這些TabletServer在接收Tablet時(shí)，需要恢復(fù)Tablet對應(yīng)的內(nèi)存鏡像。由于Log文件是很多Tablet共用的，即使TabletServer只接受一個(gè)Tablet，它也需要把整個(gè)Log文件讀取一遍，已找到相應(yīng)的Tablet的Log。因此Log越大，這個(gè)恢復(fù)的過程就會越長。我們假設(shè)失效的TabletServer節(jié)點(diǎn)在失效前服務(wù)n個(gè)Tablet，Write Buffer占用的內(nèi)存大小為b，顯然Log文件的大小至少為b。該節(jié)點(diǎn)停止服務(wù)后，被Master分配到其它m(m=n)個(gè)節(jié)點(diǎn)上去，由于每個(gè)節(jié)點(diǎn)都會完整的掃描一遍Log文件，因此TFS的數(shù)據(jù)讀取總量為m*b，最壞情況下為n*b(Tablet被非配到n臺不同的機(jī)器上)。內(nèi)存空間b越大，則整個(gè)恢復(fù)的流程越慢。一種解決辦法是利用基于TFS的MapReduce平臺，用MapReduce任務(wù)將等待讀取的Log文件按照Tablet ID劃分開，使得每個(gè)Tablet ID對應(yīng)的Log成為一個(gè)獨(dú)立的文件。這樣被分配到Tablet的TabletServer只需要讀取對應(yīng)的Log小文件，減少了大量的冗余I/O操作，加速整個(gè)恢復(fù)流程。這將是未來工作的一部分。讀緩存另一種類型的緩存是讀緩存。所謂讀緩存是指緩存已被讀入內(nèi)存中的TSFile的內(nèi)容，緩存越大，則下次讀操作能在內(nèi)存中命中的概率也就越大。最好情況下，節(jié)點(diǎn)內(nèi)存較大并且數(shù)據(jù)量較小時(shí)，這時(shí)所有的TSFile都可以被加載到內(nèi)存中，從而最大限度的保證讀數(shù)據(jù)效率。但是實(shí)際運(yùn)行中TSFile的總大小遠(yuǎn)遠(yuǎn)大于內(nèi)存大小，因此給不同的Tablet合理的分配緩存是一個(gè)重要的問題。在實(shí)際使用中，不同的表格用途也不盡相同，有的表格純粹為了存儲數(shù)據(jù)，基本不需要緩存；有的表格是為了處理數(shù)據(jù)，那么只有當(dāng)這個(gè)表格在使用時(shí)才會用到緩存；還有些表格甚至是為了作為超級大的內(nèi)存Map內(nèi)使用，這種情況下要求使用的內(nèi)存最多。為了適應(yīng)這些不同性質(zhì)的表格，本系統(tǒng)中采取的辦法是讓Client可以在open方法中設(shè)置緩存的級別。具體來講是Client向Master設(shè)置表的優(yōu)先級，Master查詢該表對應(yīng)的所有Tablet，向管理這些Tablet的TabletServer設(shè)置優(yōu)先級。緩存的級別分三種，High、Medium、Low。默認(rèn)情況下表的緩存級別是Medium。當(dāng)讀緩存過大需要釋放內(nèi)存時(shí)，系統(tǒng)會優(yōu)先釋放優(yōu)先級較低的表對應(yīng)的Tablet。表的優(yōu)先級的設(shè)置是不會被作為元數(shù)據(jù)保存的，并且這個(gè)設(shè)置只作為參考，設(shè)置優(yōu)先級后的性能跟TabletServer當(dāng)時(shí)的負(fù)載狀態(tài)相關(guān)，對于緩存級別為High的表，系統(tǒng)并不保證讀操作的一個(gè)絕對性能提升。由于TSFile在讀取時(shí)是以塊為單位，在緩存的管理時(shí)同樣也以塊為單位進(jìn)行。 Tablet分裂當(dāng)一個(gè)Tablet的數(shù)據(jù)過多或者成為了熱點(diǎn)Tablet后，需要把這個(gè)Tablet分裂成兩個(gè)較小的Tablet以便加以調(diào)度。這個(gè)分裂的過程由TabletServer發(fā)起，但是必須要有Master的參與才能完成。整個(gè)分裂的流程如下：1. TabletServer通過后臺進(jìn)程監(jiān)控所有Tablet的大小，當(dāng)其發(fā)現(xiàn)某個(gè)Tablet過大時(shí)(超過一定的閾值)，進(jìn)入準(zhǔn)備分裂狀態(tài)。2. TabletServer同Master通信，告訴Master其想要分裂的Tablet ID，Master返回兩個(gè)新生成的ID。3. 拿到兩個(gè)新的Tablet ID后，掃描原Tablet確定從某個(gè)midkey分裂，從而確定這兩個(gè)Tablet的Range。4. 在TFS目錄/prefix/splitlog/下為這兩個(gè)ID分別建立兩個(gè)同名的日志文件。從此時(shí)開始，所有向待分裂Tablet的寫請求都會寫兩份日志，一份是原TabletServer的日志，另一份寫入相應(yīng)新生成的Tablet的日志，即 /prefix/splitlog/id(id為分裂后的Tablet的ID)。這是為了當(dāng)新生成的Tablet被分配到其他的節(jié)點(diǎn)上時(shí)，可以快速恢復(fù)在分裂的這段時(shí)間內(nèi)寫入的數(shù)據(jù)。5. TabletServer將待分裂的Tablet劃分成兩個(gè)TSFile，并上傳到后臺TFS上。注意，到此時(shí)為止，未改動(dòng)任何元數(shù)據(jù)和數(shù)據(jù)文件。6. 上傳完TSFile結(jié)束后，TabletServer向Master報(bào)告分裂完成，Master在Debby中增加這兩個(gè)新的Tablet的元信息，并刪除舊的Tablet信息。這個(gè)過程利用了Debby中提供的事務(wù)功能保證寫操作和刪除操作在一起的事務(wù)性。隨后，Master根據(jù)分配算法分配這兩個(gè)Tablet。至此，整個(gè)分裂的過程全部結(jié)束。在整個(gè)分裂的過程中，元數(shù)據(jù)和系統(tǒng)狀態(tài)的修改留到最后才進(jìn)行，并且由數(shù)據(jù)庫(Debby使用Berkeley DB)的事務(wù)性來保證這個(gè)修改的原子性和完整性，不會在Debby上出現(xiàn)元信息不一致的情況，比如新舊Tablet同時(shí)存在，或者新舊Tablet同時(shí)不存在。在最后一步修改元數(shù)據(jù)之前，任何錯(cuò)誤都可以忽略，只需等到該Tablet下次被檢測到需要分裂時(shí)重新執(zhí)行整個(gè)流程即可。若最后修改元數(shù)據(jù)出錯(cuò)，若Tablet的信息沒有被寫上，則和上述情況一樣；若Tablet信息已被寫上，則分裂已成功，Master恢復(fù)時(shí)只需分配這兩個(gè)Tablet。 客戶端(Client)接口與實(shí)現(xiàn)Bighive客戶端(Client)是以鏈接庫的形式提供給用戶程序使用。客戶端不僅為用戶提供整齊統(tǒng)一的接口，在內(nèi)部處理與Master，TabletServer以及Debby的交互，并進(jìn)行必要的錯(cuò)誤處理和重試工作。Client在第一次使用表時(shí)通過Master取得表對應(yīng)的所有Tablet的元數(shù)據(jù)，元數(shù)據(jù)中包括Tablet的Range和機(jī)器位置。當(dāng)需要操作數(shù)據(jù)時(shí)，Client直接與相應(yīng)的TabletServer通信操作數(shù)據(jù)。在這期間，對于Tablet元數(shù)據(jù)發(fā)生的變化(分裂或者Tablet遷移導(dǎo)致)，Cl