多階段提交協(xié)議是專用的共識協(xié)議,其中常見的是兩階段提交協(xié)議(2PC)和三階段提交協(xié)議(3PC)。這些協(xié)議的目的是協(xié)調(diào)參與分布式原子事務的進程,決定是提交還是終止(回退)事務。由于這些算法能夠處理整個系統(tǒng)網(wǎng)絡(luò)或進程方面的故障,所以它們常被當作分布式數(shù)據(jù)存儲或處理的解決方案。
2PC的基礎(chǔ)算法由兩個階段構(gòu)成。第一個階段是表決階段,即主存儲設(shè)備或協(xié)調(diào)程序向所有參與者或其他存儲設(shè)備發(fā)起“提交請求”。在提交前,所有參與者都處理事務,提交后參與者會告知主存儲或協(xié)調(diào)程序它們能夠提交了,或者投贊成票了。這就可以開始第二階段了,即完成階段,主存儲設(shè)備給所有參與者發(fā)送提交信號,參與者們開始提交數(shù)據(jù)。只要有參與者提交失敗,回退信號就會發(fā)送給所有參與者,事務將被終止。
到目前為止,該協(xié)議聽起來相當不錯,因為在分布式數(shù)據(jù)庫環(huán)境中提供了事務的原子性。暫且不要這么早下結(jié)論。它在步驟A中發(fā)起了事務。那么在主數(shù)據(jù)庫告知應用服務器事務完成(步驟C)前,所有的2PC步驟都要完成(步驟B)。在整個過程中,應用服務器上的線程都要等待SQL查詢結(jié)束,且數(shù)據(jù)庫響應了這一事務。這一示例非常常見,網(wǎng)絡(luò)上幾乎所有的用戶購買、注冊或競價的事務,都可能用2PC實現(xiàn)。但是,把應用服務器鎖住那么久,會造成可怕的后果。即使你可能認為自己的應用服務器還有充足的容量,或者由于應用服務器是商用硬件,可以用較低的成本擴展它們,但還要考慮鎖定同樣會發(fā)生在數(shù)據(jù)庫端。在執(zhí)行提交操作時,假設(shè)你采用的是行鎖,那么在所有數(shù)據(jù)提交完之前,所有的數(shù)據(jù)行都會被鎖住。如果采用的是塊鎖,結(jié)果會更糟我們已經(jīng)大范圍地實現(xiàn)了2PC協(xié)議,結(jié)果是災難性的,這要完全歸昝于該方法的鎖定和等待特性。在實現(xiàn)2PC協(xié)議前,數(shù)據(jù)庫最初每秒可以處理幾千個讀操作和寫操作。在一小部分(少于20%)調(diào)用中引人了2PC后,整個站點能處理的事務量只有以前的1/4。即使我們能增加更多的應用服務器,但由于數(shù)據(jù)被鎖定了,網(wǎng)站建設(shè)數(shù)據(jù)庫也不能處理更多的查詢。雖然2PC協(xié)議看起來是個比Y軸劃分或乙軸劃分更好的分割數(shù)據(jù)庫的方法,但仔細考慮后就會發(fā)現(xiàn)很多問題。要用更好的辦法拆分數(shù)據(jù)庫表,而不是用多階段提交協(xié)議延長單一數(shù)據(jù)庫的生命。
本文地址:http://www.khwajamoinuddinchishty.com//article/3498.html