- 淘寶的管理海量小文件的分佈式存儲系統TFS
- 阿里巴巴開源的分佈式調用框架Dubbo（讀音[ˈdʌbəʊ]）
- 阿里巴巴開源的數據庫中間件Cobar
- 爲了存儲大量的網站索引，谷歌設計了GFS分佈式文件存儲系統和基於列存儲的Bigtable NoSQL數據庫系統
- 爲了計算PageRank算法中的頁面Rank值，谷歌又設計了MapReduce（ [mæp] [rɪˈdjuːs]）分佈式計算系統
- 爲了方便分佈式系統中不同主機間的協調，谷歌又設計了Chubby ( [ˈtʃʌbi] 圓胖的;豐滿的) 分佈式鎖系統
- 爲了解決不同語言實現的組件間的通信問題，Facebook設計了Thrift( [θrɪft]儲蓄機構)
- 爲了解決大量消息的快速傳遞問題，領英設計了Kafka([ˈkɑfkə] )
1.1 分佈式系統的組成
- 前端web、PC端、手機端
- 後端：大都是基於Linux的集羣
- 集羣管理系統：分佈式協調組件
- 存儲系統
- 計算系統
- 中間件
- 支持分庫分表的數據庫訪問中間件
- 用來異步化的消息中間件
- 用來開發不同組件的分佈式系統調用中間件
- 用來監控各個組件狀態的分佈式跟蹤中間件
1.2 分佈式協調組件
本質：分佈式環境中的進程間通信機制
分佈式協調組件對外提供的是一種分佈式同步服務。爲了獲得健壯性，一個協調組件內部也是由多個結點組成的，結點之間通過一些分佈式一致性協議（Paxos帕克索斯、Raft[ræft] ）來協調彼此的狀態。如果一個結點崩潰了，其他結點就自動接管過來，繼續對外提供服務，好像什麼都沒有發生過一樣。
1.3 分佈式存儲系統
與單擊系統類似，分佈式系統的存儲也分爲兩個層次：
- 第一個層是文件級，即分佈式文件系統。如： GFS（Google File System）、HDFS（Hadoop Distributed File System）、TFS（Taobao File System）
- 第二個層次是在文件系統之上的進一步抽象，即數據庫系統。
分佈式系統下的數據庫採用的大都是最終一致性（最終一致性即在“有窮”時間內，各個節點上的數據最終會收斂到一致的狀態，當然這裏的“有窮”經常是指很短暫的時間，幾分或幾秒就算比較長了），而非滿足ACID屬性的強一致性
CAP理論：在分佈式系統裏，沒有辦法同時達到一致性、可用性和網絡分區可容忍性，只能在三者中擇其二。
1.4 分佈式計算系統
1.4.1 批處理分佈式計算系統
MapReduce框架？？？？？？？
1.4.2 流處理分佈式計算系統
- 微批處理系統：Apache Spark[spɑːrk]
- 真正的流處理系統：Apache Storm、Apache Samza、Kafka Streams
1.4.3 混合系統
電商的智能推薦系統，其既需要批處理的功能（爲了確保響應速度，預先將大量的計算通過批處理系統完成），也需要流處理的功能（根據用戶的最新行爲，對推薦系統進行實時調整）
- Lamda（拉姆達）架構思想：用一個批處理系統（如MapReduce）來進行批處理計算，再用一個實時處理系統（如Apache Spark/Storm）來進行實時計算，最後用一個合併系統將二者的計算結果結合起來並生成最終結果
- “Questioning the Lamda Architecture”論文中提及Lamda架構的缺點即處理邏輯需要在批處理系統和流處理系統中實現兩遍。利用Kafka可以保存歷史消息的特性，作爲批處理系統和流處理系統的共享資源來處理（生產者與消費者關係）
1.5 分佈式系統中節點之間的關係
- 主從式（Master-slave）關係：GFS、Bigtable、HDFS、HBase、淘寶TFS、京東JFS、百度BFS、百度Tera
- 對等式（peer-to-peer）關係：亞馬遜的Dynamo