percolator的事務實現依賴乙個全域性的時間戳服務來生成嚴格遞增的時間戳，因為每個事務需要連線時間戳服務2次,這個服務必需能夠很好的擴充套件. 這個預報服務通過寫乙個最高可分配的時間戳到持久儲存中週期性的分派乙個範圍的時間戳段;給乙個已分配時間戳段,那麼預報服務能夠在記憶體中嚴格按增量給請求分配時間戳（譯者：現在看來，這個時間戳服務是單機的。）.如果預報服務重啟,時間戳將會跳到最大的已分配時間戳(我們不會讓時間戳往後退).為了減少rpc請求(在事務延遲時間不斷增長下)每個percolator worker在跨事務的場景下通過維持乙個預先準備的預報服務的rpc請求批量提交時間戳請求.隨著預報服務壓力越來越大,批量請求能夠自然地彌補這種壓力.批量請求時間戳讓預報服務的擴充套件性得到了很好的提公升,並且並不影響預報服務對分配的時間戳的保證(嚴格遞增).我們的預報服務單台機器每秒提供大約2百萬個的時間戳.
事務協議使用嚴格遞增的時間戳來保證get()操作返回該事務開始時間之前所有的已提交的寫.讓我們來看看它是如何提供這種保證的, 假如乙個事務r在tr時間戳進行讀並且事務w 在tw(
percolator有乙個通知機制，作用是最原始的資料發生變化後自動通知使用者**執行後續的操作，包括事務，所有使用者寫的觀察者**會被打成乙個二進位製包,然後讓其在系統中的每乙個tablet伺服器上單獨執行.每乙個觀察者註冊了乙個方法和幾個column在percolator中,percolator會在任何行的這些列(任意乙個)寫入資料後觸發這些方法.
percolator的應用被組織成了一系列觀察者;每個觀察者完成乙個任務並且通過向表寫資料的方式建立更多的工作給接下去的觀察者.在我們的索引系統中,乙個mapreduce任務通過執行裝載器的事務(loader transactions)裝載爬取過來的文件到percolator中,而這個行為觸發了後續對文件進行索引的一系列文件處理事務(解析,分解連線,等等).而文件處理事務又會觸發經一步的集群事務.集群事務,後續又會觸發匯出變化了的文件到服務系統中的事務.
通知和資料庫的觸發器相似.但是與資料庫觸發器不同的是,他們不能用來維護資料庫的資料完整性.因為觸發的觀察者是從乙個觸發的寫操作中執行乙個獨立的事務,所以觸發的寫操作和被觸發的觀察者寫操作不是原子的.通知旨在幫助構建乙個增量的計算而不是用來維護資料的完整性.
相對於複雜語義的重疊觸發.這種語義和意圖的不同使觀察者行為更加容易被理解.percolator應用由少量觀察者組成----google的索引系統大約有10個觀察者.每個觀察者明確地在worker的main()函式的中構建.所以worker是知道哪些觀察者是活躍的.幾個觀察者一起觀察同乙個column是可行的,但是我們避免了這個特性,所以我們很清除哪個觀察者會在乙個特殊的column被寫入後執行.使用者需要擔心一下通知的無限迴圈,percolator不會阻止這種事情;使用者會通過構建一系列觀察者的典型結構來避免無限迴圈.
摘自 bucketli
Percolator 中的分布式事務
percolator 對外提供兩個主要的功能,乙個是分布式事務,另外乙個是 observers,這裡簡單介紹一下 percolator 中分布式事務的實現方法.以下內容都出自對 google large scale incremental processing using distributed t...
TransactionScope 分布式事務
transactionscope是.net framework 2.0滯後，新增了乙個命名空間。它的用途是為資料庫訪問提供了乙個 輕量級 區別於 sqltransaction 的事物。使用之前必須新增對 system.transactions.dll 的引用。下列 就是乙個正在建立的事務，這個事務自...
TransactionScope 分布式事務配置
1 先新增system.transactions的引用 需要新增net程式集 c 呼叫時的 如下 using system.transactions using transactionscope scope new transactionscope 2 設定web伺服器及sql伺服器環境配置 控制面...