在計算機領域，當單機效能達到瓶頸時，有兩種方式可以解決效能問題，一是堆硬體，進一步提公升配置，二是分布式，水平擴充套件。當然，兩者都是一樣的燒錢。
今天聊聊我所理解的分布式系統的架構思路。
平時接觸到的分布式系統有很多種，比如分布式檔案系統，分布式資料庫，分布式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是它保證一致性的核心。這個演算法比較難懂，我目前也沒弄懂，這裡就不深入了。
接觸過這麼多分布式系統後發現，它們的設計思路是如此的相似，這或許就是萬法歸一吧。
本文由metaclblog於2017-02-25 17:35:25自動同步至cnblogs
出處：
分布式系統的架構思路
在計算機領域，當單機效能達到瓶頸時，有兩種方式可以解決效能問題，一是堆硬體，進一步提公升配置，二是分布式，水平擴充套件。當然，兩者都是一樣的燒錢。今天聊聊我所理解的分布式系統的架構思路。平時接觸到的分布式系統有很多種，比如分布式檔案系統，分布式資料庫，分布式webservice，分布式計算等等，面向...
分布式系統的架構思路
在計算機領域，當單機效能達到瓶頸時，有兩種方式可以解決效能問題，一是堆硬體，進一步提公升配置，二是分布式，水平擴充套件。當然，兩者都是一樣的燒錢。今天聊聊我所理解的分布式系統的架構思路。平時接觸到的分布式系統有很多種，比如分布式檔案系統，分布式資料庫，分布式webservice，分布式計算等等，面向...
python分布式架構 分布式架構
1.分布式架構 採用centos mongodb windows2012 python redis進行分布式架構搭建，mongodb的框架最核心的設計就是 mongodb和mapreduce。mongodb為海量的資料提供了儲存，則mapreduce為海量的資料提供了計算，windows2012作為...