開發者學堂課程【Java 面試疑難點串講 4：Java Web 開發：叢集設計那點事】學習筆記，與課程緊密聯系，讓使用者快速學習知識。
課程位址：
https://developer.aliyun.com/learning/course/27/detail/1219叢集設計那點事
一、叢集設計
隻要是從事 java 的項目開發，那麼所遵循的基本原則就是 mvc 設計模式，那麼可以思考一下再哪一塊會出現問題。
從一個正常的開發的流程來說，最終不管背景經過了多少道處理，那麼前台都要進行顯示不受限制以及迅速反應才是整個開發中必須要解決的問題;
控制層隻是進行内容的接收，驗證 vo 轉換，業務調用，控制層隻是一個導向(業務分發)，從 ajax 的時代開始應該使用 json 讓控制層處理更加的容易一些，這樣就産生了 restful 架構設計;
業務層需要進行的是業務處理，需要調用一堆的資料層開發程式，是以業務層如何可以簡化，如何可以更高效為控制層服務或者是為使用者服務是一個關鍵問題。
資料層需要解決 vo 轉換以及速度還要快，不能都進行資料庫的操作，因為資料庫是瓶頸。如果從最基礎的開發要求來看，首先有一個伺服器 Webserver，專門做使用者處理，做完處理之後，有一台專門的伺服器，伺服器跑資料庫，這樣的過程之中，資料庫就能進行更有效的處理。使用者發送資訊給 Webserver。圖示如下
這種架構之中,沒有考慮特别複雜的操作形式，因為并發資料量少。網站不僅僅被使用者通路，還被機器所通路，在整個處理過程之中，使用者并不多。從本質效果來說，現在的代碼在人少的時候，能夠滿足要求。配置有 1g 記憶體加 5g 的資料盤和 20g 的系統盤，這隻是一台伺服器所能實作的。
需要叢集的理由是：
造成整個的開發瓶頸的最大問題在于資料庫操作非常緩慢。正常流程中，所有的項目操作流程幾乎都會按照一種固定的模式運作，從資料層到資料庫，一個項目中有一個資料庫，資料層之後還有業務層和控制層。
目前要執行一個功能控制層，能夠給予最大的操作形式就是使用者的資料交換。如果使用者要進行操作，就必須将使用者請求發給控制層，控制層将使用者的請求進行處理。
0 控制層接收到請求之後調用相應的業務層進行處理，業務方法中牽扯到業務層中的業務接口。業務層接口最終結果要調用資料接口，在處理當中，一個業務接口要調用許多個資料接口，做一個複雜查詢，可能同時要查 20 張表。資料接口會去調用資料庫，不管如何處理操作，資料層執行完成之後，這些操作都傳回到業務接口，而後業務接口再将資料處理，于是這些資料真正發回給控制層，控制層，再把資料發回使用者。圖示如下
如果這個時候使用者量暴增，所有的業務複雜操作就都會影響到使用者。如果做搶購的時候，所關心的一定不會是商品數量減少，商品的訂單增加，所關心的問題隻有一個就是是誰能搶到。如果隻是簡單的搶奪，隻需要做一個訂單的記錄即可。由此可知，資料庫的查詢性能直接導緻項目可能出現問題，那麼基于以下考慮
大型資料庫貴，是以隻能使用 my sql。
應該多準備資料庫，資料需要同步。處理準備兩組資料庫進行改進，是簡單的主從操作，相當于從一個人幹活，更新到兩個人幹活。從相當于做備份，因為在資料量過大時，不能夠及時做備份，從伺服器此時能夠給予主伺服器支援，資料層加快。
但是如果這樣開發，又會産生一個新的問題既然都有兩台資料庫都做查詢有點浪費，我們認為應該将更新操作也分攤一下。
準備三組 mysql，此時包含六台伺服器。如果六台伺服器都進行讀操作，會浪費資源，是以可以往裡寫資料。假設項目裡隻有三類資料，需要平均配置設定到不同表中， 是以會有一台專門的伺服器進行配置設定。使用者隻關注能否取到資料，不關心如何存儲資料。mycat 元件做讀寫分離，由 mycat 去維護所有能夠見到的主機，将資料平均配置設定。使用者不關注伺服器有多麼複雜的組成，隻需要知道通過一個專門的伺服器，使用者就可以讀到資料。這個過程按照傳統 jdbc 使用，代碼操作比較迅速。
進行叢集設定，僅僅因為建立資料庫昂貴。即使再将資料庫的服務搭建更加複雜，實際上最終也隻是對于整個項目的提升不能得到特别大的改善，因為它的讀寫仍然較慢。如果現在有需求，每秒鐘要求可以讀寫達到 10 萬次。如果使用 mysql 就會很慢，是以如果要進行資料高速讀取，就會出現 nosql 資料庫 (MongDB、Redis)。
使用者按照正常操作送出請求，依然要尋找控制層，業務層，資料層。資料層之後是關系型資料庫叢集，通過叢集能夠得到較大提升。目前架構如果隻是做簡單開發，一定能滿足需求，能保證項目正常進行。但關系型資料庫叢集很慢，于是又加入主從，用 redis 叢集控制。使用者讀資料一定需要通過控制層讀取，但不應該通過傳統的業務層讀取，應該通過叢集讀。 此時誕生元件 codis，該元件負責協調 redis 叢集。以上操作。能保證高速讀取讀寫頻率每秒鐘 10 萬次左右。
此時還存在問題，控制層隻有一個。是以就算後面讀取很快。但是控制層無法承擔，相當于背景的資料，可以按照每秒 10 萬次的讀取，但是控制層每秒隻能處理1000 個使用者。于是會發現所有的問題都卡在了控制層的性能上，于是就繼續建立一個 tomcat 叢集。
使用者需要正常進行通路，需要通過 web 通路，但 web 中并不是唯一的，有很多個web，每個 web 之中都有獨立的處理關系型資料庫叢集的能力。項目很大的情況下，準備多個 tomcat，但平時用不到多個伺服器，是以存在 5 台備用，15 台主用。在該過程中，使用者操作較為簡單，隻需要輸入網址。但是還需要将使用者請求進行分攤。并不是一開始就進行處理操作，先進行分攤處理，如此就可以完成控制層操作分擔。在整個操作過程中，以下叢集可以做高效操作。
對業務層控制層資料層進行合理處理後，還可以對業務用 RPC 進行拆分。假設辦公中存在很多系統，人事子系統，倉庫子系統，行政資源子系統内部辦公資源子系統，這些系統之間能夠進行互相調用，形成另一套叢集,此時可以形成一套完整的 rpc 架構。但又存在一個問題。
如果進行圖檔或視訊資訊的存儲，那麼空間會占用較大，實際中可以運用圖檔視訊伺服器進行處理。
無限擴充系統之後，使用者調用圖檔時可直接從 tracker 中讀取。以下專門對于圖檔進行處理的子系統。
在整個系統劃分之中，如果要采用大資料的分析處理，這個時候又需要建構大資料的分析系統。
大資料分析如下，在大資料分析之中，最重要的就是使用者資料采集，通過一套消息中間件行為把操作發送，這些消息中間件形成一套消息叢集。
叢集之間正常調用，保證操作性能。将使用者零散資料發送到消息中間件，此時存在消息分析系統。
之後存在 storm 叢集，記憶體需要非常龐大，64g 以上為宜。還需要對資料進行零散資料分析，又存在一 個 hadoop 叢集。hadoop 都會向關系型資料庫中直接儲存。
會将使用者資訊存存到緩存資料庫叢集中，以便下次調用。結構如下
但其中的關鍵是 zk。
此時再進行正常開發時，需要的伺服器較多。如果要構造完整的叢集開發模式，使用者輕松上網，能夠接收到使用者的處理行為的是一台 nginx，以下對應許多 tomcat，第一區域是使用者能夠直接通路的一套完整區域，第二區域是真正處理服務的叢集過程。
在該叢集當中，在整個處理過程之中，兩者之間可以做通路處理。
Tomcat 之後有許多遠端服務叢集，提供别樣服務。 仍然牽扯到關系型資料庫叢集，還需要緩存叢集。
該流程結束後，還需要消息叢集并牽扯到大資料叢集。消息叢集都會給大資料叢集做開發，還存在一個圖檔叢集。圖示如下。