你是天選之人,開始了自己的互聯網生意。剛開始的時候,用一臺配置了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機了,只是網絡延遲較長。既然是基礎理念,那就意味著,我們還需要增加許多的細節來清晰化我們的算法設計。比如直流電穩定,交流電長距離傳輸損耗小。這也是基礎理念,如何讓燈泡亮起來,不管是交流電還是直流電,我們都因該關注電機怎麼設計得更好。
在接下來的系列文章中,我們將會讓迷霧中的分佈系,一步步變得清晰、完整和鮮活起來。
全文完