分布式雜談

分布式模型的理念自計算機誕生之日就已經出現。然而計算機發展初期，由于設備數量稀少且價格昂貴，再加上摩爾定律的影響，與其實現一套復雜的分布式架構系統，直接提升單臺機器的硬件性能要更加簡單可行得多。由此導致的現象就是上世紀40到80年代之間，計算機行業一直被大型機所主導。

分布式編程，經過多年的演變，計算機硬件發展遭遇瓶頸，通過分布式架構來水平提升計算能力成為主流。今天，借助已有的開源技術，你可以非常容易搭建起屬于自己的分布式服務，大大降低了分布式應用開發的門檻；另一方面，近幾年微服務理念的興起掀起了新一輪的技術熱潮。

根據平臺和技術框架的不同，分布式開發的具體實現會存在差異，不過各自的架構理念以及技術原理仍是大同小異，連集成度極高的大型主機平臺，也早在1990年就提出了sysplex集群技術。

什么是分布式開發，以Web系統為例，一套完整的分布式系統通常包含以下幾個組件：

1. 負載均衡服務器
2. 應用服務器組
3. 緩存集群
4. 消息隊列
5. 數據庫集群
6. 文件服務器集群
   

與單機應用開發相比，分布式系統的邏輯結構幾乎沒有變化，依然是分應用服務、緩存、數據庫、文件系統等各個模塊，不同的是各個邏輯模塊內部以多節點形式構成，模塊間交互依然認為彼此是一個完整的個體，遵循高內聚低耦合的理念。
對于分布式開發人員來說，大部分情況下編寫代碼并不需要關注分布式架構的具體細節，模塊已經屏蔽了底層細節只保留接口，而接口通常是架構無關的。因此，如果把開發單機應用的邏輯套用在分布式開發過程中，編譯器并不會報錯，單機調試也大概率無異常，但最后把代碼部署到分布式環境中執行時，往往會出現意料之外的問題。架構差異帶來的影響，編譯器還不能幫我們發現并排除，更多需要依靠的程序設計規劃來解決。

分布式開發常見的問題主要有以下幾種：

1. 鎖問題
   分布式環境下，除線程同步、進程同步外，還額外增加了服務器同步的考慮。常見的臨界區、信號量等技術手段只能限制本機程序，當程序跑在不同的機器上時，彼此便失去了關聯。
2. 事務問題
   寫數據庫時，我們知道為了保證一致性，可以打開一個事務進行提交，確保事務內的修改動作要么全執行，要么全回退。但如果A機器的事務執行過程中調用了B機器的服務，在A機器回滾事務時，如何讓B機器也跟著一起撤銷修改。
3. 全局序列問題
   A機器在12:00:01時刻寫了一條日志到本地，假定同時刻B機器也寫了一條本地日志。日志歸并階段，應該怎么判斷A的日志順序在前還是B的日志？需要有一個全局的序列號發生器確保順序性以及唯一性，類似的還有時鐘同步問題。
4. session同步問題
   系統將用戶甲的請求分配給了A機器，一番操作后留下了一批session信息。不巧A機器故障了，用戶甲請求改分配到了B機器，B機器怎么知道用戶剛剛操作了什么內容？
5. 負載均衡問題
   通常我們希望用戶甲的請求被一旦分派給了機器A，后續用戶甲的請求都交給機器A來處理。但假定各個用戶請求都成功分派給了已有機器，這時候再在集群新加入一臺機器，會出現沒有請求進入新節點的情況。
6. CAP取舍：
   CAP理論說明一致性、可用性、分區容錯性三者不能同時兼備，而C、A、P三者孰優孰劣沒有統一標準，分布式開發過程必須有所取舍，如何權衡則需要自行考慮。

分布式鎖的一些思考

對公共資源加鎖會限制系統并發，如同將寬敞的多車道高速路合并成單車道，容易引發擁堵。因此能夠不加鎖解決的的問題，我們都盡量避免加鎖。

以緩存操作為例，我們通常通過以下方法避免加鎖：

場景一：查詢時緩存命中
緩存命中，直接返回緩存數據

場景二：查詢時緩存擊穿
緩存發生擊穿，此時需要訪問數據庫取得請求結果，寫入緩存后返回

場景三：更新操作
數據發生更新時，先更新數據庫值，其次直接刪除舊緩存，返回操作結果

更新場景下不直接修改緩存，而是將緩存刪除，讓后續查詢請求發生緩存擊穿，并進而更新緩存，這樣做法的好處是保證了緩存內容和數據庫內容的最終一致性。如果將刪除緩存動作調整為更新緩存，當數據更新和緩存擊穿同時發生時，有可能緩存擊穿查詢到的是修改前的臟數據，而回寫存時緩存擊穿寫入在后，導致最后緩存內容和數據庫值不一致。

對于復雜的業務場景，緩存加鎖不可避免。正如上面提到的，普通的進程同步機制無法控制跨服務器進程，這時需要引入分布式鎖的概念。分布式鎖同樣是實現公共資源的互斥訪問，主要的區別是它將控制范圍從單機擴展到了集群。

以常見的“秒殺”活動為例，看看分布式鎖如何發揮作用。
場景四：商品秒殺

1. 接收商品請求后，首先檢查當前庫存量；
2. 若庫存量滿足，首先嘗試獲取分布式鎖，表明要對庫存進行調整；
3. 鎖定成功，則更新數據庫以及緩存庫存，最后釋放鎖；
4. 鎖定失敗，則說明秒殺失敗；

加入分布式鎖后，秒殺活動帶來的流量壓力轉移到了緩存讀取以及分布式鎖的排隊請求中，避免了海量更新請求直接落到數據庫層。

在目前主流的分布式框架中并沒有直接提供分布式鎖的接口，相比之下分布式鎖更接近一種邏輯概念，由開發人員自行設計實現。常見的分布式鎖方案基于redis或Zookeeper實現，也有基于數據庫的設計。

結尾

這幾年來微服務的興起和容器技術的發展，讓分布式理念愈加滲透到各個領域。不過不管技術如何演變，任何時候拋開量級談設計都是不靠譜的行為，單機設計不一定就比分布式要差，選擇合適的才是最優解。

作者：阮偉聰