天天看點

帶着問題學習分布式系統

  很長一段時間,對分布式系統都比較感興趣,也聽說過、了解過其中一些相關的知識點,但都比較零碎。一直想系統的學習一下,但是一拖再拖,寫下本文,也是希望能督促自己。

  聽過很多道理,卻依然過不好這一生。

  看過很多關于學習的技巧、方法,卻沒應用到自己的學習中。

  随着年紀變大,記憶力越來越差,整塊的時間也越來越少,于是,越來越希望能夠更高效的學習。學習是一種習慣也是一種能力,這種能力在上學期間養成是最好的,畢竟那個時候絕大部分時間都在學習。但很遺憾,我沒有養成适合自己的、好的學習習慣。工作之後,除了在日常工作中用到的知識技術,很難通過自學掌握新的知識(偏向于專業知識,即技術)。而網際網路行業的分支、知識點又是如此之多,于是會出現這樣的情況,遇到一個新的知識,覺得很厲害很感興趣,看兩天,但很快就忘記了。另外,對于一些比較龐雜的技術,又無從下手,也很難堅持下去。

  根本的問題在于學習不系統,沒有把一個個的知識點連接配接起來,本來這些新的知識就很少在工作中實踐,如果又是一個個的資訊孤島,很快就會被遺忘。另一個問題,沒有良好的規劃,今天看看這裡,明天看看哪裡,糾結于細枝末節,忘了從整體上把握。

  幸好,差不多半年前開始意識到了這個問題,開始看書,看别人的部落格,開始思考如何充分利用好有限的時間。自己也實踐了一些想法,比如寫部落格,堅持寫部落格。也有很多沒做好,比如如何學習掌握一門新技術。關于這一點,其實看了許多文章,也有很多印象深刻,覺得很有道理;也有一些好書,比如《study more,learn less》。紙上得來終覺淺,絕知此事要躬行,别人的辦法再好也需要親身實踐才知道是否對自己适用。

  需要學習的技術很多,要自學新知識也不是一件容易的事,選擇一個自己比較感興趣的會是一個比較好的開端,于是,打算學一學分布式系統。

  帶着問題,有目的的學習,先了解整體架構,在深入感興趣的細節,這是我的計劃。

  首先得有問題,如果每日重複相同的工作,也不主動去學習,很難發現新的問題。不怕自己無知,就怕不知道自己無知,隻有不斷的學習,才會發現更多未知的知識領域!

  分布式要解決什麼問題呢?解決持久化資料太大,單個節點的硬碟無法存儲的問題;解決運算量太大,單個節點的記憶體、CPU無法處理的問題。解決這些問題,有兩種思路:scale up,scale out。前者就是提升單個節點的能力,更大的磁盤,更快的CPU,定制的軟硬體,然而這意味着更高的價格,而且再怎麼scaleup 也是有上限的。後者就是把存儲、計算任務分擔到普通的機器上,通過動态增加節點來應對資料量的增長,但缺點是多個節點的管理、任務的排程比較麻煩,這也是分布式系統研究和解決的問題。隻有當資料量達到單機無法存儲、處理的情況下才考慮分布式,不然都是自找麻煩。

  狀态的維護比計算要難很多,所謂狀态就是需要持久化的資料。是以主要考慮分布式存儲,況且即使是分布式計算,為了節省帶寬需要盡量保證data locality,也是需要分布式存儲。

  現在有一堆資料,可能是結構化或者半結構化,需要将資料分片(segment、fragment、shard),形成一個個的資料子集,存儲到一組實體節點上,實體節點之間通過網絡通信。那麼需要考慮兩個問題:

  第一:資料如何劃分; 

  第二:資料的可靠性、可用性問題

  

  資料分片是指将資料子集盡可能均衡的劃分到各個實體節點上。那麼會有哪些挑戰呢?

  (1)如果某個實體節點當機,如何将該實體節點負責的資料盡快的轉移到其他實體節點;

  (2)如果新增了實體節點,怎麼從其他節點遷移資料到新節點;

  (3)對于可修改的資料(即不是隻能追加的資料),比如資料庫資料,如果某節點資料量變大,怎麼将部分資料遷移到其他負載較小的節點,及達到動态均衡的效果。

  (4)中繼資料的管理問題:當資料分布在各個節點,那麼當使用者使用的時候需要知道具體的資料在哪一個節點上。是以,系統需要維護資料的中繼資料:即每一個資料所在的位置、狀态等資訊。當使用者需要具體的資料時,先查詢中繼資料,然後再去具體的節點上查詢。當資料在節點之間遷移的時候,也需要更新中繼資料。中繼資料的管理節點這裡稱之為meta server。中繼資料的管理也帶來了新的挑戰:

    (4.1)如何抽取資料的特征(特征是分片的依據,也是使用者查詢資料時的key),或者支援使用者自定義資料特征;

    (4.2)如何保證meta server的高性能和高可用,是單點還是複制集

  (5)分片的粒度,即資料子集的大小,也是資料遷移的基本機關。粒度過粗,不利于資料均衡;粒度過細,管理、遷移成本又會比較大。

  自問自答(2017 06 28):

  帶着問題學習分布式系統之資料分片 

  前面提到,分布式系統中的節點都是普通的節點,是以有一定的機率會出現實體故障,比如斷電、網絡不可用,這些故障導緻資料的暫時不可用;另外一些故障更嚴重,會導緻資料的丢失,比如磁盤損壞。即使單個節點的故障是小機率,當叢集中的節點數目很多是,故障就成為了一個大機率事件。是以,保證資料的高可用和可靠性是分布式系統必須解決的問題。

  為了避免單點故障,可行的辦法就是資料備援(複制集),即将同一份資料放在不同的實體節點,甚至是不同的資料中心。如果資料是一次寫,多次讀那很好辦,随便從哪個副本讀取都行。但對于很多分布式存儲系統,比如資料庫,資料是持續變化的,有讀有寫。那麼複制集會帶來什麼樣的挑戰呢,需要如何權衡呢,假設有三個副本:

  (1)三個副本的地位,大家都是平等的還是有主(primary、master)有次(secondary、slave),如果是平等的,那麼每個節點都可以接收寫操作;如果不平等,可以一個節點負責所有的寫操作,所有節點都提供讀操作,

  (2)在平等的情況下,怎麼保證寫入操作不沖突,保證各個節點的資料是一緻的,怎麼保證能讀取到最新的資料

  (3)不平等的情況下

    (3.1)寫節點怎麼将變更的資料同步到其他節點,同步還是異步;

    (3.2)非寫節點能否提供讀資料,如果能夠允許,會不會讀取到過時的資料。

    (3.3)主節點是怎麼産生的,當主節點當機的時候,怎麼選擇出新的主節點。是有統一的複制集管理中心(記錄誰主誰次,各自的狀态),還是複制集自己選舉出一個主節點?

  (4)不管複制集内部的節點是平等的,還是有集中式節點的,隻要有多個資料副本,就需要考慮資料的一緻性可用性問題。按照CAP理論,隻能同時滿足一緻性 可用性 分區容錯性之間的二者,不同的分布式系統需要權衡。

   自問自答(2017 08 30)

  帶着問題學習分布式之中心化複制集

  分布式系統有自己的術語或者概念。在目前的這個時間點,我對其中的一些有了解,或者使用過;另外一些隻是聽說過,不甚了解;當然,還有更多的是不知道的,是需要在後續的學習中去發現、去掌握的。

  分片 副本 一緻性哈希 幂等 CAP paxos raft NWR lease 兩階段送出協定 三階段送出協定 拜占庭問題

  目前收集到的學習資料如下:

  劉傑的《分布式系統原理介紹》

  Distributed systems for fun and profit  

  CMU課程:http://www.cs.cmu.edu/~dga/15-440/S14/syllabus.html

  MIT課程:http://nil.csail.mit.edu/6.824/2016/schedule.html

  前面兩個是基礎整體介紹,最後一個是MIT的課程,網上評價很高,也有很多人在學習。

  對于一門新技術,不要上來就開幹,思考新技術解決了什麼問題、已有的技術能否替代、适用場景與缺陷。對于自己(程式員),想想為什麼要學、是深度還是廣度知識、該技術在自己的技能樹中的位置。

  對于學習,需要長期目标與短期目标相結合。長期目标很重要,但需要分解成一個個小目标,否則很容易在停頓、重拾之間打轉,也很容易分心到其他雜事,也就堅持不下去了。

  本文位址:http://www.cnblogs.com/xybaby/p/6930977.html

本文版權歸作者xybaby(博文位址:http://www.cnblogs.com/xybaby/)所有,歡迎轉載和商用,請在文章頁面明顯位置給出原文連結并保留此段聲明,否則保留追究法律責任的權利,其他事項,可留言咨詢。

繼續閱讀