Java集羣--大型網站是怎樣解決多用戶高併發訪問的

      時間過得真快，再次登陸博客園來寫博，才發現距離上次的寫博時間已通過去了一個月了，雖然是由於本身找了實習，但這也說明本身對時間的掌控能力仍是沒那麼的強，哈哈，看來還需不斷的努力啊!（這裏得特別說明一下本人面試的一些感覺：作咱們IT這一行，必定要使本身精於某個領域，再不斷的去涉獵其餘的領域，更重要的是學會找出各個領域的相融點，這跟咱們學習書本同樣，用‘Java’和‘計算機網絡’來舉下例子，咱們知道Java中的socket編程，對於面向鏈接的編程來講（包括咱們每次在網頁上向服務器請求資源時），它的第一步就是創建雙方之間的通信鏈路，而這個過程其實就是TCP的鏈接，這時就能夠聯想計算機網絡中的TCP鏈接的三次握手，而在斷開時就能夠聯想TCP斷開鏈接的四次揮手等等；再者就是學習每門編程語言時，要打好本身的基礎，這在面試的時候是很重要的......）

      本人進入公司實習後，發現本人所在的項目組所採用的框架技術是Seam（簡單粗暴的講該框架就是JSF和EJB3的粘合劑），也許大多數的大家跟本人同樣，在學校上基本沒有聽過有這麼個框架，確實，這個框架確實沒那麼火，網上的資料也沒有SSH三大架構的多，可是，既然在這個項目組了，那就得作好本職工做了，因而，花了兩天的時間來先熟悉一下總體的代碼，恰好，這時客戶那邊有一個新的需求，因而，導師就把這個重任放在本人身上了（深深的感受導師太看重本人了），因而，花了三天的時間把這個功能實現了並交付給客戶去使用，本身也所以對這個框架更加熟悉了一點。

      後來，公司以爲Seam這個框架有點老了，因此就想對該項目實行底層改造，也就是由於這個契機，經過項目組成員的討論，在實現底層改造的同時，也把單機網站過渡到分佈式網站，這也就是本人在本文將要講訴的內容了。

      爲了解決大型網站的訪問量大、併發量高、海量數據的問題，咱們通常會考慮業務拆分和分佈式部署。咱們能夠把那些關聯不太大的業務獨立出來，部署到不一樣的機器上，從而實現大規模的分佈式系統。但這之中也有一個問題，那就是用戶如何選擇相應的機器的問題，這也被稱爲訪問統一入口問題，而解決的方法是咱們能夠在集羣機器的前面增長負載均衡設備，實現流量分發（總圖以下）。

     這裏得先解釋一下何爲「負載均衡」，負載均衡就是將負載（工做任務、訪問請求等）進行平衡、分攤到多個操做單元（服務器、組件等）上進行執行，是解決高性能，單點故障（高可用，若是你是單機版網絡，一旦服務器掛掉了，那麼用戶就沒法請求了，但對於集羣來講，一臺服務器掛掉了，負載均衡器會把用戶的請求發送給其餘的服務器進行處理），擴展性（這裏主要是指水平伸縮）的終極解決方案。

    

      在這裏，本人主要討論負載均衡設備爲Nginx(至於爲啥不講講F5，由於人家太貴了，不過人家比較穩定)，這是一款輕量級的Web服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，具備佔用內存少、併發能力強等，中國大陸使用nginx網站用戶有：百度、網易、新浪、騰訊等（該介紹來自百科）。

      nginx你們能夠上其官網去下載最新版，解壓後複製到部署目錄，對於Nginx的配置網上的資料不少，這裏就再也不贅述了，只總結一下Nginx使用的注意事項：

      1.nginx的負載均衡配置中默認是採用輪詢的方式，這種方式中，每一個請求按時間順序逐一分配到不一樣的後端服務器，若是後端服務器down掉，能自動剔除，但存在各個服務器的session共享問題。

      2.另一種方式是ip_hash:每一個請求按訪問的ip的hash結果分配，若是訪問的IP是固定的，那麼在正常狀況下，該用戶的請求都會分配到後臺的同一臺服務器去處理，可是若是用戶每次請求的IP都不一樣呢？因此這種方式也同1的方式同樣都存在這麼一個問題：session在各個服務器上的共享問題。

      3.，若是集羣中的服務器的性能不一，能夠經過配置各個服務器的權值來實現資源利用率的最大化，即性能好的優先選擇

      也許你會問，既然IP可能變化，那麼用戶用頁面請求時的cookie的ID應該是肯定的吧！那麼咱們能夠用cookie_id來進行hash，而後在經過負載均衡器分發到對應的服務器上，這樣就能夠解決session問題了，其實當初本人也有想到這個方案，但最後本人也放棄這個方案了，由於是根據cookid_id確實能夠把該用戶的請求惟一的分發到那臺獨一無二的服務器上，那若是這臺服務器掛掉了，那麼根據這種分發策略，豈不是在這服務器上請求資源的用戶都不能訪問了，你說是否是呢？

      解決服務器共享session問題：使用redis來共享各個服務器的session，並同時經過redis來緩存一些經常使用的資源，加快用戶得到請求資源的速度（我的比較喜歡redis，固然大家也可使用memcache來實現，不過，memcache不能作到持久化，這樣這臺服務器一掛掉，那麼全部的資源也都沒有了......）。

     不過，本人以爲這樣進行集羣部署，最好配上數據庫的主從部署，由於若是在集羣中只分配一個數據庫服務器，那麼這個系統的瓶頸將會出如今數據庫的操做上，雖然redis能減輕這種負擔，但對於數據量大的仍是有必定影響的，並且數據庫的主從部署也能夠防止因某個數據庫服務器的掛掉而丟失用戶的信息。

     一家之言，歡迎拍磚。