在計算機領域，當單機效能達到瓶頸時，一般有兩種方式解決效能問題：
而分布式系統的設計說白了就是： 如何合理將乙個系統拆分成多個子系統部署到不同機器上。
講設計方法前，先介紹分布式系統的特性：
（1）分布性
空間中隨機分布。這些計算機可以分布在不同的機房，不同的城市，甚至不同的國家。
（2）對等性
分布式系統中的計算機沒有主/從之分，組成分布式系統的所有節點都是對等的。在分布式系統最常見的概念之一是副本–資料副本和服務副本。資料副本是指在不同的節點上持久化同乙份資料，當某乙個節點上儲存的 資料丟失時，可以從副本上讀取到該資料，這是解決分布式系統資料丟失問題最為有效的手段。服務副本，指多個節點提供同樣的服務，每個節點都有 能力接收來自外部的請求並進行相應的處理。
（3）併發性
同乙個分布式系統的多個節點，可能會併發地操作一些共享的資源，諸如資料庫或分布式儲存。
（4）缺乏全域性時鐘
既然各個計算機之間是依賴於交換資訊來進行相互通訊，很難定義兩件事件的先後順序，缺乏全域性始終控制序列。
（5）故障總會發生
組成分布式的計算機，都有可能在某一時刻突然間崩掉。分的計算機越多，可能崩掉乙個的機率就越大。如果再考慮到設計程式時的異常故障，也會加大故障的概率。
（6）處理單點故障
單點 spof（single point of failure）：某個角色或者功能只有某一台計算機在支撐，在這台計算機上出現的故障是單點故障。當然處理方式可以是採用上面所講的：集群。
將系統拆分成多個子系統，這就意味著拆分後的系統必然需要通過網路進行互相通訊聯絡。所以通訊中的穩定和安全也顯得尤為重要。隨著業務慢慢的增長，擴充套件性、可靠性、資料一致性都需要進行考慮。
（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 百萬。如果請求繼續增加呢，兩台解決不了的問題，那就三颱唄。這種方式我們稱之為水平拆分，如果實現請求的平均分配便是負載均衡了。
垂直拆分：
垂而直拆分是將同樣的系統按照應用場景(呼叫方)進行拆分。
比如交易系統的支付模組，上游有使用者支付和商家支付兩個呼叫流程。按照垂直拆分的規則就可以將支付模組拆分為使用者支付和商家支付。
優點：按需配給（預估呼叫方的流量，配置對應的機器數），各個垂直呼叫之間相互不影響，通過配置可以進行上游呼叫降級。
缺點：幾乎完全重複的輪子。
在如，我們現在有兩個資料請求，資料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，記憶體）、鏈路監控、日誌監控）自動預警；
○ 應用的容錯設計 （服務降級，限流） 自我保護能力；
○ 資料量 （資料分片，讀寫分離）。
(待補充)
分布式 分布式鎖
本質是利用redis的setnx 方法的特性來加鎖，setnx 即key不存在則設定key，否則直接返回false，要求在分布式系統中使用同乙個redis服務，以下提供兩種解決方案 1 直接使用redistemplate 這其實並不能完全保證高併發下的安全問題，因為可能在鎖過期之後該執行緒尚未執行完...
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...
分布式系統中的分布式事務
分布式事務中可以借助mq訊息系統來進行事務控制，這一點與可靠訊息最終一致方案一樣。看來mq中介軟體確實在乙個分布式系統架構中，扮演者重要的角色。最大努力通知方案是比較簡單的分布式事務方案，它本質上就是通過定期校對，實現資料一致性。中介軟體如何保證訊息的一致性 問題的問法多種多樣，怎麼保證兩個伺服器的...