2021年大数据基础（五）：分布式技术
2021大數據領域優質創作博客，帶你從入門到精通，該博客每天更新，逐漸完善大數據各個知識體系的文章，幫助大家更高效學習。
有對大數據感興趣的可以關注微信公眾號：三幫大數據
目錄
分布式技術
為什么需要分布式
計算問題
存儲問題
分布式系統概述
分布式實現方案
分布式系統
集群（Cluster）
負載均衡（Load Balancer）
彈性(伸縮性)
失效轉移
分布式技術
為什么需要分布式
計算問題
無論是我們在學校剛開始學編程，還是在剛參加工作開始處理實際問題，寫出來的程序都是很簡單的。因為面對的問題很簡單。以處理數據為例，可能只是把一個幾十K的文件解析下，然后生成一個詞頻分析的報告。很簡單的程序，十幾行甚至幾行就搞定了。
直到有一天，給你扔過來1000個文件，有些還特別大，好幾百M了。你用之前的程序一跑，發現跑的時間有點長。于是想要去優化下。1000 個文件，互相還沒業務聯系，用多線程呀，一個線程處理一個文件，結果再匯總就搞定了。如果多線程效果不夠好，比如像 Python 的多線程，沒法利用多核的威力，那就用多進程。
無論是線程、進程，本質上，目的都是為了計算的并行化，解決的是算的慢的問題。而如果計算量足夠大，就算榨干了機器的計算能力，也算不過來，咋辦？
一臺機器不夠，那就多搞幾臺機器嘛。所以就從多線程/進程的計算并行化，進化到計算的分布式化（當然，分布式一定程度上也是并行化）。
存儲問題
另一方面，如果處理的數據有10T，而你手上的機器只有500G 的硬盤，怎么辦？?
一種辦法是縱向擴展，搞一臺幾十T硬盤的機器；另一種是橫向擴展，多搞幾臺機器，分散著放。前者很容易到瓶頸，畢竟數據無限，而一臺機器的容量有限，所以在大數據量的情況下，只能選后者。把數據分散到多臺機器，本質上解決的是存不下的問題。
同時，剛才提到計算分布式化后，總不能所以程序都去同一臺機器讀數據吧，這樣效率必然會受到單臺機器性能的拖累，比如磁盤 IO、網絡帶寬等，也就逼著數據存儲也要分散到各個機器去了。基于這兩個原因，數據存儲也分布式起來了。
分布式系統概述
分布式系統是一個硬件或軟件組件分布在不同的網絡計算機上，彼此之間僅僅通過消息傳遞進行通信和協調的系統。簡單來說就是一群獨立計算機集合共同對外提供服務，但是對于系統的用戶來說，就像是一臺計算機在提供服務一樣。
分布式意味著可以采用更多的普通計算機（相對于昂貴的大型機）組成分布式集群對外提供服務。計算機越多，CPU、內存、存儲資源等也就越多，能夠處理的并發訪問量也就越大。
從分布式系統的概念中我們知道，各個主機之間通信和協調主要通過網絡進行，所以，分布式系統中的計算機在空間上幾乎沒有任何限制，這些計算機可能被放在不同的機柜上，也可能被部署在不同的機房中，還可能在不同的城市中，對于大型的網站甚至可能分布在不同的國家和地區。
???????分布式實現方案
分布式系統
小明的公司有3個系統：系統A，系統B和系統C，這三個系統所做的業務不同，被部署在3個獨立的機器上運行，他們之間互相調用（當然是跨域網絡的），通力合作完成公司的業務流程。
將不同的業務分部在不同的地方，就構成了一個分布式的系統，現在問題來了，系統A是整個分布式系統的臉面，用戶直接訪問，用戶訪問量大的時候要么是速度巨慢，要么直接掛掉，怎么辦？
由于系統A只有一份，所以會引起單點失敗。
集群（Cluster）
小明的公司不差錢，就多買幾臺機器吧， 小明把系統A一下子部署了好幾份（例如下圖的3個服務器），每一份都是系統A的一個實例，對外提供同樣的服務，這樣，就不怕其中一個壞掉了，還有另外兩個呢。
這三個服務器的系統就組成了一個集群。
可是對用戶來說，一下子出現這么多系統A，每個系統的IP地址都不一樣，到底訪問哪一個呢？
如果所有人都訪問服務器1.1，那服務器1.1會被累死，剩下兩個閑死，成了浪費錢的擺設。
負載均衡（Load Balancer）
小明要盡可能的讓3個機器上的系統A工作均衡一些，比如有3萬個請求，那就讓3個服務器各處理1萬個（理想情況），這叫負載均衡
很明顯，這個負載均衡的工作最好獨立出來，放到獨立的服務器上（例如nginx）：
后來小明發現，這個負載均衡的服務器雖然工作內容簡單，就是拿到請求，分發請求，但是它還是有可能掛掉，單點失敗還是會出現。沒辦法，只好把負載均衡也搞成一個集群，這個集群和系統A的集群有兩點不同：
1.我們可以用某種辦法，讓這個機器對外只提供一個IP地址，也就是用戶看到的好像只有一個機器。
2.同一時刻，我們只讓一個負載均衡的機器工作，另外一個原地待命，如果工作的那個掛掉了，待命的那個就頂上去。
彈性(伸縮性)
如果3個系統A的實例還是滿足不了大量請求，例如雙十一，可以申請增加服務器，雙十一過后，新增的服務器閑置，成了擺設，于是小明決定嘗試云計算，在云端可以輕松的創建，刪除虛擬的服務器，那樣就可以輕松的隨著用戶的請求動圖的增減服務器了。
失效轉移
上面的系統看起來很美好，但是做了一個不切實際的假設：所有的服務都是無狀態的，換句話說，假設用戶的兩次請求直接是沒有關聯的。但是現實是，大部分服務都是有狀態的，例如購物車。
用戶訪問系統，在服務器上創建了一個購物車，并向其中加了幾個商品，然后服務器1.1掛掉了，用戶后續訪問就找不到服務器1.1了，這時候就要做失效轉移，讓另外幾個服務器去接管，去處理用戶的請求。
可是問題來了，在服務器1.2,1.3上有用戶的購物車嗎？如果沒有，用戶就會抱怨，我剛創建的購物車哪里去了？還有更嚴重的，假設用戶登錄過得信息保存到了該服務器1.1上登錄的，用戶登錄過的信息保存到了該服務器的session中，現在這個服務器掛了，用的session就不見了，會把用戶踢到了登錄界面，讓用戶再次登錄！
處理不好狀態的問題，集群的威力就大打折扣，無法完成真正的失效轉移，甚至無法使用。
怎么辦？
一種辦法是把狀態信息在集群的各個服務器之間復制，讓集群的各個服務器達成一致。
還有一種辦法， 就是把幾種狀態信息存儲在一個地方，讓集群服務器的各個服務器都能訪問到。
- 📢博客主頁：https://lansonli.blog.csdn.net
- 📢歡迎點贊 👍 收藏 ?留言 📝 如有錯誤敬請指正！
- 📢本文由 Lansonli 原創，首發于 CSDN博客🙉
- 📢大數據系列文章會每天更新，停下休息的時候不要忘了別人還在奔跑，希望大家抓緊時間學習，全力奔赴更美好的生活?
總結
以上是生活随笔為你收集整理的2021年大数据基础（五）：分布式技术的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 2021年大数据基础（四）：
- 下一篇： 2021年大数据环境搭建（一）：