平時接觸到的分布式系統有很多種，比如分布式檔案系統，分布式資料庫，分布式webservice，分布式計算等等，面向的情景不同，但分布式的思路是否是一樣的呢?
1.簡單的例子
另乙個栗子，我們現在有兩個資料請求，資料1 90萬，資料2 80萬，上面那台機器也hold不住，我們加一台機器來負載均衡一下，每台機器處理45萬資料1和40萬資料2，但是平分太麻煩，不如一台處理資料1，一台處理資料2，同樣能解決問題，這種方式我們稱之為垂直拆分。
水平擴充套件和垂直拆分是分布式架構的兩種思路，但並不是乙個二選一的問題，更多的是兼併合用。下面介紹乙個實際的場景。這也是許多網際網路的公司架構思路。
2.實際的例子
我此時所在的公司的計算機系統很龐大，自然是乙個整的分布式系統，為了方便組織管理，公司將整個技術部按業務和平台拆分為部門，訂單的，會員的，商家的等等，每個部門有自己的web伺服器集群，資料庫伺服器集群，通過同乙個**訪問的鏈結可能來自於不同的伺服器和資料庫，對**及底層對資料庫的訪問被分配到了不同的伺服器集群,這個便是典型的按業務做的垂直拆分，每個部門的伺服器在hold不住時，會有彈性的擴充套件，這便是水平擴充套件。
在資料庫層，有些表非常大，資料量在億級，如果只是純粹的水平的擴充套件並不一定最好，如果對錶進行拆分，比如可以按使用者id進行水平拆表，通過對id取模的方式，將使用者劃分到多張表中，同時這些表也可以處在不同的伺服器。按業務的垂直拆庫和按使用者水平拆表是分布式資料庫中通用的解決方案。
前面我們談到了分布式來解決效能問題，但其附帶的問題是怎麼分布，即如何負載均衡。這裡要解決的問題是當客戶端請求時，應該讓它請求分布式系統中哪一台伺服器，通常的做法是通過一台中間伺服器來給客服端分配目標伺服器。
這裡同樣拿兩個不同的分布式系統做說明，下圖左邊是分布式檔案系統fastdfs,右邊是乙個用於分布式的rpc中介軟體。
zookeeper是分布式系統中乙個負載均衡框架，google的chubby的乙個開源實現，是是hadoop和hbase的重要元件。
同樣的在http中，常聽說的nginx也是乙個負載均衡伺服器，它面向的是分布式web伺服器。至於具體的負載均衡算**詢，hash等這裡就不深入了。
分布式系統中，解決了負載均衡的問題後，另外乙個問題就是資料的一致性了，這個就需要通過同步來保障。根據不同的場景和需求，同步的方式也是有選擇的。
在分布式檔案系統中，比如商品頁面的，如果進行了修改，同步要求並不高，就算有數秒甚至數分鐘的延遲都是可以接受的，因為一般不會產生損失性的影響，因此可以簡單的通過檔案修改的時間戳，隔一定時間掃瞄同步一次，可以犧牲一致性來提高效率。
但銀行中的分布式資料庫就不一樣了，一丁點不同步就是無法接受的，甚至可以通過加鎖等犧牲效能的方式來保障完全的一致。
在一致性演算法中paxos演算法是公認的最好的演算法，chubby、zookeeper中paxos是它保證一致性的核心。這個演算法比較難懂，我目前也沒弄懂，這裡就不深入了。
分布式 分布式系統的設計
在計算機領域，當單機效能達到瓶頸時，一般有兩種方式解決效能問題 而分布式系統的設計說白了就是 如何合理將乙個系統拆分成多個子系統部署到不同機器上。講設計方法前，先介紹分布式系統的特性 1 分布性 空間中隨機分布。這些計算機可以分布在不同的機房，不同的城市，甚至不同的國家。2 對等性 分布式系統中的計...
分布式系統原理 筆記
資料分布協議 使用維度各有利弊 雜湊 更新起來要成倍遷移 一致性雜湊 環雜湊，易實現負載均衡 資料量 元資料多，類似b樹的中間節點 資料範圍 也是元資訊多 基本副本協議 中心化 primary secondary 中心節點負責維護資料的更新 併發控制 協調副本的一致性 去中心化 乙個節點向另乙個節點...
分布式系統中的分布式事務
分布式事務中可以借助mq訊息系統來進行事務控制，這一點與可靠訊息最終一致方案一樣。看來mq中介軟體確實在乙個分布式系統架構中，扮演者重要的角色。最大努力通知方案是比較簡單的分布式事務方案，它本質上就是通過定期校對，實現資料一致性。中介軟體如何保證訊息的一致性 問題的問法多種多樣，怎麼保證兩個伺服器的...