分布式本質上不過是將多個單機服務組合在一起對外提供服務
1、客戶端
當 rpc 服務部署在多個節點上時，客戶端得到的是乙個服務列表，有多個 ip 埠對。客戶端的連線池可以隨機地挑選任意的 rpc 服務節點進行連線，每個服務節點應該有個權重值，當所有節點的權重值一樣時，它們的流量分配就是均勻的。如果某個節點的相對權重值較小，它被客戶端選中的概率也會相對比較小。
2、容災failover
當有乙個服務節點掛掉時，客戶端需要採取一定的策略避免請求失敗。當請求失敗時，客戶端還要進行重試，但是也不可以無限重試，要有一定的重試策略。比如當節點掛掉時，將失效節點摘除，放置到失效節點列表中。然後每隔一段時間檢查失效節點是否恢復了，如果恢復了，那就從失效節點中移除，再將節點位址重新加入到有效節點列表中。那如何判斷節點真的掛掉了呢，一般需要設定乙個時間視窗，統計在一定時間視窗裡出現的錯誤數量。如果這個數量過大，那就意味著失效了。這也是為了防止網路偶然抖動導致服務節點流量的大幅波動。
3、降權法
上面提到客戶端會為每個節點賦予乙個權值，改變權值就可以改變節點的相對流量。如果某個節點出現了一次呼叫錯誤，可以對該節點進行降權。如果錯誤次數過多，降權會降的很快，最終達到乙個最小值。之所以不應該降到零，那是為了給節點提供乙個恢復的機會。被降權的節點後來只要有一次呼叫成功，那麼 weight 值就應該盡快被還原，這樣節點就可以快速恢復為正常節點。
客戶端一次呼叫失敗會嘗試重試。如果降權太慢，會導致重試次數太多，因為第二次隨機挑選節點時還是很有可能再次挑選到失效節點。降權太快也不好，網路抖動會導致節點流量分配的快速抖動，瞬間從正常降到近零，又可以瞬間從近零恢復到正常。
乙個簡單的策略是權重減半法。錯誤一次權重減半，連續錯誤兩次權重就降到 1/4，如此直到降到最小值。如果初始權重值是 1024，那麼權重值就會逐漸衰減1024=>512=>256=>128=>64=>32=>16=>8=>4=>2=>1。如果節點恢復了，那麼呼叫會成功，權重就可以直接恢復到正常值，也可以通過加倍法逐漸恢復到正常值1=>2=>4=>8=>16=>32=>64=>128=>256=>512=>1024。如果希望恢復的更快一點，可以通過乘 4 法，乘 8 法。
4、服務發現
健壯的服務應該是可以支援動態擴容的服務。比如 rpc 服務壓力過大，希望通過增加節點的方式來減小單個 rpc 服務的壓力。如果使用的是前面的靜態 rpc 服務位址列表，那麼當節點增加時，我們需要修改客戶端的配置重啟才能生效。通過服務發現技術，當 rpc 服務節點增加或減少時，客戶端可以動態快速收到服務列表的變更資訊，從而可以實時調整連線配置，這樣無需重啟就可以完成服務的擴容和縮容
服務發現技術依賴於服務之間的特殊中間節點。這個節點的作用就是接受服務的註冊，提供服務的查詢，以及服務列表變更的實時通知功能。它一般使用支援高可用的分布式配置資料庫作為解決方案，如 zookeeper/etcd 等。
服務註冊——服務節點在啟動時將自己的服務位址註冊到中間節點
服務查詢——客戶端啟動時去中間節點查詢服務位址列表
服務變更通知——客戶端在中間節點上訂閱依賴服務列表的變更事件。當依賴的服務列表變更時，中間節點負責將變更資訊實時通知給客戶端
原 Storm分布式RPC
分布式 rpc drpc 的設計目標是充分利用 storm 的計算能力實現高密度的並行實時計算。storm 接收若干個函式引數作為輸入流，然後通過 drpc 輸出這些函式呼叫的結果。嚴格來說，drpc 並不能算作是 storm 的乙個特性，因為它只是一種基於 storm 原語 stream spou...
分布式儲存原理
當hdfs集群啟動之時，datanode會向namenode傳送資訊，包括block儲存位置，datanode位址。client向namenode匯報當前上傳檔案的資訊 block數量 檔案上傳時間 檔案許可權 擁有著 2.1client將大檔案切割成乙個個的block塊 以字元為單位進行切割 cl...
Scrapy分布式原理
首先我們先看一下scrapy的單機架構 也就是說scrapy的單機架構實際上實在本機維護乙個爬取佇列，用scheduler進行排程，如果我們要實現scarpy的分布式，就需要多台主機協同操作，那麼問題來了 實際上就是共享爬取佇列 核心就是將這個佇列進行共享，讓多台主機都能訪問，然後讓各個主機的sch...