下圖結構的設計思想是：
如果站點的訪問量非常大,當然下圖所能設計的模型是不能適應併發5萬的網路的。【併發5萬:即每秒5萬個併發請求，那麼一天是86400秒，每2秒乙個響應,則一天就是21.6億次訪問】
》在提供動態內網的web server的前端增加兩台快取伺服器，這樣就可以快取動態網頁為靜態網頁，這樣就有效降低後端web server的壓力。
》mysql-proxy 作為讀寫分離來實現mysql的高效處理效能。若需要高可用也可將他做成2臺。
》還有mysql伺服器在不使用鏈結執行緒池的情況，一台mysql server不論是使用myisam 或 innodb每秒接收1000個讀寫請求都是非常吃力的。因為,資料連線與web連線是無法比較的,乙個資料連線可能一次傳送的資料量會非常大；比如：查詢乙個有100萬行資料的表，乙個select * from ... 它返回的資料量你可以想象下，有多大。所以，為了分擔每台mysql server的壓力，在讀伺服器前要加上乙個負載均衡器這樣就可以大大的分擔單台server的壓力。
》memcache：有些資料可能不會經常性更新，那麼就可以將這些mysql查詢結果快取到memcache中，用來提高響應速度。比如：**的店家他們會上傳自己的商品資訊，但一般情況下，他們的**一旦建立好，大部分資料基本是不會在改變的。像這些資料就可以快取到memcache中。memcache是不能高可用，因為memcache不支援級聯間通訊，並且快取資料也不能共享。若memcache壞了，就直接在換一台即可，然後，將每個webserver指向新的memcache重新來生成快取。
》xcache：從php4.0以後,php都必須先編譯為opt檔案後，才能執行，那麼它將對webserver效能造成影響，因此需要安裝xcache作為php的模組，來快取php編譯後的結果。
假設是第一次啟動這個系統，當乙個使用者發來請求,nignx將請求交給快取伺服器，快取伺服器發現沒有需要的快取資料，接著它向後端的原始web server請求資料，web server 發現使用者請求的是乙個動態內容,向mysql-proxy傳送查詢，mysql-proxy發現這是乙個讀的查詢，因此將查詢傳送給負載均衡器，由負載均衡器負責將請求**給後端的mysql server，並將最終的查詢結果返回給mysql-proxy，mysql-proxy再把資料提交給web server，webserver在向使用者響應前，先將查詢的mysql的結果快取到memcache中，方便後續快速查詢，接著web server將資料返回給快取伺服器，快取伺服器將返回的結果頁面快取乙份後，響應使用者請求。
下圖結構的設計思想是：
》非同步訊息同步的平台，又稱作佇列管理器：它主要用來管理大量請求的緩衝佇列的，假如你的伺服器群最初設計時，每台server最大可響應500個請求，假若，突然併發量上公升，這時我們可以使用佇列管理器來解決這個問題，當有大量併發請求時，佇列管理器會檢查當前伺服器的空閒狀態，若為忙碌則將請求緩衝在自己的佇列中，並每次乙個乙個的將使用者請求分散轉給滿負荷的server,讓server進行響應。這樣就可以避免大量的併發導致server拒絕服務。佇列管理器有：rabbitmq ， zeromq，它也可簡單理解為乙個鏈結池。當然若不是採用非同步系統方式，依然可以使用cache server來代替佇列管理器。
》 php集群：所謂php集群實際上就是不使用apache了,直接安裝fastcgi來充當php伺服器,僅僅提供處理php請求的能力。當然，它也是需要xcache的。
注意: 只有在將動態內容和靜態內容分開的情況下，才可以使用php集群。在下面這個圖中，就是將靜態的內容單獨獨立出去。故採用php集群。
》靜態內容server： 這裡將靜態內容伺服器增加了很多臺,主要是因為，的體積太大,假如：像**這裡**，一張幾k大小，那麼一年會有多少將佔多少空間，10年哪？假如**10年來存的總容量為10t，那麼你可以想象下，在乙個10t的庫中找乙個是多麼不輕鬆！！所以，可以再cache server中快取經常被訪問的，就可以明顯提高效能了。
【注意：二八法則也是考慮的因素，100個商鋪，最多20%是活躍的，80%是非活躍的】
更完善的系統架構：
1》在實際的環境中，我們不可能讓每台伺服器自己儲存自己的日誌，因為這是非常不便於集中管理的。假如將所有server的日誌集中管理那麼像如此大的系統，每天產生的日誌量可能就會達到100g以上。並且我們還希望可以對這些日誌進行分析，並快速得到結果。那麼就必須使用到分布式系統hadoop了。它就是為了方便管理日誌，分析日誌，挖掘資料，就產生下下面這整套系統。而hadoop是完成資料分析最為核心的分布式系統。但它的缺點是，不能實時分析資料，它是一種非同步資料分析系統。因此，對於實時性的資料分析它就無能為力了。hadoop是開源界根據google發表的關於分布式系統的**而開發出來的，在google內部已經開發出了自己的實時的分布式系統，在開源界實時性的分布式系統也正在開發中。目前尚不明確。
這種分布式監控系統有什麼用？
就比如：五一搶購，若採用這種系統，我們可以實時分析出到目前為止，那個商戶的交易額最高，那個商戶的商品最熱銷，那個商戶的的人氣最高等等....
2》在下面這個系統結構中：
我會還需要考慮到，若下面的server都是物理機，那麼其故障遷移，故障處理，及故障恢復都將變的非常困難。這時，我們就需要借助雲來實現方便我們管理，我們可以將物理機都做成高可用，接著，我們將i/o需求不大業務都遷移到虛擬機器上，這樣我們就可以實現快速故障處理。並且讓我們的系統更加模組化，所謂模組化：即將我們的前端web server做到乙個虛擬機器集群中，並讓他成為乙個雲模組。我們的mysql集群也一樣，對外都只提供連線介面即可，至於後端如何實現就不要管了。當然我們的hadoop是不能放到虛擬機器中的，畢竟虛擬機器的i/o能力是很弱的，而hadoop需要非常大的i/o效能。
Impala之概念及架構
impala伺服器是乙個分布式，大規模並行處理 mpp 資料庫引擎。它包括執行在cdh集群主機上的不同後台程序。1，客戶端 有三類客戶端可以與impala進行互動 基於驅動程式的客戶端 odbc driver和jdbc driver，其中jdbc driver支援hive1與hive2風格的驅動形式...
Impala概念及架構解析
impala伺服器是乙個分布式 大規模並行處理 mpp 資料庫引擎。執行在集群每個節點上的守護程序，名稱為impalad。負責讀寫資料檔案 接受查詢請求，將查詢結果返回給中心協調者節點。statestore搜尋集群中impalad程序節點的健康狀態，並不斷將健康狀態的結果 給所有的impalad程序...
Kafka 基礎概念及架構
kafka是 個分布式 分割槽的 多副本的 多 產者 多訂閱者，基於zookeeper協調的分布式 志系統 也可以當做mq系統 常 可以 於web nginx 志 訪問 志，訊息服務等等。kafka主要應 場景 志收集系統和訊息系統 kafka主要設計目標 kafka訊息傳遞模式 發布 訂閱模式 不...