<strong id="g4pkx"></strong>
    <font id="g4pkx"><noscript id="g4pkx"></noscript></font>
      <font id="g4pkx"></font>
    1. <font id="g4pkx"></font>
        1. 如何pick分布式系統協調框架?Eureka or Zookeeper?
          課工場 | 2020-07-10 13:13:12  1165 瀏覽
          隨著互聯網的快速發展,分布式的思想已經廣泛應用在各個行業中了。分布式是與中心化相對的概念,中心化的思想是把關鍵的內容集中處理,這樣的好處是提高了效率、更專注專一,壞處是如果中心系統掛了,所有的內容都沒有了。
          分布式的思想是把整個模塊分成多個模塊去處理,每個人負責一部分,這樣的好處是即使某一部分沒有了,其它的內容還存在,造成的損失不大,壞處是多模塊協調溝通成本高。
          比如在企業管理中不會把核心模塊只交給某個人負責,而是培養多個人都了解此模塊,這樣即使核心人員離職了,企業還是可以正常運轉,不會有多大影響。
          而在計算機系統的世界中,分布式系統的出現是為了用便宜的、普通的機器完成單個計算機無法完成的計算存儲任務,更好的利用資源處理更多的任務。
          早期的時候一套應用程序全部署在一臺機器上,但隨著業務量的增長、用戶請求的增加,該機器已經不能滿足更多的計算存儲任務,即使換更好的機器或者單獨升級某個組件能力(比如加磁盤、加內存、換更好的CPU)也不能解決問題,這時候只能采用SOA或微服務設計、分布式模式進行部署了,在系統架構上把業務進行拆分,子業務與子業務之間通過網絡進行通信,共同協調完成任務,在部署模式上把不同的子業務部署在不同的機器上,子業務扛不住業務壓力時再加新的機器支撐。
          在業務拆分細粒化、業務部署集群化的情況下就會帶來新的問題,不過戴上CAP的帽子后,問題多多的分布式系統也能變得很可愛~
          那么什么是CAP定理呢?CAP是一致性Consistency、可用性Availability、分區容錯性PartitionTolerance,CAP定理是說這三個目標不能同時滿足。
          首先我們來看看分區容錯性,在分布式系統中,大部分系統都分布在子網絡內,每個子網絡就是一個區,比如你的服務一臺部署在北京,一臺部署在上海,這就是兩個區。而這兩臺服務器可能由于網絡問題而無法通信,這就是分區容錯,一般來說,由于客觀原因,分區容錯是不能避免的。
          下圖中G1和G2在不同的區,G1向G2發送消息,但由于鏈路壞了或其它原因,G2可能收不到。

          然后我們再來看看一致性,一致性的意思就是數據必須一致。比如你位于北京區域,然后在淘寶下單買了一個商品,這時候在北京區域的訂單系統服務器上有了你的訂單記錄,但是在上海區域的服務器系統沒有獲取這個信息,所以就會存在你在北京時能看到自己的訂單記錄,但到了上海后沒有訂單記錄的情況(基于CDN內容分發網絡原則,網絡請求往最近的服務器區域發送)。如下圖所示,客戶端往服務器G1寫了一條數據V0,G1必須要往G2服務器再寫入V0這條數據,這樣當客戶端向G2服務器請求數據時才能獲取V0這條數據的同步,如果G1沒有向G2同步寫數據,就會出現客戶端向G2請求時數據不一致。


          最后我們來看看可用性,可用性就是服務任何時候都可以用,只要客戶端發起請求,服務器端就必須響應。
          那么一致性和可用性為什么不能并存呢?比如為了保障G2的一致性,那么G1在寫操作的時候,就必須鎖定G2的讀操作和寫操作,只有數據同步后才能開放G2的讀寫,在鎖定的時候,G2就必然不可用;而如果保障G2的可用性,那么G1在寫操作的時候,G2就不能被鎖定,數據就會不一致。因此CA只能擇一,魚和熊掌畢竟也不能兼得
          選魚方案之Zookeeper--要CP不要A
          在某些業務,比如交易場景中,因為涉及到了金錢,所以必須要數據一致,有任何差錯,老板就會拿刀架你脖子上了。
          Zookeeper就是保障了數據一致性的方案。在Zookeeper中使用專有的ZAB原子廣播協議來保障數據的一致性,在該協議中會包含三個角色Leader領導者、Follower跟隨者、Observer觀察者,Leader是唯一處理寫請求的人;Follower是接收客戶端的請求,處理讀請求但不處理寫請求,并且可以參加或投票Leader的選舉(當Leader掛了的時候);Observer是不能參加也不能投票的Follower。
          當客戶端向服務器發送請求,要寫入數據時,服務器會根據自己的角色和該請求的類型進行判斷,如果自己是leader那么就處理該請求;如果自己是Follower,那么服務器會根據請求類型進行決策,如果是寫請求,就轉發給Leader,Leader會給所有的Follower都發一個提議,讓大家來投票,如果超過一半的服務器都同意這個提議,那么Leader才會進行操作,從而保障了數據的一致性。
          比如在我們剛剛的訂單場景中,當用戶在客戶端發起一個商品購買請求給到訂單系統服務器時,服務器集群中的Leader判斷這是一個寫請求,需要往數據庫里插入一條某某用戶已購買某某商品的記錄,它會把這個記錄直接放在自己的服務器的數據庫里,并同步給其它的服務器也需要寫入該記錄。
          如果客戶端的請求發送給了Follower的服務器,那么它會轉發給Leader,Leader就給所有的服務器都發通知,問他們是否可以寫入此條記錄,如果超過一半的人都表示可以操作,那么Leader、對應的服務器就會把數據寫入在服務器里。

          選熊掌方案之Eureka--要AP不要C
          在某些業務,比如電商場景中,對于服務的可用性要求非常高,雙十一的時候打不開商品的頁面簡直是會要了女人的命啊,當然打開了就會要了男人的命,哈哈哈,開個小玩笑。
          所以在電商場景中服務的可用性是非常重要的,Eureka就是保障了服務可用性的方案。在Eureka集群中,服務器與服務器是通過Replicate來同步數據的,不區分master節點、slave節點,每個應用都指向其它應用,當某個服務器宕機時,該應用就切換到新的服務器節點執行任務,待宕機服務器恢復正常后,再將服務切回來。
          如下圖所示,還是以訂單場景來講解,在北京、上海、西安機房的服務器里都部署了訂單服務的應用程序,但是可能西安機房斷電了出了故障,從而導致西安的用戶使用訂單服務時就不能正常的使用了,但是因為整個大系統采用的是跨地區的高可用的集群部署模式,因此當西安的服務不可用時,用戶的請求就會走到上海,由上海的機房來提供服務,同時把數據同步給到北京的服務器,但這時候就會出現一個問題:西安機房的服務器由于斷電了沒能提供服務,因此斷電這段時間內的服務數據時沒有的,就出現了北京上海西安的數據不一致的情況。在業務場景中通常采用人工校對、客服等的方式可以解決。


          Zookeeper我所欲也,Eureka亦我所欲也,二者不可得兼。可用性我所欲也,一致性亦我所欲也,然二者不可得兼,同學們根據自己的業務場景選擇合適的分布式協調框架即可~~



          標簽:
          五月丁香浪潮网