架構的演變之路

關於分佈式系統，一直不知道該怎麼寫，這裏就先介紹下架構的演變

1.在最開始時，使用的架構是這樣的：

 

 瀏覽器向後臺服務器發送請求，而後服務器請求數據庫，獲取數據，在響應給瀏覽器，這是最先期的架構，服務器和數據庫放在一臺主機上，

 

這樣的架構帶來的問題是：

　　當訪問量逐漸增大時，服務器的負載就會愈來愈大，負載達到必定限制時，服務器就會宕機，一旦服務器宕機，前端就獲取不到任何數據

2.爲了解決這個問題，就提出了第二套架構

 

 經過將數據庫分離出來成爲一個單獨的服務器，來減少放web項目的服務器的壓力，這樣雖然解決了第一種架構的問題，可是新的問題出現了：

　　當有十萬併發請求web服務器時，服務器就會宕機，服務器宕機，瀏覽器仍然獲取不到任何數據，核心功能在web服務器上

3.所以就出現了第三種架構

 

 爲了解決上一種架構的問題，因而就提出了使用web服務器集羣來部署項目，這樣當節點1宕機的話，就會請求節點2處理請求，那麼問題也隨之而來：

　　若是訪問量很是大，致使節點1宕機的話，那麼全部的請求就會被節點2接受，節點1宕機，節點2最後必然也會宕機，

4.負載均衡

 

 針對上面的架構的問題，就有了解決辦法：

　　使用nginx來作負載均衡，使用輪詢算法，一條給節點1，一條給節點2，下一個請求還給節點1，這樣就解決了上面的問題，可是又迎來了新的問題：

　　假設節點1的最大負載是8萬，那麼當節點1上如今已經達到滿載8萬時，下一條請求就是壓死駱駝的最後一根稻草，當下一次請求進入節點1，節點1的負載就到了8萬零一條，

這時節點1就會宕機。當節點1宕機後，nginx會繼續嘗試鏈接節點1，當嘗試幾回仍是鏈接不上後，就會放棄鏈接，並將節點1標記爲宕機狀態。

　　節點1宕機後，全部的請求就會壓在節點2上，那麼最後結果是節點2也必然宕機

5.架構五，將項目拆分

 

將一個項目於分兩個節點來存放，節點1就只存放門戶網站，節點2存放登陸的項目， 這樣就將請求分不一樣的服務器處理了

假設此時又十萬併發過來了，這十萬併發中有兩萬是請求門戶網站的，就訪問節點一、3，八萬是請求登陸項目的就訪問節點二、4，這樣高併發的問題就解決了。能夠查看dubbo架構：https://github.com/Zs-xiazhi/dubbo

　　併發的問題解決了，數據庫又出現問題了：想象一下，隨着項目的愈來愈大，用戶愈來愈多，數據庫中的用戶表中的數據也愈來愈多，數據的查詢就會很是慢，並且服務器集羣中全部的服務器都是訪問這一個數據庫，那麼數據庫的壓力就會很大。隨着數據庫中的數據愈來愈多，壓力愈來愈大，數據庫就會宕機，而服務器集羣訪問的只有這一臺數據庫，一旦數據庫宕機，那麼全部的項目都獲取不到數據了。

6.架構六，設置主從數據庫

由於上面已經解決了服務器集羣高併發問題，所以就不詳細畫該部分了：

 

 數據庫設置主從關係庫，正常運行時web服務器訪問主庫，全部的數據都存放在DB1上，當DB1宕機時，訪問DB2，發現沒有數據，所以DB1和DB2之間要作數據同步。

當DB1宕機期間，全部的數據都存放在DB2上，若是DB1修好了，這時發現DB2上有的數據DB1上沒有，DB2就會自動向DB1同步數據，速度很是快，爲了加快速度，能夠將常常使用的且不常常修改的數據放入redis緩存中

這種架構出現的問題是：

　　1.若是DB1宕機，如何切換從庫?

　　　　啓用監聽。項目啓動後，web項目鏈接數據庫DB1，當DB1鏈接超時，啓用監聽，切換數據庫DB2

　　2.單表數據過大，數據庫承受訪問壓力過大

　　　　單表數據量過大：分庫分表

　　　　數據庫承受訪問壓力過大：獨寫分離

7.分庫分表

 

 如上圖所示，假設項目用戶愈來愈多，那麼用戶表user內的數據就會愈來愈多，這時查詢數據很是慢，使用分庫分表，就是將同一張表放入不一樣的數據庫中。

假設user表中有10萬條數據，那麼就在db1放1-5萬條數據， db2中放5-10萬條數據

在分庫分表中，沒有主從概念，全部的數據庫都是平等的

問題：如何知道要查詢的數據在那兒個數據庫中？

　　假設用戶須要查詢一條數據， 那麼服務器如何知道這條數據存在哪兒個數據庫的表中的呢？因此須要在服務器和數據庫之間創建一個命名節點，這也是一個數據庫，裏面存放的數據是每一個數據庫節點的數據範圍。如：DB1---1-5萬，DB2--5-10萬。這樣服務器訪問數據庫時，先到命名節點中查詢要查的數據庫是在哪兒個數據庫上，而後再到相應的數據庫中查詢數據。

8.讀寫分離

分庫分表完美解決了大量數據的存儲問題，可是單個服務器壓力過大的問題尚未解決，讀寫分離解決但服務器壓力過大問題：中間的命名節點仍然存在，這裏畫漏了

 

 讀寫分離：

　　就是把服務器端的select和增刪改操做分離開來，對每個數據庫作標識（read-->只作select操做，write-->只作增刪改操做）

讀寫分離是有主從概念的，並非真的有主庫和從庫的區分，是有這個概念，讀爲主，寫爲從。

上圖使用的是獨寫分離加上分庫分表，這兩種方式能夠同時使用，也能夠分開單獨使用，並不衝突