不要使用多級提交協議存儲或處理事務。不要使用它。分段數據存儲和處理系統由Y軸或Z軸除外。申請原因：多級提交協議是一個封鎖建議，在完成其他其他事務之前無法執行。不要將多個階段與外國人整體數據庫生活的簡單方式。它可能降低可擴展性，甚至早些時候甚至最終結束了系統的生命。

　　多級提交協議是專門的共識協議。常見是一個兩階段提交協議（2PC）和三階段提交協議（3PC）。這些共識[開發網站公司]討論的目的是協調參與分布式原子事務的過程。決定提交或終止（回滾）。由于這些算法可以處理整體系統網絡或流程故障，因此因此，它們通常被視為分布式數據存儲或處理解決方案。

　　網站托管代運營2pc的基本算法由兩個階段組成。第一階段是投票的階段，那是， 主存儲設備或協調程序將“提交請求”發起給所有參與者或其他存儲設備。在犯下之前，所有參與者都有處理交易。提交后， 參與者將通知主存儲或協調程序。 他們可以提交。或投票給票。這可以啟動第二階段，完成階段，主存儲設備向所有參與者發送提交信號。參與者已開始提交數據。只要有參與者的提交失敗，返回信號將發送給所有參與者，交易將被終止。

　　迄今為止，協議聽起來相當不錯，分布式數據庫環境中交易的原子性[公司網站設計]。不要這么早結論。它在步驟A中啟動了交易。因此，在通知主數據庫之前，通知應用程序服務器事務（步驟c），所有2PC步驟都已完成（步驟b）。在整個過程中，應用程序服務器上的線程必須等待SQL查詢結束，數據庫響應此事務。這個例子很常見，幾乎所有用戶都在網絡上購買， 注冊或招標交易，它可以用2pc實現。但，保持應用服務器這么長時間。會特定軟件開發推廣造成可怕的后果。即使您可能認為您的應用程序服務器容量足夠，或者應用程序服務器是商業硬件，您可以以較低的成本擴展它們，然而， 考慮在數據庫中鎖定相同的情況。執行提交時，假設您使用一條線路鎖，然后在提交所有數據之前，所有數據行都被鎖定。如果您使用塊鎖，因此， 我們廣泛實現了2PC協議。結果是災難性的，這應該完全省略該方法的鎖定和等待特性。在實現2PC協議之前，數據庫可以處理數千個讀取操作和每秒寫入操作。[企業官方網站生產]一小部分（不到20％）， 它吸引了2pc，整個網站只能處理前一個1/4。即使我們可以添加更多應用程序服務器，但是因為數據被鎖定，網站施工數據庫無法處理更多查詢。雖然2PC協議看起來像劃分比Y軸劃分或半軸更好的分割數據庫的方法，但經過仔細考慮， 你會發現很多問題。使用更好的方法來拆分數據庫表，而不是使用多級提交協議來擴展單個數據庫的生命。