不要使用多階段提交協(xié)議存儲或處理事務(wù)。不要使用它。用Y軸或Z軸劃分分割數據存儲和處理系統。應用理由:多階段提交協(xié)議是一種阻斷提議，在它完成之前，其他事務(wù)不能執行。不要將多階段提交協(xié)議作為廷長(cháng)整體數據庫生命的簡(jiǎn)單方式。它很可能降低擴展性，甚至更早地終止系統的壽命。

多階段提交協(xié)議是專(zhuān)用的共識協(xié)議，其中常見(jiàn)的是兩階段提交協(xié)議(2PC)和三階段提交協(xié)議(3PC)。這些協(xié)議的目的是協(xié)調參與分布式原子事務(wù)的進(jìn)程，決定是提交還是終止(回退)事務(wù)。由于這些算法能夠處理整個(gè)系統網(wǎng)絡(luò )或進(jìn)程方面的故障，所以它們常被當作分布式數據存儲或處理的解決方案。



2PC的基礎算法由兩個(gè)階段構成。第一個(gè)階段是表決階段，即主存儲設備或協(xié)調程序向所有參與者或其他存儲設備發(fā)起“提交請求”。在提交前，所有參與者都處理事務(wù)，提交后參與者會(huì )告知主存儲或協(xié)調程序它們能夠提交了，或者投贊成票了。這就可以開(kāi)始第二階段了，即完成階段，主存儲設備給所有參與者發(fā)送提交信號，參與者們開(kāi)始提交數據。只要有參與者提交失敗，回退信號就會(huì )發(fā)送給所有參與者，事務(wù)將被終止。

到目前為止，該協(xié)議聽(tīng)起來(lái)相當不錯，因為在分布式數據庫環(huán)境中提供了事務(wù)的原子性。暫且不要這么早下結論。它在步驟A中發(fā)起了事務(wù)。那么在主數據庫告知應用服務(wù)器事務(wù)完成(步驟C)前，所有的2PC步驟都要完成(步驟B)。在整個(gè)過(guò)程中，應用服務(wù)器上的線(xiàn)程都要等待SQL查詢(xún)結束，且數據庫響應了這一事務(wù)。這一示例非常常見(jiàn)，網(wǎng)絡(luò )上幾乎所有的用戶(hù)購買(mǎi)、注冊或競價(jià)的事務(wù)，都可能用2PC實(shí)現。但是，把應用服務(wù)器鎖住那么久，會(huì )造成可怕的后果。即使你可能認為自己的應用服務(wù)器還有充足的容量，或者由于應用服務(wù)器是商用硬件，可以用較低的成本擴展它們，但還要考慮鎖定同樣會(huì )發(fā)生在數據庫端。在執行提交操作時(shí)，假設你采用的是行鎖，那么在所有數據提交完之前，所有的數據行都會(huì )被鎖住。如果采用的是塊鎖，結果會(huì )更糟我們已經(jīng)大范圍地實(shí)現了2PC協(xié)議，結果是災難性的，這要完全歸昝于該方法的鎖定和等待特性。在實(shí)現2PC協(xié)議前，數據庫最初每秒可以處理幾千個(gè)讀操作和寫(xiě)操作。在一小部分(少于20%)調用中引人了2PC后，整個(gè)站點(diǎn)能處理的事務(wù)量只有以前的1/4。即使我們能增加更多的應用服務(wù)器，但由于數據被鎖定了，網(wǎng)站建設數據庫也不能處理更多的查詢(xún)。雖然2PC協(xié)議看起來(lái)是個(gè)比Y軸劃分或乙軸劃分更好的分割數據庫的方法，但仔細考慮后就會(huì )發(fā)現很多問(wèn)題。要用更好的辦法拆分數據庫表，而不是用多階段提交協(xié)議延長(cháng)單一數據庫的生命。