什麼是分佈式系統 一個分佈式系統須要什麼結構

什麼是分佈式系統

 

  分佈式系統是由一組經過網絡進行通訊、爲了完成共同的任務而協調工做的計算機節點組成的系統。分佈式系統的出現是爲了用廉價的、普通的機器完成單個計算機沒法完成的計算、存儲任務。其目的是利用更多的機器,處理更多的數據html

  首先須要明確的是,只有當單個節點的處理能力沒法知足日益增加的計算、存儲任務的時候,且硬件的提高(加內存、加磁盤、使用更好的CPU)高昂到得不償失的時候,應用程序也不能進一步優化的時候,咱們才須要考慮分佈式系統。由於,分佈式系統要解決的問題自己就是和單機系統同樣的,而因爲分佈式系統多節點、經過網絡通訊的拓撲結構,會引入不少單機系統沒有的問題,爲了解決這些問題又會引入更多的機制、協議,帶來更多的問題。。。mysql

  在不少文章中,主要講分佈式系統分爲分佈式計算(computation)與分佈式存儲(storage)。計算與存儲是相輔相成的,計算須要數據,要麼來自實時數據(流數據),要麼來自存儲的數據;而計算的結果也是須要存儲的。在操做系統中,對計算與存儲有很是詳盡的討論,分佈式系統只不過將這些理論推廣到多個節點罷了。web

  那麼分佈式系統怎麼將任務分發到這些計算機節點呢,很簡單的思想,分而治之,即分片(partition)。對於計算,那麼就是對計算任務進行切換,每一個節點算一些,最終彙總就好了,這就是MapReduce的思想;對於存儲,更好理解一下,每一個節點存一部分數據就好了。當數據規模變大的時候,Partition是惟一的選擇,同時也會帶來一些好處:redis

  (1)提高性能和併發,操做被分發到不一樣的分片,相互獨立spring

  (2)提高系統的可用性,即便部分分片不能用,其餘分片不會受到影響sql

 

  理想的狀況下,有分片就好了,但事實的狀況卻不大理想。緣由在於,分佈式系統中有大量的節點,且經過網絡通訊。單個節點的故障(進程crash、斷電、磁盤損壞)是個小几率事件,但整個系統的故障率會隨節點的增長而指數級增長,網絡通訊也可能出現斷網、高延遲的狀況。在這種必定會出現的「異常」狀況下,分佈式系統仍是須要繼續穩定的對外提供服務,即須要較強的容錯性。最簡單的辦法,就是冗餘或者複製集(Replication),即多個節點負責同一個任務,最爲常見的就是分佈式存儲中,多個節點複雜存儲同一份數據,以此加強可用性與可靠性。同時,Replication也會帶來性能的提高,好比數據的locality能夠減小用戶的等待時間。docker

  下面這種來自Distributed systems for fun and profit  的圖形象生動說明了Partition與Replication是如何協做的。 數據庫

  

  Partition和Replication是解決分佈式系統問題的一記組合拳,不少具體的問題均可以用這個思路去解決。但這並非銀彈,每每是爲了解決一個問題,會引入更多的問題,好比爲了可用性與可靠性保證,引用了冗餘(複製集)。有了冗餘,各個副本間的一致性問題就變得很頭疼,一致性在系統的角度和用戶的角度又有不一樣的等級劃分。若是要保證強一致性,那麼會影響可用性與性能,在一些應用(好比電商、搜索)是難以接受的。若是是最終一致性,那麼就須要處理數據衝突的狀況。CAP、FLP這些理論告訴咱們,在分佈式系統中,沒有最佳的選擇,都是須要權衡,作出最合適的選擇。django

分佈式系統挑戰

  分佈式系統須要大量機器協做,面臨諸多的挑戰:編程

  第一,異構的機器與網絡:

    分佈式系統中的機器,配置不同,其上運行的服務也可能由不一樣的語言、架構實現,所以處理能力也不同;節點間經過網絡鏈接,而不一樣網絡運營商提供的網絡的帶寬、延時、丟包率又不同。怎麼保證你們齊頭並進,共同完成目標,這四個不小的挑戰。

  第二,廣泛的節點故障:

    雖然單個節點的故障機率較低,但節點數目達到必定規模,出故障的機率就變高了。分佈式系統須要保證故障發生的時候,系統仍然是可用的,這就須要監控節點的狀態,在節點故障的狀況下將該節點負責的計算、存儲任務轉移到其餘節點

  第三,不可靠的網絡:

    節點間經過網絡通訊,而網絡是不可靠的。可能的網絡問題包括:網絡分割、延時、丟包、亂序。

    相比單機過程調用,網絡通訊最讓人頭疼的是超時:節點A向節點B發出請求,在約定的時間內沒有收到節點B的響應,那麼B是否處理了請求,這個是不肯定的,這個不肯定會帶來諸多問題,最簡單的,是否要重試請求,節點B會不會屢次處理同一個請求。

 

  總而言之,分佈式的挑戰來自不肯定性,不肯定計算機何時crash、斷電,不肯定磁盤何時損壞,不肯定每次網絡通訊要延遲多久,也不肯定通訊對端是否處理了發送的消息。而分佈式的規模放大了這個不肯定性,不肯定性是使人討厭的,因此有諸多的分佈式理論、協議來保證在這種不肯定性的狀況下,系統還能繼續正常工做。

  並且,不少在實際系統中出現的問題,來源於設計時的盲目樂觀,以爲這個、那個應該不會出問題。Fallacies_of_distributed_computing頗有意思,介紹了分佈式系統新手可能的錯誤的假設:

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.

  劉傑在《分佈式系統原理介紹》中指出,處理這些異常的最佳原則是:在設計、推導、驗證分佈式系統的協議、流程時,最重要的工做之一就是思考在執行流程的每一個步驟時一旦發生各類異常的狀況下系統的處理方式及形成的影響。

 

 

分佈式系統特性與衡量標準

  透明性:使用分佈式系統的用戶並不關心繫統是怎麼實現的,也不關心讀到的數據來自哪一個節點,對用戶而言,分佈式系統的最高境界是用戶根本感知不到這是一個分佈式系統,在《Distributed Systems Principles and Paradigms》一書中,做者是這麼說的:

A distributed system is a collection of independent computers that appears to its users as a single coherent system.  

  可擴展性:分佈式系統的根本目標就是爲了處理單個計算機沒法處理的任務,當任務增長的時候,分佈式系統的處理能力須要隨之增長。簡單來講,要比較方便的經過增長機器來應對數據量的增加,同時,當任務規模縮減的時候,能夠撤掉一些多餘的機器,達到動態伸縮的效果

  可用性與可靠性:通常來講,分佈式系統是須要長時間甚至7*24小時提供服務的。可用性是指系統在各類狀況對外提供服務的能力,簡單來講,能夠經過不可用時間與正常服務時間的必知來衡量;而可靠性而是指計算結果正確、存儲的數據不丟失。

  高性能:無論是單機仍是分佈式系統,你們都很是關注性能。不一樣的系統對性能的衡量指標是不一樣的,最多見的:高併發,單位時間內處理的任務越多越好;低延遲:每一個任務的平均時間越少越好。這個其實跟操做系統CPU的調度策略很像

  一致性:分佈式系統爲了提升可用性可靠性,通常會引入冗餘(複製集)。那麼如何保證這些節點上的狀態一致,這就是分佈式系統不得不面對的一致性問題。一致性有不少等級,一致性越強,對用戶越友好,但會制約系統的可用性;一致性等級越低,用戶就須要兼容數據不一致的狀況,但系統的可用性、併發性很高不少。

 

 

組件、理論、協議

 

  假設這是一個對外提供服務的大型分佈式系統,用戶鏈接到系統,作一些操做,產生一些須要存儲的數據,那麼在這個過程當中,會遇到哪些組件、理論與協議呢

 

用一個請求串起來

  用戶使用Web、APP、SDK,經過HTTP、TCP鏈接到系統。在分佈式系統中,爲了高併發、高可用,通常都是多個節點提供相同的服務。那麼,第一個問題就是具體選擇哪一個節點來提供服務,這個就是負載均衡(load balance)。負載均衡的思想很簡單,但使用很是普遍,在分佈式系統、大型網站的方方面面都有使用,或者說,只要涉及到多個節點提供同質的服務,就須要負載均衡。

  經過負載均衡找到一個節點,接下來就是真正處理用戶的請求,請求有可能簡單,也有可能很複雜。簡單的請求,好比讀取數據,那麼極可能是有緩存的,即分佈式緩存,若是緩存沒有命中,那麼須要去數據庫拉取數據。對於複雜的請求,可能會調用到系統中其餘的服務。

  承上,假設服務A須要調用服務B的服務,首先兩個節點須要通訊,網絡通訊都是創建在TCP/IP協議的基礎上,可是,每一個應用都手寫socket是一件冗雜、低效的事情,所以須要應用層的封裝,所以有了HTTP、FTP等各類應用層協議。當系統越發複雜,提供大量的http接口也是一件困難的事情。所以,有了更進一步的抽象,那就是RPC(remote produce call),是的遠程調用就跟本地過程調用同樣方便,屏蔽了網絡通訊等諸多細節,增長新的接口也更加方便。

  一個請求可能包含諸多操做,即在服務A上作一些操做,而後在服務B上作另外一些操做。好比簡化版的網絡購物,在訂單服務上發貨,在帳戶服務上扣款。這兩個操做須要保證原子性,要麼都成功,要麼都不操做。這就涉及到分佈式事務的問題,分佈式事務是從應用層面保證一致性:某種守恆關係。

  上面說道一個請求包含多個操做,其實就是涉及到多個服務,分佈式系統中有大量的服務,每一個服務又是多個節點組成。那麼一個服務怎麼找到另外一個服務(的某個節點呢)?通訊是須要地址的,怎麼獲取這個地址,最簡單的辦法就是配置文件寫死,或者寫入到數據庫,但這些方法在節點數據巨大、節點動態增刪的時候都不大方便,這個時候就須要服務註冊與發現:提供服務的節點向一個協調中心註冊本身的地址,使用服務的節點去協調中心拉取地址。

  從上能夠看見,協調中心提供了中心化的服務:以一組節點提供相似單點的服務,使用很是普遍,好比命令服務、分佈式鎖。協調中心最出名的就是chubby,zookeeper。

  回到用戶請求這個點,請求操做會產生一些數據、日誌,一般爲信息,其餘一些系統可能會對這些消息感興趣,好比個性化推薦、監控等,這裏就抽象出了兩個概念,消息的生產者與消費者。那麼生產者怎麼講消息發送給消費者呢,RPC並非一個很好的選擇,由於RPC確定得指定消息發給誰,但實際的狀況是生產者並不清楚、也不關心誰會消費這個消息,這個時候消息隊列就出馬了。簡單來講,生產者只用往消息隊列裏面發就好了,隊列會將消息按主題(topic)分發給關注這個主題的消費者。消息隊列起到了異步處理、應用解耦的做用。

  上面提到,用戶操做會產生一些數據,這些數據忠實記錄了用戶的操做習慣、喜愛,是各行各業最寶貴的財富。好比各類推薦、廣告投放、自動識別。這就催生了分佈式計算平臺,好比Hadoop,Storm等,用來處理這些海量的數據。

  最後,用戶的操做完成以後,用戶的數據須要持久化,但數據量很大,大到按個節點沒法存儲,那麼這個時候就須要分佈式存儲:將數據進行劃分放在不一樣的節點上,同時,爲了防止數據的丟失,每一份數據會保存多分。傳統的關係型數據庫是單點存儲,爲了在應用層透明的狀況下分庫分表,會引用額外的代理層。而對於NoSql,通常自然支持分佈式。

 

一個簡化的架構圖

  下面用一個不大精確的架構圖,儘可能還原分佈式系統的組成部分(不過只能體現出技術,很差體現出理論)

  

 

 

概念與實現

  那麼對於上面的各類技術與理論,業界有哪些實現呢,下面進行簡單羅列。

  固然,下面的這些實現,小部分我用過,知其因此然;大部分據說過,知其然;還有一部分以前聞所未聞,分類也不必定正確,只是從其餘文章抄過來的。羅列在這裏,以便往後或深或淺的學習。

 

  • 負載均衡:

    Nginx:高性能、高併發的web服務器;功能包括負載均衡、反向代理、靜態內容緩存、訪問控制;工做在應用層

    LVS: Linux virtual server,基於集羣技術和Linux操做系統實現一個高性能、高可用的服務器;工做在網絡層

  • webserver:

    Java:Tomcat,Apache,Jboss

    Python:gunicorn、uwsgi、twisted、webpy、tornado

  • service:  

    SOA、微服務、spring boot,django

  • 容器:

    docker,kubernetes

  • cache:

    memcache、redis等

  • 協調中心:

    zookeeper、etcd等

    zookeeper使用了Paxos協議Paxos是強一致性,高可用的去中心化分佈式。zookeeper的使用場景很是普遍,以後細講。

  • rpc框架:

    grpc、dubbo、brpc

    dubbo是阿里開源的Java語言開發的高性能RPC框架,在阿里系的諸多架構中,都使用了dubbo + spring boot

  • 消息隊列:

    kafka、rabbitMQ、rocketMQ、QSP

    消息隊列的應用場景:異步處理、應用解耦、流量削鋒和消息通信

  • 實時數據平臺:

    storm、akka

  • 離線數據平臺:

    hadoop、spark

    PS: apark、akka、kafka都是scala語言寫的,看到這個語言仍是很牛逼的

  • dbproxy:

    cobar也是阿里開源的,在阿里系中使用也很是普遍,是關係型數據庫的sharding + replica 代理

  • db:

    mysql、oracle、MongoDB、HBase

  • 搜索:

    elasticsearch、solr

  • 日誌:

    rsyslog、elk、flume

 

總結

  寫這篇文章,我曾在網絡上搜索過「如何學習分佈式系統」,但實話說,沒有很認同的答案。也許,這確實是一個難以回答的問題。因而,我想本身寫出一個答案,但寫完這篇文章,感受本身的回答也很混亂,也沒有說清楚,不過對我本身仍是有一些指導意義的,好比,理清了分佈式系統中會遇到的各類技術、理論、協議,以及經過一個例子展現他們是如何協做的,接下來就是各個擊破了。

  網上的諸多回答,上來就是看各類論文,google三大件、paxos什麼的,我的以爲不是很實用。更好的過程,是先有一個總體的把握,而後本身思考會有什麼問題,帶着問題去尋求答案,在尋求答案的時候再去看論文。

  另外,也有不少人提到,掌握好計算機基礎知識,如操做系統、計算機網絡,對學習分佈式系統是大有裨益的,這一點我很贊同。分佈式系統解決問題的思路是早就有的,不少都是前人研究透的問題,思想都是相同的。好比函數式編程中的map reduce之於Hadoop的MapReduce,好比磁盤存儲的raid之於Partition與Replication,好比IPC之於消息隊列。

 

references

Distributed systems for fun and profit  

劉傑:分佈式原理介紹

Fallacies_of_distributed_computing

CMU 15-440: Distributed Systems Syllabus

Distributed Systems Principles and Paradigms

學習分佈式系統須要怎樣的知識?

 

轉載自 http://www.cnblogs.com/xybaby/p/7787034.html

相關文章
相關標籤/搜索