最近有人總跟我說這個樣的問題有的時候真不想在技術上表現的太突出，特別是某些領導但是越是這樣給臉不要臉的人大有人在太low 了，這也是我第一次我感覺到沒有共同的語言。
正事走起。
分佈式是指將一個業務拆分不同的子業務，分佈在不同的機器上執行，集羣是指多臺服務器集中在一起，實現同一業務，可以視爲一臺計算機，一個雲計算平臺，就是通過一套軟件系統把分佈式部署的資源集中調度使用。要應對大併發，要實現高可用，既需要分佈式，也離不開集羣。
分佈式和集羣區別？
分佈式
分佈式：是指將一個業務拆分不同的子業務，分佈在不同的機器上執行。
集羣
集羣：是指多臺服務器集中在一起，實現同一業務，可以視爲一臺計算機。
多臺服務器組成的一組計算機，作爲一個整體存在，向用戶提供一組網絡資源，這些單個的服務器就是集羣的節點。
兩個特點
可擴展性：集羣中的服務節點，可以動態的添加機器，從而增加集羣的處理能力。
高可用性：如果集羣某個節點發生故障，這臺節點上面運行的服務，可以被其他服務節點接管，從而增強集羣的高可用性。
集羣分類
常用的集羣分類
1.高可用集羣(High Availability Cluster)
高可用集羣,普通兩節點雙機熱備，多節點HA集羣。
2.負載均衡集羣(Load Balance Cluster)
常用的有 Nginx 把請求分發給後端的不同web服務器，還有就是數據庫集羣，負載均衡就是，爲了保證服務器的高可用，高併發。
3.科學計算集羣(High Performance Computing Cluster)
簡稱HPC集羣。這類集羣致力於提供單個計算機所不能提供的強大的計算能力。
兩大能力
負載均衡：負載均衡能把任務比較均衡地分佈到集羣環境下的計算和網絡資源。
集羣容錯：當我們的系統中用到集羣環境,因爲各種原因在集羣調用失敗時，集羣容錯起到關鍵性的作用。
例如 Dubbo 的集羣容錯：
Failover Cluster
失敗自動切換，當出現失敗，重試其它服務器，通常用於讀操作，但重試會帶來更長延遲。
Failfast Cluster
快速失敗，只發起一次調用，失敗立即報錯，通常用於非冪等性的寫操作，比如新增記錄。
Failback Cluster
失敗自動恢復，後臺記錄失敗請求，定時重發，通常用於消息通知操作。
Forking Cluster
並行調用多個服務器，只要一個成功即返回，通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。
簡單總結
分佈式，從狹義上理解，也與集羣差不多，但是它的組織比較鬆散，不像集羣，有一定組織性，一臺服務器宕了，其他的服務器可以頂上來。
分佈式的每一個節點，都完成不同的業務，一個節點宕了，這個業務就不可訪問了。
1. 分佈式是指將一個業務拆分不同的子業務，分佈在不同的機器上執行。
2. 集羣是指多臺服務器集中在一起，實現同一業務，可以視爲一臺計算機。
分佈式的每一個節點，都可以用來做集羣。而集羣不一定就是分佈式了。
什麼是雲計算平臺？
一個雲計算平臺，就是通過一套軟件系統把分佈式部署的資源集中調度使用。要應對大併發，要實現高可用，既需要分佈式，也離不開集羣。
比如負載均衡，如果只是一臺服務器，這臺宕機了就完蛋了。
分佈式的難點，就是很多機器做存在依賴關係的不同活兒，這些活兒需要的資源、時間區別可能很大，某些機器還可能罷工，要怎麼樣才能協調好，做到效率最高，消耗最少，不出錯。
分佈式的應用場景？
平時接觸到的分佈式系統有很多種，比如分佈式文件系統，分佈式數據庫，分佈式WebService，分佈式計算等等，面向的情景不同，但分佈式的思路是否是一樣的呢?
1.簡單的例子
假設我們有一臺服務器，它可以承擔1百萬/秒的請求，這個請求可以的是通過http訪問網頁，通過tcp下載文件，jdbc執行sql，RPC調用接口…，現在我們有一條數據的請求是2百萬/秒，很顯然服務器hold不住了，會各種拒絕訪問，甚至崩潰，宕機，怎麼辦呢。
一臺機器解決不了的問題，那就兩臺。所以我們加一臺機器，每臺承擔1百萬。如果請求繼續增加呢，兩臺解決不了的問題，那就三臺唄。
這種方式我們稱之爲水平擴展。如何實現請求的平均分配便是負載均衡了。
另一個栗子，我們現在有兩個數據請求，數據1 90萬，數據2 80萬，上面那臺機器也hold不住，我們加一臺機器來負載均衡一下，每臺機器處理45萬數據1和40萬數據2，但是平分太麻煩，不如一臺處理數據1，一臺處理數據2，同樣能解決問題，這種方式我們稱之爲垂直拆分。
水平擴展和垂直拆分是分佈式架構的兩種思路，但並不是一個二選一的問題，更多的是兼併合用。下面介紹一個實際的場景。這也是許多互聯網的公司架構思路。
2.實際的例子
我此時所在的公司的計算機系統很龐大，自然是一個整的分佈式系統，爲了方便組織管理，公司將整個技術部按業務和平臺拆分爲部門，訂單的，會員的，商家的等等，每個部門有自己的web服務器集羣，數據庫服務器集羣，通過同一個網站訪問的鏈接可能來自於不同的服務器和數據庫，對網站及底層對數據庫的訪問被分配到了不同的服務器集羣,這個便是典型的按業務做的垂直拆分，每個部門的服務器在hold不住時，會有彈性的擴展，這便是水平擴展。
在數據庫層，有些表非常大，數據量在億級，如果只是純粹的水平的擴展並不一定最好，如果對錶進行拆分，比如可以按用戶id進行水平拆表，通過對id取模的方式，將用戶劃分到多張表中，同時這些表也可以處在不同的服務器。按業務的垂直拆庫和按用戶水平拆表是分佈式數據庫中通用的解決方案。
比如 Mycat 開源分佈式數據庫中間件 http://www.mycat.io/
3.分佈式一致性
分佈式系統中，解決了負載均衡的問題後，另外一個問題就是數據的一致性了，這個就需要通過同步來保障。根據不同的場景和需求，同步的方式也是有選擇的。
在分佈式文件系統中，比如商品頁面的圖片，如果進行了修改，同步要求並不高，就算有數秒甚至數分鐘的延遲都是可以接受的，因爲一般不會產生損失性的影響，因此可以簡單的通過文件修改的時間戳，隔一定時間掃描同步一次，可以犧牲一致性來提高效率。
但銀行中的分佈式數據庫就不一樣了，一丁點不同步就是無法接受的，甚至可以通過加鎖等犧牲性能的方式來保障完全的一致。
在一致性算法中paxos算法是公認的最好的算法，Chubby、ZooKeeper 中Paxos是它保證一致性的核心。這個算法比較難懂，我目前也沒弄懂，這裏就不深入了。