PAOXS協議

自己原文公眾號：

https://mp.weixin.qq.com/s/wsh1JwBv5uA3eDJzP4evBw

這幾天深入學習一下。這個分散式系統的一個協議。分散式系統顧名思義就是要分。但是分散式又要保證在分的情況下還要一致。這個就難了，如果不考慮一致，隨便。

保持資料同步的一種方法是在多個節點上同時更新資料。如果我有3臺機器做一個分散式系統。我只寫第一個（一隻羊薅羊毛）。那麼另外兩個把這些資料一次映象過去就結束了。這個難度相對較小。所以MySQL的MGR不少都是單主模式。

但是如果每個點寫入就難度大了。需要有一個協調者，但是協調者就一個如果處理不過來或者壞了怎麼辦？所以要多個協調者。

有了多個協調者問題解決了嗎？其實問題更大了。當有一塊表我們知道時間，當有兩塊表我們不知道時間。有的人會說選出一個leader。可以。但是這是leader flower模式，就像主從。我們說的是並行寫入。Oracle的RAC是叢集，而ADG就不是。因為ADG的DG是不可以寫的。當然Oracle19C開始可以寫了。那是表面。其背後原理是從庫接受寫的請求，但是不馬上直接，給主庫送過去，主庫執行了，再給從庫。這才能保證一致性性。否則直接寫從庫就不一致了。所以目前RAC的這個架構還沒有能打破。

那麼當1 2 3號機器一起被寫，如何處理。假如有個值它是10，在1號機上把它改成3 ，在2號機上改成5.那麼最後看到的是幾？3or5？這取決於執行的順序。如果是先3，那麼結果是5，如果是先5那麼結果是3.因為一個機器處理完畢要送給其他機器。後面覆蓋前面的。

要想一致只有一個辦法，每個機器接收到指令然後進行全域性的協調排序。這裡注意一下當多個分發器以後我們不能保證順序。訊息佇列的寫入順序一定是讀取順序嗎？問題越來越難解決了。

解決方案是設定鎖，然後排序。天啊，多少人單機的鎖都沒搞定，現在又是多協調鎖。這就是我們聽過的分散式鎖。有了鎖，那麼就有死鎖。（鎖等待還好辦一些）設定優先順序（你看又多了一個環節），單機的死鎖有人都跨不過去。這回鎖又多了，又複雜了。

所以我一直說單機是最好的架構。（考慮高可用容災的話，做叢集或者主從）單機沒有這些問題。

那有人說單機數量量大處理不了怎麼辦？答案見我上一篇公眾號。

除了大廠的資料量以外，我們一般的系統如果說單機資料量大處理不了。那麼放心、叢集的也處理不了。多花一些精力在資料庫設計和邏輯實現上吧。