第一天 負載均衡之高併發發送

高併發發送：

1處：負載均衡

2處：數據庫

在APP服務器多臺狀況下，若是用戶登陸，session怎麼處理？

本文來源：凱哥Java(kaigejava)

我的博客：www.kaigejava.com

以下圖:

說明：

若是用戶登陸的時候負載到01服務器上，當用戶在操做其餘的時候，若是被負載到02機器上。這個時候02機器上面就沒有當前用戶的session。用戶就會被轉跳到登錄頁面。

解決方案：

1:能夠把用戶的session放置到cookie中

優勢：解決了session沒有的問題

缺點：session放在了用戶的瀏覽器中，是不安全的

2:能夠把用戶的session放置到數據庫中

優勢：解決了session沒有的問題

缺點：當用戶量很大的時候，若是把session放置到數據庫中，會形成數據庫壓力過大。從而使數據庫運行不正常

3:能夠把用戶的session放在緩存服務器中

最好的解決的方案是：放在緩存服務器中。這裏推薦兩種緩存服務器:memcached、redis

要求：memcached/redis必須是集羣

4:tomcat共享session

缺點：當tomcat數量過多的時候及其影響性能。因此不推薦

數據庫併發：

1 要求：隨着業務量的增大，數據庫庫承載能力也要增大

2 數據安全，不能丟失

3 支持備份+容災

高併發解決發展階段：

初級階段：系統或服務器級別就誒接方案

總結一句話：初級階段懟硬件(服務器級別)

接着隨着業務量的不斷增長,硬件成本水漲船高。就進入了第二階段：應用級別的解決方案

總結一句話：應用級別處理。

業務量繼續增長：進入第三階段：

增長了應用服務器的數量,隨之而來的問題又來了。

問題1：用戶訪問ip多了,怎麼解決?

多臺應該服務器。每臺對應的ip確定不同。

問題2：數據庫出現了瓶頸,怎麼解決?

解決用戶IP多的辦法一：

使用DNS進行解析。

DNS定義：

DNS解析多ip思路：

循環複用DNS。

缺點：

終極解決方案：

負載均衡工做原理分析：

說明：

1:在用戶請求,轉發請求的功能

2:若是這一臺機器掛了

   負載均衡服務會不 會繼續把請求轉發給這臺服務器呢?

  答案:不會

3:若是這一臺機器恢復正常了

  負載均衡服務器會不會把它添加回來呢?

答案:會的

三大功能

一:轉發

二:故障移除

三:恢復添加

負載均衡的種類：

1）一種是經過硬件來進行解決，常見的硬件有NetScaler、F5、Radware和Array等商用的負載均衡器，可是它們是比較昂貴的

2）一種是經過軟件來進行解決的，常見的軟件有LVS、Nginx、apache等,它們是基於Linux系統而且開源的負載均衡策略.