本文成於2020年3月14日
參考：原文
文章目錄
分佈式和集羣名詞解釋
- 集羣 指將多臺服務器集中在一起，每臺服務器都實現相同的業務，做相同的事情。但是每臺服務器並不是缺一不可，存在的作用主要是緩解併發壓力和單點故障轉移問題。可以利用一些廉價的符合工業標準的硬件構造高性能的系統。實現：高擴展、高性能、低成本、高可用！
- 分佈式 就是將一個完整的系統，按照業務功能，拆分成一個個獨立的子系統，在分佈式結構中，每個子系統就被稱爲“服務”。這些子系統能夠獨立運行在web容器中，它們之間通過RPC方式通信。略等於微服務，微服務是更細的設計。
使用分佈式的心路歷程
- 大多數的開發者大多數的系統可能從來沒接觸過分佈式系統，也根本沒必要進行分佈式系統架構，爲什麼？因爲在訪問量或者QPS沒有達到單臺機器的性能瓶頸的時候，根本沒必要進行分佈式架構。那如果業務量上來了，一般會怎麼解決呢？
- 首先考慮的就是機器升級。機器配置的垂直擴展，首先要找到當前性能的瓶頸點，是CPU，是內存，是硬盤，還是帶寬。砸錢加CPU，砸錢換SSD硬盤，砸錢換1T內存，這通常是解決問題最直接也最高效的方法。帶寬不夠？加帶寬，1G不夠用100G。CPU 8核不夠？搞32核96核。這是絕大多數公司能思考到的第一個方案，也是最高效最快最安全的方法，立竿見影。
- 其次就是系統拆分，將所提供服務的主流程以及支線流程梳理出來，按照流程進行系統拆分。如同一棵樹，核心業務作爲主幹流程，其他系統按照需要進行拆分，如同樹的開枝散葉。所採取的方式有這麼一些，按前後端進行拆分，按照領域拆分，按團隊拆分，當然通常來說這些拆分基本都要跟着組織架構走。
- 再不行就進行技術升級，更換更加高效或者場景適合的技術。比如從 Oracle 更換到HBase。從A數據庫連接池更換到B數據庫連接池。技術的變革對於業務量的支持也是非常巨大的，同一臺機器不同的技術，效能發揮的程度可以說有天壤之別。
- 最後的最後手段纔會考慮分佈式架構，實在是砸不出這麼多錢了，實在是沒辦法了。因爲分佈式架構肯定會帶來非常多非常多的一致性問題，原本只需要訪問一臺機器，現在需要訪問N臺，那麼這N臺機器的一致性怎麼保證，以前撐死搞個主從備份就算完了，定時同步一下數據就好，現在N臺設備的數據怎麼管理，甚至這個集羣本身怎麼管理，都會成爲一個致命的問題。
- 所以只有等業務量到達一定程度了，單臺機器扛不住了，纔會開始堆錢升級機器，系統拆分，換技術，繼續堆錢升級機器，系統拆分…週而復始，發現成本太高或者技術已經到達上線了。最後沒辦法，就選擇分佈式架構了。
- 但是分佈式架構的優勢也是明顯的，用一羣低廉的設備，來提供一個高性能高吞吐量的穩定的系統，下面開始說說常見的分佈式集羣的架構。
常見的分佈式集羣架構
1. 純負載均衡形式(集羣方向)
在集羣前面，前置一個流量分發的組件進行流量分發，整個集羣的機器提供無差別的服務，這在常見的 web 服務器中是最最常見的。目前比較主流的方式就是整個集羣機器上雲，根據實時的調用量進行雲服務器彈性伸縮。常見的負載均衡有硬件層面的 F5、軟件層面的 nginx 等。
2. 領導選舉型(分佈式方向)
整個集羣的消息都會轉發到集羣的領導這裏，是一種 master-slavers，區別只是這個 master 是被臨時選舉出來的，一旦 master 宕機，集羣會立刻選舉出一個新的領導，繼續對外提供服務。使用領導選舉型架構的典型的應用有 ElasticSearch，zookeeper。
3. 區塊鏈型(分佈式方向)
整個集羣的每一個節點都可以進行記錄，但是記錄的內容要得到整個集羣 N 個機器的認可纔是合法的。典型的應用有 Bit Coin，以及 Hyperledger。
4. master-slaver型(分佈式方向)
整個集羣以某臺 master 爲中樞，進行集羣的調度。交互是這樣，一般會把所有的管理類型的數據放到 master 上，而把具體的數據放到 slaver 上，實際進行調用的時候，client 先調用 master 獲取數據所存放的 server 的 信息，再自行跟 slave 進行交互。典型的系統有 Hadoop集羣，HBase 集羣，Redis 集羣等。
5. 規則型一致性Hash
這種架構類型一般出現在數據庫分庫分表的設計中。按照規則進行分庫分表，在查詢之前使用規則引擎進行庫和表的確認，再對具體的應用進行訪問。爲什麼要用一致性 Hash ？其實用什麼都可以，只是對於這類應用來說一致性 Hash 比較常見而已。
