一．什么是分布式系統(tǒng)
分布式系統(tǒng)是由一組通過網(wǎng)絡進行通信右遭、為了完成共同的任務而協(xié)調工作的計算機節(jié)點組成的系統(tǒng)。分布式系統(tǒng)的出現(xiàn)是為了用廉價的缤削、普通的機器完成單個計算機無法完成的計算窘哈、存儲任務。其目的是利用更多的機器亭敢，處理更多的數(shù)據(jù)滚婉。
首先需要明確的是，只有當單個節(jié)點的處理能力無法滿足日益增長的計算帅刀、存儲任務的時候让腹，且硬件的提升（加內存、加磁盤扣溺、使用更好的CPU）高昂到得不償失的時候骇窍，應用程序也不能進一步優(yōu)化的時候，我們才需要考慮分布式系統(tǒng)锥余。因為腹纳，分布式系統(tǒng)要解決的問題本身就是和單機系統(tǒng)一樣的，而由于分布式系統(tǒng)多節(jié)點驱犹、通過網(wǎng)絡通信的拓撲結構嘲恍，會引入很多單機系統(tǒng)沒有的問題，為了解決這些問題又會引入更多的機制着绷、協(xié)議蛔钙，帶來更多的問題。荠医。吁脱。
在很多文章中桑涎，主要講分布式系統(tǒng)分為分布式計算（computation）與分布式存儲（storage）。計算與存儲是相輔相成的兼贡，計算需要數(shù)據(jù)攻冷，要么來自實時數(shù)據(jù)（流數(shù)據(jù)），要么來自存儲的數(shù)據(jù)遍希；而計算的結果也是需要存儲的等曼。在操作系統(tǒng)中，對計算與存儲有非常詳盡的討論凿蒜，分布式系統(tǒng)只不過將這些理論推廣到多個節(jié)點罷了禁谦。
那么分布式系統(tǒng)怎么將任務分發(fā)到這些計算機節(jié)點呢，很簡單的思想废封，分而治之州泊，即分片（partition）。對于計算漂洋，那么就是對計算任務進行切換遥皂，每個節(jié)點算一些，最終匯總就行了刽漂，這就是MapReduce的思想演训；對于存儲，更好理解一下贝咙，每個節(jié)點存一部分數(shù)據(jù)就行了样悟。當數(shù)據(jù)規(guī)模變大的時候，Partition是唯一的選擇颈畸，同時也會帶來一些好處：
（1）提升性能和并發(fā)乌奇，操作被分發(fā)到不同的分片，相互獨立
（2）提升系統(tǒng)的可用性眯娱，即使部分分片不能用礁苗，其他分片不會受到影響
理想的情況下，有分片就行了徙缴，但事實的情況卻不大理想试伙。原因在于，分布式系統(tǒng)中有大量的節(jié)點于样，且通過網(wǎng)絡通信疏叨。單個節(jié)點的故障（進程crash、斷電穿剖、磁盤損壞）是個小概率事件蚤蔓，但整個系統(tǒng)的故障率會隨節(jié)點的增加而指數(shù)級增加，網(wǎng)絡通信也可能出現(xiàn)斷網(wǎng)糊余、高延遲的情況秀又。在這種一定會出現(xiàn)的“異车ゼ牛”情況下，分布式系統(tǒng)還是需要繼續(xù)穩(wěn)定的對外提供服務吐辙，即需要較強的容錯性宣决。最簡單的辦法，就是冗余或者復制集（Replication）昏苏，即多個節(jié)點負責同一個任務尊沸，最為常見的就是分布式存儲中，多個節(jié)點復雜存儲同一份數(shù)據(jù)贤惯，以此增強可用性與可靠性洼专。同時，Replication也會帶來性能的提升孵构，比如數(shù)據(jù)的locality可以減少用戶的等待時間壶熏。
下面這種來自Distributed?systems?for?fun?and?profit??的圖形象生動說明了Partition與Replication是如何協(xié)作的。
Partition和Replication是解決分布式系統(tǒng)問題的一記組合拳浦译，很多具體的問題都可以用這個思路去解決。但這并不是銀彈溯职，往往是為了解決一個問題精盅，會引入更多的問題，比如為了可用性與可靠性保證谜酒，引用了冗余（復制集）叹俏。有了冗余，各個副本間的一致性問題就變得很頭疼僻族，一致性在系統(tǒng)的角度和用戶的角度又有不同的等級劃分粘驰。如果要保證強一致性，那么會影響可用性與性能述么，在一些應用（比如電商蝌数、搜索）是難以接受的。如果是最終一致性度秘，那么就需要處理數(shù)據(jù)沖突的情況顶伞。CAP、FLP這些理論告訴我們剑梳，在分布式系統(tǒng)中唆貌，沒有最佳的選擇，都是需要權衡垢乙，做出最合適的選擇锨咙。
分布式系統(tǒng)挑戰(zhàn)
分布式系統(tǒng)需要大量機器協(xié)作，面臨諸多的挑戰(zhàn)：
第一追逮，異構的機器與網(wǎng)絡：
分布式系統(tǒng)中的機器酪刀，配置不一樣粹舵，其上運行的服務也可能由不同的語言、架構實現(xiàn)蓖宦，因此處理能力也不一樣齐婴；節(jié)點間通過網(wǎng)絡連接，而不同網(wǎng)絡運營商提供的網(wǎng)絡的帶寬稠茂、延時柠偶、丟包率又不一樣。怎么保證大家齊頭并進睬关，共同完成目標诱担，這四個不小的挑戰(zhàn)。
第二电爹，普遍的節(jié)點故障：
雖然單個節(jié)點的故障概率較低蔫仙，但節(jié)點數(shù)目達到一定規(guī)模，出故障的概率就變高了丐箩。分布式系統(tǒng)需要保證故障發(fā)生的時候摇邦，系統(tǒng)仍然是可用的，這就需要監(jiān)控節(jié)點的狀態(tài)屎勘，在節(jié)點故障的情況下將該節(jié)點負責的計算施籍、存儲任務轉移到其他節(jié)點
第三，不可靠的網(wǎng)絡：
節(jié)點間通過網(wǎng)絡通信概漱，而網(wǎng)絡是不可靠的丑慎。可能的網(wǎng)絡問題包括：網(wǎng)絡分割瓤摧、延時竿裂、丟包、亂序照弥。
相比單機過程調用腻异，網(wǎng)絡通信最讓人頭疼的是超時：節(jié)點A向節(jié)點B發(fā)出請求，在約定的時間內沒有收到節(jié)點B的響應这揣，那么B是否處理了請求捂掰，這個是不確定的，這個不確定會帶來諸多問題曾沈，最簡單的这嚣，是否要重試請求，節(jié)點B會不會多次處理同一個請求塞俱。
總而言之姐帚，分布式的挑戰(zhàn)來自不確定性，不確定計算機什么時候crash障涯、斷電罐旗，不確定磁盤什么時候損壞膳汪，不確定每次網(wǎng)絡通信要延遲多久，也不確定通信對端是否處理了發(fā)送的消息九秀。而分布式的規(guī)模放大了這個不確定性遗嗽，不確定性是令人討厭的，所以有諸多的分布式理論鼓蜒、協(xié)議來保證在這種不確定性的情況下痹换，系統(tǒng)還能繼續(xù)正常工作。
而且都弹，很多在實際系統(tǒng)中出現(xiàn)的問題娇豫，來源于設計時的盲目樂觀，覺得這個畅厢、那個應該不會出問題冯痢。Fallacies_of_distributed_computing很有意思，介紹了分布式系統(tǒng)新手可能的錯誤的假設：
The network is reliable.
Latency is zero.
Bandwidth is infinite.
The network is secure.
Topology doesn't change.
There is one administrator.
Transport cost is zero.
The network is homogeneous.
劉杰在《分布式系統(tǒng)原理介紹》中指出框杜，處理這些異常的最佳原則是：在設計浦楣、推導、驗證分布式系統(tǒng)的協(xié)議咪辱、流程時,最重要的工作之一就是思考在執(zhí)行流程的每個步驟時一旦發(fā)生各種異常的情況下系統(tǒng)的處理方式及造成的影響椒振。
透明性：使用分布式系統(tǒng)的用戶并不關心系統(tǒng)是怎么實現(xiàn)的，也不關心讀到的數(shù)據(jù)來自哪個節(jié)點梧乘，對用戶而言，分布式系統(tǒng)的最高境界是用戶根本感知不到這是一個分布式系統(tǒng)庐杨，在《Distributed Systems Principles and
Paradigms》一書中选调，作者是這么說的：
A distributed
system is a collection of independent computers that appears to its users as a
single coherent system.
可擴展性：分布式系統(tǒng)的根本目標就是為了處理單個計算機無法處理的任務，當任務增加的時候灵份，分布式系統(tǒng)的處理能力需要隨之增加仁堪。簡單來說，要比較方便的通過增加機器來應對數(shù)據(jù)量的增長填渠，同時弦聂，當任務規(guī)模縮減的時候氛什，可以撤掉一些多余的機器莺葫，達到動態(tài)伸縮的效果
可用性與可靠性：一般來說，分布式系統(tǒng)是需要長時間甚至7*24小時提供服務的枪眉∞嗝剩可用性是指系統(tǒng)在各種情況對外提供服務的能力，簡單來說贸铜，可以通過不可用時間與正常服務時間的必知來衡量堡纬；而可靠性而是指計算結果正確聂受、存儲的數(shù)據(jù)不丟失。
高性能：不管是單機還是分布式系統(tǒng)烤镐，大家都非常關注性能蛋济。不同的系統(tǒng)對性能的衡量指標是不同的，最常見的：高并發(fā)炮叶，單位時間內處理的任務越多越好碗旅；低延遲：每個任務的平均時間越少越好。這個其實跟操作系統(tǒng)CPU的調度策略很像
一致性：分布式系統(tǒng)為了提高可用性可靠性悴灵，一般會引入冗余（復制集）扛芽。那么如何保證這些節(jié)點上的狀態(tài)一致，這就是分布式系統(tǒng)不得不面對的一致性問題积瞒。一致性有很多等級川尖，一致性越強，對用戶越友好茫孔，但會制約系統(tǒng)的可用性叮喳；一致性等級越低，用戶就需要兼容數(shù)據(jù)不一致的情況缰贝，但系統(tǒng)的可用性馍悟、并發(fā)性很高很多。
假設這是一個對外提供服務的大型分布式系統(tǒng)，用戶連接到系統(tǒng)赞弥，做一些操作毅整，產(chǎn)生一些需要存儲的數(shù)據(jù)，那么在這個過程中绽左，會遇到哪些組件悼嫉、理論與協(xié)議呢
用戶使用Web、APP拼窥、SDK戏蔑，通過HTTP、TCP連接到系統(tǒng)鲁纠。在分布式系統(tǒng)中总棵，為了高并發(fā)、高可用改含，一般都是多個節(jié)點提供相同的服務彻舰。那么，第一個問題就是具體選擇哪個節(jié)點來提供服務，這個就是負載均衡（load balance）刃唤。負載均衡的思想很簡單隔心，但使用非常廣泛，在分布式系統(tǒng)尚胞、大型網(wǎng)站的方方面面都有使用硬霍，或者說，只要涉及到多個節(jié)點提供同質的服務笼裳，就需要負載均衡唯卖。
通過負載均衡找到一個節(jié)點，接下來就是真正處理用戶的請求躬柬，請求有可能簡單拜轨，也有可能很復雜。簡單的請求允青，比如讀取數(shù)據(jù)橄碾，那么很可能是有緩存的燕耿，即分布式緩存颖变，如果緩存沒有命中，那么需要去數(shù)據(jù)庫拉取數(shù)據(jù)饮焦。對于復雜的請求琼掠，可能會調用到系統(tǒng)中其他的服務拒垃。
承上，假設服務A需要調用服務B的服務瓷蛙，首先兩個節(jié)點需要通信悼瓮，網(wǎng)絡通信都是建立在TCP/IP協(xié)議的基礎上，但是艰猬，每個應用都手寫socket是一件冗雜横堡、低效的事情，因此需要應用層的封裝姥宝，因此有了HTTP、FTP等各種應用層協(xié)議恐疲。當系統(tǒng)愈加復雜腊满，提供大量的http接口也是一件困難的事情。因此培己，有了更進一步的抽象碳蛋，那就是RPC（remote produce call），是的遠程調用就跟本地過程調用一樣方便省咨，屏蔽了網(wǎng)絡通信等諸多細節(jié)肃弟，增加新的接口也更加方便。
一個請求可能包含諸多操作，即在服務A上做一些操作笤受，然后在服務B上做另一些操作穷缤。比如簡化版的網(wǎng)絡購物，在訂單服務上發(fā)貨箩兽，在賬戶服務上扣款津肛。這兩個操作需要保證原子性，要么都成功汗贫，要么都不操作身坐。這就涉及到分布式事務的問題，分布式事務是從應用層面保證一致性：某種守恒關系落包。
上面說道一個請求包含多個操作部蛇，其實就是涉及到多個服務，分布式系統(tǒng)中有大量的服務咐蝇，每個服務又是多個節(jié)點組成涯鲁。那么一個服務怎么找到另一個服務（的某個節(jié)點呢）？通信是需要地址的嘹害，怎么獲取這個地址撮竿，最簡單的辦法就是配置文件寫死，或者寫入到數(shù)據(jù)庫笔呀，但這些方法在節(jié)點數(shù)據(jù)巨大幢踏、節(jié)點動態(tài)增刪的時候都不大方便，這個時候就需要服務注冊與發(fā)現(xiàn)：提供服務的節(jié)點向一個協(xié)調中心注冊自己的地址许师，使用服務的節(jié)點去協(xié)調中心拉取地址房蝉。
從上可以看見，協(xié)調中心提供了中心化的服務：以一組節(jié)點提供類似單點的服務微渠，使用非常廣泛搭幻，比如命令服務、分布式鎖逞盆。協(xié)調中心最出名的就是chubby檀蹋，zookeeper。
回到用戶請求這個點云芦，請求操作會產(chǎn)生一些數(shù)據(jù)俯逾、日志，通常為信息舅逸，其他一些系統(tǒng)可能會對這些消息感興趣桌肴，比如個性化推薦、監(jiān)控等琉历，這里就抽象出了兩個概念坠七，消息的生產(chǎn)者與消費者水醋。那么生產(chǎn)者怎么講消息發(fā)送給消費者呢，RPC并不是一個很好的選擇彪置，因為RPC肯定得指定消息發(fā)給誰拄踪，但實際的情況是生產(chǎn)者并不清楚、也不關心誰會消費這個消息悉稠，這個時候消息隊列就出馬了宫蛆。簡單來說，生產(chǎn)者只用往消息隊列里面發(fā)就行了的猛，隊列會將消息按主題（topic）分發(fā)給關注這個主題的消費者耀盗。消息隊列起到了異步處理、應用解耦的作用卦尊。
上面提到叛拷，用戶操作會產(chǎn)生一些數(shù)據(jù)，這些數(shù)據(jù)忠實記錄了用戶的操作習慣岂却、喜好忿薇，是各行各業(yè)最寶貴的財富。比如各種推薦躏哩、廣告投放署浩、自動識別。這就催生了分布式計算平臺扫尺，比如Hadoop筋栋，Storm等，用來處理這些海量的數(shù)據(jù)正驻。
最后弊攘，用戶的操作完成之后，用戶的數(shù)據(jù)需要持久化姑曙，但數(shù)據(jù)量很大襟交，大到按個節(jié)點無法存儲，那么這個時候就需要分布式存儲：將數(shù)據(jù)進行劃分放在不同的節(jié)點上伤靠，同時捣域，為了防止數(shù)據(jù)的丟失，每一份數(shù)據(jù)會保存多分宴合。傳統(tǒng)的關系型數(shù)據(jù)庫是單點存儲焕梅，為了在應用層透明的情況下分庫分表，會引用額外的代理層形纺。而對于NoSql丘侠，一般天然支持分布式徒欣。
下面用一個不大精確的架構圖逐样，盡量還原分布式系統(tǒng)的組成部分（不過只能體現(xiàn)出技術，不好體現(xiàn)出理論）
概念與實現(xiàn)
那么對于上面的各種技術與理論，業(yè)界有哪些實現(xiàn)呢脂新，下面進行簡單羅列挪捕。
當然，下面的這些實現(xiàn)争便，小部分我用過级零，知其所以然；大部分聽說過滞乙，知其然奏纪；還有一部分之前聞所未聞，分類也不一定正確斩启，只是從其他文章抄過來的序调。羅列在這里，以便日后或深或淺的學習兔簇。
負載均衡：
Nginx：高性能发绢、高并發(fā)的web服務器；功能包括負載均衡垄琐、反向代理边酒、靜態(tài)內容緩存、訪問控制狸窘；工作在應用層
LVS： Linux virtual server墩朦，基于集群技術和Linux操作系統(tǒng)實現(xiàn)一個高性能、高可用的服務器朦前；工作在網(wǎng)絡層
webserver：
Java：Tomcat介杆，Apache，Jboss
Python：gunicorn韭寸、uwsgi春哨、twisted、webpy恩伺、tornado
service：
SOA赴背、微服務、spring boot晶渠，django
容器：
docker凰荚，kubernetes
cache：
memcache、redis等
協(xié)調中心：
zookeeper褒脯、etcd等
zookeeper使用了Paxos協(xié)議Paxos是強一致性便瑟，高可用的去中心化分布式。zookeeper的使用場景非常廣泛番川，之后細講到涂。
rpc框架：
grpc脊框、dubbo、brpc
dubbo是阿里開源的Java語言開發(fā)的高性能RPC框架践啄，在阿里系的諸多架構中浇雹，都使用了dubbo + spring boot
消息隊列：
kafka、rabbitMQ屿讽、rocketMQ昭灵、QSP
消息隊列的應用場景：異步處理、應用解耦伐谈、流量削鋒和消息通訊
實時數(shù)據(jù)平臺：
storm烂完、akka
離線數(shù)據(jù)平臺：
hadoop、spark
PS:
apark诵棵、akka窜护、kafka都是scala語言寫的，看到這個語言還是很牛逼的
dbproxy：
cobar也是阿里開源的非春，在阿里系中使用也非常廣泛柱徙，是關系型數(shù)據(jù)庫的sharding + replica 代理
db：
mysql、oracle奇昙、MongoDB护侮、HBase
搜索：
elasticsearch、solr
日志：
rsyslog储耐、elk羊初、flume
本文版權歸作者xybaby（博文地址：http://www.cnblogs.com/xybaby/）所有
