你是天選之人，開始了自己的互聯網生意。剛開始的時候，用一臺配置了1024 (1 vCPU)，2048 (2GB)內存的服務器來提供服務，剛剛好。但因為你是天選之人，你的生意蒸蒸日上，越來越多的人開始使用你提供的互聯網服務，這時候你升級了服務器到4096 (4 vCPU)，30720 (30GB)。但因為你是天選之人，很快，這樣的服務器已經滿足不了你的需求了，那麼你再次進行了升級...
無限服務
我們發現，以目前（這個還不知道要持續多久）的計算機基礎設施，沒法用有限的資源來滿足我們無限的慾望。精兵戰術當然有用，這也是很多人喜歡海軍陸戰隊，因為這個稱號意味著超強的個人能力。但光桿司令的時間和精力畢竟是有限的，如果我們想要成就一番偉業，就得發動群眾，打造你的不朽軍團，號令群雄，王者歸來。
為了給我們的越來越多的顧客提供服務，我們需要設計一套方案，以達到分工協作，清除瓶頸的目的。
那麼我們又可以再一次站在巨人肩膀上面了。
二階提交 - two-phase commit
XA(eXtended Architecture)標準，是由X/Open組織，在將近30年前，1991年發佈的一份說明。後來X/Open牽手The Open Group，從此一起開心的研究DTP(distributed transaction processing)。
獨立系統裡，如果想要保證事務的連貫和可靠，上一篇頭條說有說明 -「分佈式」基礎 - ACID。那麼二階提交，就是為了保證分佈式系統的原子性，保證同一事務，在多副本(repication)系統裡裡，要麼都執行，要麼都回滾，步調一致，整整齊齊。
那麼，巨人們是怎麼做到的呢？
二階段提交
可以看出，所有的參與者(Participants)，都需要通過協調者(Coordinator)發佈的指令，來統一步調。
- 協調者：兄弟姐妹們都準備好了嗎，let's party？
- 參與者：準備好了/不，我先上個廁所，再等我一會
- 協調者：上廁所的回來了，狂歡開始/接到消息，今晚狂歡取消，大家都散了吧
- 參與者：狂歡中（左右互搏）...， 這個時候接不了電話。狂歡結束，通知協調者，我high完了
二階提交確實解決了原子性的問題，大家步調一致，要麼一起high，要麼一起撤。但也有一個關鍵問題，會鎖定處理中的資源，其它的事務都只能等著處理完。如上例中，左右互搏過程中，雙手都很忙，那麼假設雙手就是資源，如果有電話來了，我是接不了的，需要我的雙手互相認可後，才能接聽電話。如果不巧協調者down機了，那麼被鎖的資源將會一直得不到釋放，很可能引起蝴蝶效應。
計算機發展短短數十載，進步神速，是因為吸引了很多優秀的人才，針對上面資源鎖的問題，又有人提出了改進方案，三階提交：
三階段提交
相對二階提交，三階提交多了個步預提交，並引入超時機制。
預提交(PreCommit)：讓事務的處理處於中間狀態，也就是將undo和redo都寫入事務系統，把能做的事情提前做好，為提交做好充分準備，但又沒有真正提交
超時機制：預提交階段的引入，保證了各參與者都已經做好充分準備。超時機制的好處是，就算這個時候協調者down機了，超時後，參與者都會樂觀的的認為，沒有消息就是最好的消息，繼續提交。那麼解決了資源一直被鎖的問題。
不管是二階提交還是三階提交，都只是基礎理念，都會存在需要加強鞏固的地方。比如：
- 都有單點依賴的問題，那麼這個協調者就是實實在在的瓶頸。
- 都需要所有的參與者共同響應，組織協調的成本很大
- 很可能出現數據不連貫的問題，比如，commit的過程中，有的小夥伴就是遲遲沒法回覆，可能並不是down機了，只是網絡延遲較長。
既然是基礎理念，那就意味著，我們還需要增加許多的細節來清晰化我們的算法設計。比如直流電穩定，交流電長距離傳輸損耗小。這也是基礎理念，如何讓燈泡亮起來，不管是交流電還是直流電，我們都因該關注電機怎麼設計得更好。
在接下來的系列文章中，我們將會讓迷霧中的分佈系，一步步變得清晰、完整和鮮活起來。
全文完
