分佈式知識點

時間  2019-11-29
標籤 分佈式 知識 欄目 系統架構 简体版
原文   原文鏈接

分佈式

  • Docker【容器化引擎服務】html

  • 微服務思想【服務拆分，持續集成、持續交付、持續部署】git

  • Kubernetes（k8s）【容器化部署，管理雲平臺中多個主機上的容器化的應用】github

  • 雲計算【SaaS（軟件即服務） 、PaaS（平臺即服務） 、IaaS（基礎架構即服務）】web

  • Zookeeper【分佈式協調服務】算法

  • Dubbo、Thrift（RPC 框架）【分佈式服務治理】數據庫

  • 分佈式事務解決方案緩存

  • ActiveMQ、Kafka、RabbitMQ【分佈式消息通訊】服務器

  • 熔斷，限流，降級機制網絡

  • Redis【分佈式緩存】session

  • Mycat【數據庫路由】

  • Nginx【反向代理】

  • Tomcat【Web Server 服務】

  • DevOps【自動化運維】

  • Go【併發的、帶垃圾回收的、快速編譯的語言】

  • 分佈式業務這裏列舉以下：

      1. 分佈式存儲，如GFS
      2. 分佈式計算，如MapReduce
      3. 分佈式鎖，如Chobby
      4. 分佈式數據庫，如BigTable，Spanner
      5. 分佈式ML，如TensorFlow分佈式
      6. 分佈式MQ，如Kafka

集羣（cluster）是指在多臺不一樣的服務器中部署相同應用或服務模塊，構成一個集羣，經過負載均衡設備對外提供服務。

分佈式（distributed）指在多臺不一樣的服務器中部署不一樣的服務模塊，經過遠程調用協同工做，對外提供服務。

把一個大的系統拆分爲多個子系統，每一個子系統負責本身專一的事情，而後經過網絡進行通訊和協調，對用戶來講，就像訪問的是同一臺及其同樣。

隨着飯店的發展，慢慢的從只有一個廚師演變爲多個廚師（集羣），接而演變爲有洗菜工、配菜工、廚師等多個職位。

這個網站架構發展也相似。網站初期，只須要搭建一個集中式的單體應用就能夠了，若是業務量有很大增加，先考慮增長機器，經過集羣部署提高能力。接着，就能夠考慮分佈式了。

 

https://github.com/h2pl/Java-Tutorial/blob/master/md/%E5%88%86%E5%B8%83%E5%BC%8F%E6%8A%80%E6%9C%AF%E5%AE%9E%E8%B7%B5%E6%80%BB%E7%BB%93.md

 

分佈式的任務：把多態機器有機的組合、鏈接起來，讓其協同完成一件任務，能夠是計算任務，也能夠是存儲任務。大概能夠包括三大部分：

1.分佈式存儲任務

2.分佈式計算任務

3.分佈式管理系統

（Google都是開創者）分佈式存儲是分佈式系統最難、最複雜、涉及面最廣的問題，大概分爲四個子方向：

1.結構化存儲

2.非結構化存儲

3.半結構化存儲

4.In-memory存儲

除了這四個子方向，還有一系列理論、算法、技術做爲支撐：例如Paxos、CAP、ConsistenHash、Timing、2PC、3PC等。

 

【1.結構化存儲】

典型的場景就是事務處理系統或關係型數據庫。好比你們耳熟能詳的MySQL。

傳統的結構化存儲系統強調的是

（1）結構化的數據（例如關係表）

（2）強一致性（例如：銀行系統、電商系統等場景）

（3）隨機訪問（索引、增刪改查、SQL語言）

然而，正是因爲這些性質和限制，結構化存儲系統的可擴展性一般不是很好，這在必定程度限制告終構化存儲在大數據場景/環境下的表現。隨着摩爾定律面臨的瓶頸，傳統的單機關係型數據庫系統面臨着巨大的挑戰。

【2.非結構化存儲】

和結構化存儲不一樣的是，非結構化存儲強調的是高可拓展性，典型的系統就是分佈式文件系統。

早期的分佈式文件系統只起到了網絡磁盤的做用，其最大的問題就是不支持容錯和錯誤恢復。

Google在2003年SOSP上推出的GFS（Google File System）則作出了里程碑的一步，其開源實現對應爲HDFS

GFS的主要思想包括：

1.用master管理metadata

2.文件使用64MB的chunks來存儲，而且在不一樣的server上保存多個副本

3.自動容錯，自動錯誤恢復

Google設計gfs最初目的是爲了存儲海量的日誌文件以及網頁等文本信息，而且對其進行批量處理（例如配合MapReduce問文檔創建倒排索引，計算網頁PageRank等）。和結構化存儲系統相比，雖然分佈式文件系統的可拓展性、吞吐率都很是好，可是幾乎沒法支持隨機訪問操做，執行進行文件進行追加操做，這樣的限制使得非結構化存儲系統很難面對低延時、實時性較強的應用。

【3.半結構化存儲】

解決非結構化存儲系統隨機訪問性能差的問題。咱們常常聽到一些流行名詞，如NoSQL、Key—Value Store，甚至包括對象存儲，例如protobuf，thrift等等。這些都屬於半結構化存儲研究的領域，其中以NoSQL近幾年發展勢頭尤其強勁。

NoSQL系統既有分佈式文件系統所具備的可拓展性，又有結構化存儲系統的隨機訪問能力（例如隨機update、read操做），系統在設計時一般選擇簡單鍵值（K-V）進行存儲，拋棄了傳統RDBMS裏複雜SQL查詢以及ACID事務。這樣作能夠換取系統最大限度的可擴展性和靈活性。

在NoSQL裏面比較有名系統包括：Google的Bigtable、Amazon的Dynamo、以及開源界大名鼎鼎的HBase、Cassandra等。一般這些NoSQL系統底層都是基於比較成熟的存儲引擎，好比Bigtable就是基於LevelDB。底層數據結構採用LSM-Tree。除了LSM-Tree以外，B-Tree（B+tree）也是很成熟的存儲引擎數據結構。

 

【4.In-Memory存儲】

隨着業務併發愈來愈高，存儲系統對低延遲的要求也愈來愈高。同時因爲摩爾定律及內存的價格不斷降低，基於內存的存儲系統也開始普及。

In-Memory顧名思義，就是將數據存儲在內存中，從而得到讀寫的高性能。比較有名的系統包括memcached，以及Redis。

這些基於K-V鍵值系統的主要目的是爲基於磁盤的存儲系統作cache。還有一些偏向於內存計算的系統，好比能夠追溯到普林斯頓KaiLee教授早期的研究工做DSM，斯坦福的RamCloud，以及最近火的基於lineage技術的tachyon項目（Spark生態系統子項目）等等。

 

【NewSQL】

 咱們在介紹結構化存儲時說到，單機 RDBMS 系統在可擴展性上面臨着巨大的挑戰，然而 NoSQL 不能很好的支持關係模型。那是否是有一種系統能兼備 RDBMS 的特性（例如：完整的 SQL 支持，ACID 事務支持），又能像 NoSQL 系統那樣具備強大的可擴展能力呢？ 2012 年 Google 在 OSDI 上發表的 Spanner，以及 2013 年在 SIGMOD 發表的 F1, 讓業界第一次看到了關係模型和 NoSQL 在超大規模數據中心上融合的可能性。不過因爲這些系統都太過於黑科技了，沒有大公司支持應該是作不出來的。好比 Spanner 裏用了原子鐘這樣的黑科技來解決時鐘同步問題，打破光速傳輸的限制。在這裏只能對 google 表示膜拜。

 

咱們在以前提到，分佈式存儲系統有一系列的理論、算法、技術做爲支撐：例如 Paxos, CAP, Consistent Hash, Timing (時鐘), 2PC, 3PC 等等。那麼如何掌握好這些技術呢？以我我的的經驗，掌握這些內容必定要理解其對應的上下文。什麼意思呢？就是必定要去思考爲何在當下環境須要某項技術，若是沒有這個技術用其它技術替代是否可行，而不是一味的陷入大量的細節之中。例如：如何掌握好 Paxos? Paxos本質上來講是一個三階段提交，更 high level 講是一個分佈式鎖。理解paxos必須一步一步從最簡單的場景出發，好比從最簡單的 master-backup 出發，發現不行，衍生出多數派讀寫，發現仍是不行，再到 paxos. 以後再瞭解其變種，好比 fast paxos, multi-paxos. 同理爲何須要 Consistent Hash, 咱們能夠先思考若是用簡單range partition 劃分數據有什麼問題。再好比學習 2pc, 3pc 這樣的技術時，能夠想一想他們和paxos 有什麼關係，可否替代 paxos。

 

做者：馬超
連接：https://www.zhihu.com/question/23645117/answer/124708083
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程