現如今的業務場景下，我們對業務的可用性要求越來越高了，越來越難以接受系統的不在線，我們可以想象一樣，我們作爲用戶，出現如下情形時會怎麼樣：
1、在電商網站買東西的時候，電商網站打不開；
2、網站可以打開，但是頁面內容展示非常緩慢，難以忍受；
上面分別談到了可用性和用戶體驗的問題，而且是以用戶的角度，那麼現在我們嘗試着以業務提供方的角度分析一下，在出現以上情況時，可能會發生什麼：
1、用戶在購物時，網站無法打開，可能會造成用戶訪問中斷，但是競爭對手的網站可以打開，此時用戶將會在競爭對手的網站上成交，造成損失；
2、網站打開緩慢，造成用戶無法忍受，這將會帶來企業形象的損失；
現如今互聯網世界中，用戶的體驗是第一位的，最基本的一點是在用戶需要的時候，系統必須可用，通常的做法是講網站或系統部署到多臺服務器上，並且隨着壓力的升高，服務器的臺數也在增多，也就是說，部署更多內容一致的服務器，將用戶的訪問在多臺服務器之間分發，實現橫向擴展，或者水平擴展，當然，還有7層的負載均衡，服務器中的內容是不一致的，通過header等轉發規則進行處理，此時我們先討論第一種。
Nginx 可以輕鬆實現上述所說的請求分發，讓後端的服務器進行橫向擴展，且Nginx可以實現的負載均衡類型也很多，例如場景的Http、TCP、UDP等，當然，在實現Nginx負載均衡之前，我們還必須注意到一件事，一件很重要的事就是在實現了Nginx負載均衡之後，客戶端的訪問入口會發生變化，客戶端所有的請求會先訪問到Nginx提供的IP地址上，然後由Nginx再次轉發到後端的某一臺服務器上，這裏我們要注意，由於後端服務器衆多，可能會出現以下事件：
1、同一用戶在網頁上刷新後，Nginx服務器把此用戶的流量分發到了另一臺後端服務器上，剛纔用戶在網頁上做的所有操作不被新服務器承認，需要重複操作；
2、用戶在訪問的過程中，由於各種意外，正在被訪問的服務器故障，此時用戶的請求可能會重新轉移，那麼用戶的會話，cookie等狀態數據怎麼辦？
這個時候我們就要談一下場景的業務類型了，我們場景的業務類型分爲有狀態業務和無狀態業務，例如常見的Web體系架構就是無狀態的，當然，Http的會話也是很重要的，但是我們可以仔細盤剝一下，網頁歸網頁，會話歸會話，網頁本身是無狀態的，所以我們只需要保證會話的可用性和可靠性即可，那麼我們是不是可以把會話放入共享內存中或者數據庫中？當然可以，這也是一種較爲主流的方式，例如會話存入Redis數據庫，所以Nginx的後端服務器完全可以把會話和網頁本身實現解耦合，來實現橫向擴展，且Nginx在將請求分發給後端服務器之前，必須先探測一下後端服務器是否工作正常，如果正常纔會將請求分發過去，那麼剛纔的兩個問題中的第二個問題是不是就迎刃而解了？至於第一個問題，也是我們將會重點討論的，此時我們必須在Nginx上具備會話的持久性，也就是常說的會話保持功能，用戶的請求到Nginx之後，Nginx將請求分發到後端服務器，且會在一定時間內，記住用戶和後端服務器的映射關係，在一定時間內，此用戶的所有請求都會有同一個服務器進行處理，這就是會話保持功能。
總結一下，負載均衡的出現使得以下情況得以緩解
1、單臺服務器能力有限，用戶體驗差；
2、單臺服務器的可預見風險大，在故障時，將會造成用戶的體驗中斷；
總的來說，負載均衡通過將業務部署到多臺服務器上，在業務服務器前端提供統一的放入點，來進行流量的再次分發的形式，來提升了系統的負載能力。
下一篇我們重點以實驗的方式來實現HTTP負載均衡、TCP 負載均衡、UDP負載均衡，且探討其中的技術原理。