分布式：分布式系统的设计
#整理了一些博文作為分布式相關理論的學習筆記，同時加上了一些個人的理解，尊重原創者，文章屬性就設為轉載吧，參考博文的鏈接已附在最后。
分布式
- 概要，與集群的區別
- 分布式系統的設計
- CAP 和 BASE 理論
一、分布式系統
在計算機領域，當單機性能達到瓶頸時，一般有兩種方式解決性能問題：
- 堆硬件，進一步提升配置；
- 分布式設計，如水平拆分、垂直拆分。
分布式系統有很多種：分布式文件系統、分布式數據庫、分布式 WebService、分布式計算等等，面向的情景不同，但分布式的思路大致相同，萬法歸一。
而分布式系統的設計說白了就是： 如何合理將一個系統拆分成多個子系統部署到不同機器上。
講設計方法前，先介紹分布式系統的特性：
1. 分布式系統的特性
（1）分布性
空間中隨機分布。這些計算機可以分布在不同的機房，不同的城市，甚至不同的國家。
（2）對等性
分布式系統中的計算機沒有主/從之分，組成分布式系統的所有節點都是對等的。在分布式系統最常見的概念之一是副本–數據副本和服務副本。數據副本是指在不同的節點上持久化同一份數據，當某一個節點上存儲的 數據丟失時，可以從副本上讀取到該數據，這是解決分布式系統數據丟失問題最為有效的手段。服務副本，指多個節點提供同樣的服務，每個節點都有 能力接收來自外部的請求并進行相應的處理。
（3）并發性
同一個分布式系統的多個節點，可能會并發地操作一些共享的資源，諸如數據庫或分布式存儲。
（4）缺乏全局時鐘
既然各個計算機之間是依賴于交換信息來進行相互通信，很難定義兩件事件的先后順序，缺乏全局始終控制序列。
（5）故障總會發生
組成分布式的計算機，都有可能在某一時刻突然間崩掉。分的計算機越多，可能崩掉一個的幾率就越大。如果再考慮到設計程序時的異常故障，也會加大故障的概率。
（6）處理單點故障
單點 SPoF（Single Point of Failure）：某個角色或者功能只有某一臺計算機在支撐，在這臺計算機上出現的故障是單點故障。當然處理方式可以是采用上面所講的：集群。
2. 分布式系統的設計
將系統拆分成多個子系統，這就意味著拆分后的系統必然需要通過網絡進行互相通信聯系。所以通信中的穩定和安全也顯得尤為重要。隨著業務慢慢的增長，擴展性、可靠性、數據一致性都需要進行考慮。
（1）系統拆分成子系統。這個需要設計師好好設計，將一個大系統拆分成多個小系統，分層次來維護。
（2）設計系統間的通信。在這兒我們可以使用消息中間件，開源框架幫我們解決了這個問題。如Apache ActiveMQ、RabbitMQ、Apache RocketMQ、Apache Kafka等。
（3）設計分布式計算。開源框架有 apReduce、Apache Hadoop、Apache Spark 等。
（4）大數據和分布式存儲。有 Apache HBase、Apache Cassandra、Memcached、Redis、MongoDB等。
（5）分布式監控控制。常用的技術包括Nagios、Zabbix、Consul、ZooKeeper等。
2.1 水平拆分和垂直拆分
水平拆分：
以購物平臺為例：
水平拆分是指按照 業務 對系統進行劃分 。比如原來的系統中包括了交易，運營兩大類，按照水平拆分的原則進行拆分，系統可以拆分成 交易系統 和 運營系統。
優點：不同業務，往往性能要求，以及請求量是不一樣的。拆分后保證業務之間的可用性影響最小化。
缺點：拆分過程中，多個系統中可能存在重復的輪子，難于維護。
假設我們有一臺服務器，它可以承擔 1 百萬/秒的請求，這個請求可以的是：通過 http 訪問網頁、通過 tcp 下載文件、jdbc 執行 sql、RPC 調用接口等等方式，現在我們有一條數據的請求是 2 百萬/秒，很顯然服務器很難hold 住，會各種拒絕訪問，甚至宕機，怎么辦呢？
一臺機器解決不了的問題，那就兩臺。所以我們加一臺機器，每臺承擔 1 百萬。如果請求繼續增加呢，兩臺解決不了的問題，那就三臺唄。這種方式我們稱之為水平拆分，如果實現請求的平均分配便是負載均衡了。
垂直拆分：
垂而直拆分是將同樣的系統按照應用場景(調用方)進行拆分 。
比如交易系統的支付模塊，上游有用戶支付和商家支付兩個調用流程。按照垂直拆分的規則就可以將支付模塊拆分為用戶支付和商家支付。
優點：按需配給（預估調用方的流量，配置對應的機器數），各個垂直調用之間相互不影響，通過配置可以進行上游調用降級。
缺點：幾乎完全重復的輪子。
在如，我們現在有兩個數據請求，數據1有 190 萬，數據2有 280 萬，上面那臺機器也 hold 不住，我們加一臺機器來負載均衡一下，每臺機器處理 45 萬數據1和 40 萬數據2，但是平分太麻煩，不如一臺處理數據1，一臺處理數據2，同樣能解決問題，這種方式我們稱之為垂直拆分。
垂直拆分更多是用在數據庫的拆分，如將某一張列很多的數據表拆分成多張數據表。
水平拆分和垂直拆分是分布式架構的兩種思路，但并不是一個二選一的問題，更多的是兼并合用。
注意：要將分布式設計中的水平拆分、垂直拆分與高并發中的水平擴展、垂直擴展區分開來。
2.2 負載均衡
前面我們談到了分布式來解決性能問題，但其附帶的問題是怎么分布，即如何負載均衡。這里要解決的問題是當客戶端發出請求時，應該讓哪一臺服務器對該請求進行處理，通常的做法是通過一臺中間服務器來給客戶端分配目標服務器。
常見如 zookeeper 是分布式系統中一個負載均衡框架，它是 google 的 chubby 的一個開源實現，是 Hadoop 和 Hbase 的重要組件。
同樣的在 http 中，常聽說的 nginx 也是一個負載均衡服務器，它面向的是分布式 web 服務器。
2.3 同步問題
分布式系統中，解決了負載均衡的問題后，另外一個問題就是數據的一致性了，這個就需要通過同步來保障。根據不同的場景和需求，同步的方式也是有選擇的。
在分布式文件系統中，比如商品頁面的圖片，如果進行了修改，同步要求并不高，就算有數秒甚至數分鐘的延遲都是可以接受的，因為一般不會產生損失性的影響，因此可以簡單的通過文件修改的時間戳，隔一定時間掃描同步一次，可以犧牲一致性來提高效率。
但銀行中的分布式數據庫就不一樣了，一丁點不同步就是無法接受的，甚至可以通過加鎖等犧牲性能的方式來保障完全的一致。
在一致性算法中 paxos 算法是公認的最好的算法，chubby、zookeeper 中 paxos 是它保證一致性的核心。
二、分布式架構下的高可用設計
避免單點故障
○ 負載均衡技術（failover ，選址，硬件負載，軟件負載，去中心化負載（gossip（redis-cluster））；
○ 熱備 linux HA；
○ 多機房（同城災備，異地災備）；
應用的高可用
○ 故障監控（系統監控（cpu，內存）、鏈路監控、日志監控）自動預警；
○ 應用的容錯設計 （服務降級，限流） 自我保護能力；
○ 數據量 （數據分片，讀寫分離）。
(待補充)
————————————————
參考鏈接：
https://blog.csdn.net/cutesource/article/details/5811914
https://blog.csdn.net/mcb520wf/article/details/82456456
https://my.oschina.net/niepanLs/blog/875578
https://blog.csdn.net/yuhaiyang_1/article/details/80892492
總結
以上是生活随笔為你收集整理的分布式：分布式系统的设计的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 分布式系统常见问题
- 下一篇： 总结：几个分布式系统架构设计原理