聊聊分散式

03-12

1、分散式概述

分散式的定義在百度一搜有一堆，這裡就不複製了，分散式是一個很大的概念，它的本質是什麼呢？不同的人對分散式下的定義描述不一樣，但在本質上是相同的，分散式的本質是：拆分+連接。這次從拆分角度來聊聊自己的一點感想。

2、拆分產生的一致性問題

拆分是將一個大的業務邏輯拆分成多個獨立的子業務邏輯，每個子業務邏輯又可以獨立部署在多台機器上(冗餘，冗餘可以做負載勻衡，提升可靠性)，這樣一來就產生了一致性問題(更新一個節點的數據，其它的節點點還沒有更新)，其實一致性問題由來已久，經典的CAP理倫由此展示：

C：一致性，這裡指的是強一致性；

A：可用性，在單位時間內要響應；

P: 分區容錯性，部分節點失敗不影響整體。

在分散式中分區容錯性是必須的，一般在一致性和可用性之間進行選擇。後來人們發現選擇一個事物不再是"是"和"不是"的離散選擇，而是一個連續區間的選擇，如可用，是10%可用，還是50%可用，還是100%可用。所以基本這樣的考慮，又有BASE理倫出來了，它提出了最終一致性的思想，這個特別有意思，在很多問題中，它具有極強的指導思想和意義。

那麼一致性怎麼解決呢？很自然的想到了兩種：

1）強一致性：等所有的節點都完成之後，再做下一步操作；

2）最終一致性：這裡又有兩種實現方式：

a. 大部分成功，剩下的慢慢同步；

b. 一個成功，然後通知剩下的進行同步(為了安全起見，還會每隔一段時間進行全量dump操作)。

這裡以最終一致性為例討論實現方案，一種以master接受寫的思路，另一種是節點完全對等的思路。第一種思路以Zookeeper為代表，後面一種是以Diamond為代表。說一下自己的感受：

1) 節點失敗沒有想像的那麼多，失敗了並不可怕；

2）分散式要注重重試、冪等、沖正(回滾)操作。

3、拆分產生的分散式事務

分散式事務是一個非常頭痛的問題，因為在目前互聯網技術中，只有少數的幾家做出自己的分散式事務框架，對外沒有開源，傳統的分散式事務處理適合小型數據量處理，一到高並發的場景並不實用，所以看到大的公司一般都是自己研發分散式事務框架。

要想分散式事務處理框架，有以下幾種：

1) 傳統二階段處理：prepare和commit，JTA為代表，所以的操作先進行prepare，全部通過後再統一做commit；

2）日誌+補償處理：其實資料庫給了我們一個很好的提示，有redo和undo日誌，依據它們可以做重試和回滾操作，所以上面說了分散式中節點失敗不可怕。在做每個子事務之前先寫日誌，成功了刪除日誌，失敗了做回滾操作。

網上還有基於消息來實現分散式事務的，大家也可以考慮下。

4、結語

目前在講分散式是一個公司從小到大發展進程中一定會遇到的，從集中型轉分散式，一定會遇到各種各樣的挑戰。最近結合自己幾年的經驗和接觸到的一些框架，總結分散式相關的內容，如分散式配置中心、分散式任務調度、分散式事務、分庫分表、分散式消息中間件、分散式數據複製技術、分散式調用跟蹤和全鏈路壓測，這一整套構成了完整體系的中間件技術(當然還有更多其它的技術體系)，自己花了大量的時間進行思考和實踐，對其中的關鍵實現原理有自己的解決思路，後續一一和大家分享，也歡迎技術愛好者與我一起交流討論，可以加我的手機微信13512717641。