① nginx listen ip 什麼意思
默認的情況下，nginx是監聽所有能到這個伺服器的埠的「listen 80;」，即是說，網路能連接到的話，nginx能就能訪問。
建議：
1、檢查一下主機的防火牆或策略，是否把80埠禁用了。
2、如果客戶端和伺服器不在同一個網段，需要在路由器設置映射或者兄嘩路由功能。
3、檢查設置nginx.conf裡面，有沒有deny相關的設察塵明置。敗告
4、在服務端本地打開http://127.0.0.1，看看能不能訪問，確定nginx正常啟動。
② nginx負載均衡策略是什麼
當一台伺服器的單位時間內的訪問量越大時，伺服器壓力就越大，大到超過自身承受能力時，伺服器就會崩潰。為了避免伺服器崩潰，讓用戶有更好的體驗，通過負載均衡的方式來分擔伺服器壓力。
建立很多很多伺服器，組成一個伺服器集群，當用如談戶訪問網站時，先訪問一個中間伺服器，在讓這個中間伺服器在伺服器集群中選擇一個壓力較小的伺服器，將渣陵碰該訪問請求引入該伺服器。
如此以來，用戶的每次訪問，都會保證伺服器集群中的每個伺服器壓力趨於平衡，分擔了伺服器壓力，避免了伺服器崩潰的情況。
nginx實現反向代理負載均衡
a、本地使用Windows系統，然後使用VirutalBox安裝一個虛擬的Linux系統。
在本地的Windows系統上分別安裝nginx（偵聽8080埠）和apache（偵聽80埠）。在虛擬的Linux系統上安裝apache（偵聽80埠）。這樣相當於擁有了1台nginx在前端作為反向代理伺服器；後面有2台apache作為應用程序伺服器，可以看作是小型的server cluster。
b、nginx用來作為反向代理服務汪前器，放置到兩台apache之前，作為用戶訪問的入口。
③ nginx的ip hash負載均衡策略怎麼配置
這個是很正常的，ip_hash的負載均衡是以客戶端的ip地址作為hash錯作的key進而計算hash值得。這種策略能保證一個ip訪問到的永遠是同一台機器。
（1）但是有一種情況就是多個ip的hash值是相同的，在這種情況下，這幾個不同的ip訪問到的就是同一台機器了。
（2）還有一種情況就是，雖然你每次用不同的機器，但是這些機器都是通過一個相同的出口ip來訪問伺服器，這時，你訪問到的也永遠是一台伺服器。
④ nginx的ip hash負載均衡策略怎麼配置
生產環境，今天無意中用IP訪問了一下，發現竟然可以訪問到，有一個域名被做為了默認域尺譽轎名。網上找了一下資料，Nginx可以設虛敬置禁止通過IP訪問的。在任一有效的Nginx配置文件中加上以下一段# forbidden use ip address accessserver { listen 80 default_server; server_name _; return 444;}其陵肆實思路很簡單，就是用IP訪問的時候，返回444錯誤。
⑤ nginx前端常用配置
nginx現在幾乎是眾多大型網站的必用技術，大多數情況下，我們不需要親自去配置它，但是了解它在應用程序中所擔任的角色，以及如何解決這些問題是非常必要的。
下面我將從nginx在企業中的真實應用來解釋nginx在應用程序中起到的作用。
為了便於理解，首先先來了解一下一些基礎知識， nginx是一個高性能的反向代理伺服器 那麼什麼是反向代理呢？
代理 是在伺服器和客戶端之間假設的一層伺服器， 代理 將接收客戶端的請求並將它轉發給伺服器，然後將服務端的響應轉發給客戶端。
不管是正向代理還是反向代理，實現的都是上面的功能。
正向代理 是為我們服務的，即為客戶端服務的，客戶端可以根據正向代理訪問到它本身無法訪問到的伺服器資源。
正向代理 對我們是透明的，對服務端是非透明的，即服務端並不知道自己收到的是來自代理的訪問還是來自真實客戶端的訪問。
反向代理 是為服務端服務的，反向代理可以幫助伺服器接收來自客戶端的請求，幫助伺服器做請求轉發，負載均衡等。
反向代理 對服務端是透明的，對我們是非透明的，即我們並不知道自己訪問的是代理伺服器，而伺服器知道反向代理在為他服務。
下面是一個nginx配置文件的基本結構：
下面是 nginx 一些配置中常用的內置全局變數，你可以在配置的任何位置使用它們。
| 變數名 | 功能 | | ------ | ------ | | $host | 請求信息中的 Host ，如果請求中沒有 Host 行，則等於設置的伺服器名 | | $request_method | 客戶端請求類型，如 GET 、 POST | $remote_addr | 客戶端的 IP 地址 | | $args | 請求中的參數 | | $content_length | 請求頭中的 Content-length 欄位 | | $http_user_agent | 客戶端agent信息 | | $http_cookie | 客戶端cookie信息 | | $remote_addr | 客戶端的IP地址 | | $remote_port | 客戶端的埠 | | $server_protocol | 請求使用的協議，如 HTTP/1.0 、·HTTP/1.1 | | server_name | 伺服器名稱| | $server_port`|伺服器的埠號|
先追本溯源以下，跨域究竟是怎麼回事。
同源策略限制了從同一個源載入的文檔或腳本如何與來自另一個源的資源進行交互。這是一個用於隔離潛在惡意文件的重要安全機制。通常不允許不同源間的讀操作。
如果兩個頁面的協議，埠（如果有指定）和域名都相同，則兩個頁面具有相同的源。
例如：
現在我在 fe.server.com 對 dev.server.com 發起請求一定會出現跨域。
現在我們只需要啟動一個nginx伺服器，將 server_name 設置為 fe.server.com ,然後設置相應的location以攔截前端需要跨域的請求，最後將請求代理回 dev.server.com 。如下面的配置：
這樣可以完美繞過瀏覽器的同源策略： fe.server.com 訪問 nginx 的 fe.server.com 屬於同源訪問，而 nginx 對服務端轉發的請求不會觸發瀏覽器的同源策略。
根據狀態碼過濾
根據URL名稱過濾，精準匹配URL，不匹配的URL全部重定向到主頁。
根據請求類型過濾。
GZIP 是規定的三種標准HTTP壓縮格式之一。目前絕大多數的網站都在使用 GZIP 傳輸 HTML 、 CSS 、 JavaScript 等資源文件。
對於文本文件， GZip 的效果非常明顯，開啟後傳輸所需流量大約會降至 1/4 ~ 1/3 。
並不是每個瀏覽器都支持 gzip 的，如何知道客戶端是否支持 gzip 呢，請求頭中的 Accept-Encoding 來標識對壓縮的支持。
啟用 gzip 同時需要客戶端和服務端的支持，如果客戶端支持 gzip 的解析，那麼只要服務端能夠返回 gzip 的文件就可以啟用 gzip 了,我們可以通過 nginx 的配置來讓服務端支持 gzip 。下面的 respone 中 content-encoding:gzip ，指服務端開啟了 gzip 的壓縮方式。
這里為什麼默認版本不是 1.0 呢？
HTTP 運行在 TCP 連接之上，自然也有著跟 TCP 一樣的三次握手、慢啟動等特性。
啟用持久連接情況下，伺服器發出響應後讓 TCP 連接繼續打開著。同一對客戶/伺服器之間的後續請求和響應可以通過這個連接發送。
為了盡可能的提高 HTTP 性能，使用持久連接就顯得尤為重要了。
HTTP/1.1 默認支持 TCP 持久連接， HTTP/1.0 也可以通過顯式指定 Connection: keep-alive 來啟用持久連接。對於 TCP 持久連接上的 HTTP 報文，客戶端需要一種機制來准確判斷結束位置，而在 HTTP/1.0 中，這種機制只有 Content-Length 。而在 HTTP/1.1 中新增的 Transfer-Encoding: chunked 所對應的分塊傳輸機制可以完美解決這類問題。
nginx 同樣有著配置 chunked的 屬性 chunked_transfer_encoding ，這個屬性是默認開啟的。
Nginx 在啟用了 GZip 的情況下，不會等文件 GZip 完成再返回響應，而是邊壓縮邊響應，這樣可以顯著提高 TTFB ( Time To First Byte ，首位元組時間，WEB 性能優化重要指標)。這樣唯一的問題是， Nginx 開始返回響應時，它無法知道將要傳輸的文件最終有多大，也就是無法給出 Content-Length 這個響應頭部。
所以，在 HTTP1.0 中如果利用 Nginx 啟用了 GZip ，是無法獲得 Content-Length 的，這導致HTTP1.0中開啟持久鏈接和使用 GZip 只能二選一，所以在這里 gzip_http_version 默認設置為 1.1 。
如上面的圖，前面是眾多的服務窗口，下面有很多用戶需要服務，我們需要一個工具或策略來幫助我們將如此多的用戶分配到每個窗口，來達到資源的充分利用以及更少的排隊時間。
把前面的服務窗口想像成我們的後端伺服器，而後面終端的人則是無數個客戶端正在發起請求。負載均衡就是用來幫助我們將眾多的客戶端請求合理的分配到各個伺服器，以達到服務端資源的充分利用和更少的請求時間。
Upstream指定後端伺服器地址列表
在server中攔截響應請求，並將請求轉發到Upstream中配置的伺服器列表。
上面的配置只是指定了nginx需要轉發的服務端列表，並沒有指定分配策略。
輪詢策略
默認情況下採用的策略，將所有客戶端請求輪詢分配給服務端。這種策略是可以正常工作的，但是如果其中某一台伺服器壓力太大，出現延遲，會影響所有分配在這台伺服器下的用戶。
最小連接數策略
將請求優先分配給壓力較小的伺服器，它可以平衡每個隊列的長度，並避免向壓力大的伺服器添加更多的請求。
最快響應時間策略
依賴於NGINX Plus，優先分配給響應時間最短的伺服器。
客戶端ip綁定
來自同一個ip的請求永遠只分配一台伺服器，有效解決了動態網頁存在的session共享問題。
匹配以 png|gif|jpg|jpeg 為結尾的請求，並將請求轉發到本地路徑， root 中指定的路徑即nginx本地路徑。同時也可以進行一些緩存的設置。
nginx的功能非常強大，還有很多需要探索，上面的一些配置都是公司配置的真實應用（精簡過了），如果您有什麼意見或者建議，歡迎在下方留言...
⑥ 二十五 網路策略
網路策略（NetworkPolicy）是一種關於pod間及pod與其他網路端點間所允許的通信規則的規范。NetworkPolicy 資源使用標如知簽選擇pod，並定義選定pod所允許的通信規則。
前提
網路策略通過網路插件來實現，所以用戶必須使用支持 NetworkPolicy 的網路解決方案 - 簡單地創建資源對象，而沒有控制器來使它生效的話，是沒有任何作用的。
網路插件：
https://kubernetes.io/docs/concepts/services-networking/network-policies/
默認情況下，Pod是非隔離的，它們接受任何來源的流量。Pod可以通過相關的網路策略進行隔離。一旦命名空間中 NetworkPolicy 配置選擇了特定的Pod，該Pod會拒絕網路策略所不允許的連接。 (命名空間下其他未被網路策略所選擇的Pod會繼續接收所有的流量)
必填欄位: 與所有其他的Kubernetes配置一樣，NetworkPolicy 需要 apiVersion、 kind和 metadata 。
spec: NetworkPolicy spec 中包含了在一個命名空間中定義特定網路策略所需的所有信息.
podSelector: 每個 NetworkPolicy 都包括一個 podSelector ，它對該策略所應用的一組Pod進行選擇。因為 NetworkPolicy 目前只支持定義 ingress 規則，這里的 podSelector 本質上是為該策略定義 "目標pod" 。示例中的策略選擇帶有 "role=db" 標簽的pod。空的 podSelector 選擇命名空間下的所有pod。
policyTypes: 每個 NetworkPolicy 都包含一個 policyTypes 列表，其中包含 Ingress 或 Egress 或兩者兼具。policyTypes 欄位表示給定的策略是應用於 進入所選 Pod 的入站流量還是來自所選 Pod 的出站流量，或兩者兼有。 如果 NetworkPolicy 未指定 policyTypes 則默認情況下始終設置 Ingress； 如果 NetworkPolicy 有任何出口規則的話則設置 Egress。
ingress: 每個 NetworkPolicy 包含一個 ingress 規則的白名單列表。（其中的）規則允許同時匹配 from 和 ports 部分的流派碰量。示例策略中包含一條簡單的規則： 它匹配一個單一的埠，來自兩個來源中的一個， 第一個通過 namespaceSelector 指定，第二個通過 podSelector 指定。
egress: 每個 NetworkPolicy 包含一個 egress 規則的白名單列表。每個規則都允許匹配 to 和 port 部分的流量。該示例策略包含一條規則，該規則將單個埠上的流量匹配到 10.0.0.0/24 中的任何目的地。
所以，示例網路策略:
1.隔離 "default" 命名空間下標簽是 "role=db" 的pod (如果它們不是已經被隔離的話)。
2.（Ingress 規則）允許以下 Pod 連接到 "default" 名字空間下的帶有 "role=db" 標簽的所有 Pod 的 6379 TCP 埠：
注意作用域
「-」是同級，或的關系
注意ipBlock中目的地址或者源地址的NAT轉換
選擇器 to 和 from 的行為
可以在 ingress from 部分或 egress to 部分中指定四種選擇器：
podSelector: 這將在與 NetworkPolicy 相同的命名空塵橡談間中選擇特定的 Pod，應將其允許作為入口源或出口目的地。
namespaceSelector: 這將選擇特定的命名空間，應將所有 Pod 用作其輸入源或輸出目的地。
namespaceSelector 和 podSelector: 一個指定 namespaceSelector 和 podSelector 的 to/from 條目選擇特定命名空間中的特定 Pod。注意使用正確的YAML語法；
下面的策略,在 from 數組中僅包含一個元素，只允許來自標有 role = client 的 Pod 且該 Pod 所在的命名空間中標有user=alice的連接。
這項策略,在 from 數組中包含兩個元素，允許來自本地命名空間中標有 role = client 的 Pod 的連接，或來自任何命名空間中標有user = alice的任何Pod的連接。
ipBlock: 這將選擇特定的 IP CIDR 范圍以用作入口源或出口目的地。 這些應該是群集外部 IP，因為 Pod IP 存在時間短暫的且隨機產生。
群集的入口和出口機制通常需要重寫數據包的源 IP 或目標 IP。在發生這種情況的情況下，不確定在 NetworkPolicy 處理之前還是之後發生，並且對於網路插件，雲提供商，Service 實現等的不同組合，其行為可能會有所不同。
在進入的情況下，這意味著在某些情況下，您可以根據實際的原始源 IP 過濾傳入的數據包，而在其他情況下，NetworkPolicy 所作用的 源IP 則可能是 LoadBalancer 或 Pod的節點等。
對於出口，這意味著從 Pod 到被重寫為集群外部 IP 的 Service IP 的連接可能會或可能不會受到基於 ipBlock 的策略的約束。
默認策略
默認情況下，如果命名空間中不存在任何策略，則所有進出該命名空間中的Pod的流量都被允許。以下示例使您可以更改該命名空間中的默認行為。
默認拒絕所有入口流量
創建選擇所有容器但不允許任何進入這些容器的入口流量的 NetworkPolicy 來為命名空間創建 "default" 隔離策略。
這樣可以確保即使容器沒有選擇其他任何 NetworkPolicy，也仍然可以被隔離。此策略不會更改默認的出口隔離行為。
默認允許所有入口流量
如果要允許所有流量進入某個命名空間中的所有 Pod（即使添加了導致某些 Pod 被視為「隔離」的策略），則可以創建一個策略來明確允許該命名空間中的所有流量。
默認拒絕所有出口流量
您可以通過創建選擇所有容器但不允許來自這些容器的任何出口流量的 NetworkPolicy 來為命名空間創建 "default" egress 隔離策略。
這樣可以確保即使沒有被其他任何 NetworkPolicy 選擇的 Pod 也不會被允許流出流量。此策略不會更改默認的 ingress 隔離行為。
默認允許所有出口流量
如果要允許來自命名空間中所有 Pod 的所有流量（即使添加了導致某些 Pod 被視為「隔離」的策`略），則可以創建一個策略，該策略明確允許該命名空間中的所有出口流量。
默認拒絕所有入口和所有出口流量
可以為命名空間創建 "default" 策略，以通過在該命名空間中創建以下 NetworkPolicy 來阻止所有入站和出站流量.
這樣可以確保即使沒有被其他任何 NetworkPolicy 選擇的 Pod 也不會被允許進入或流出流量。
SCTP支持
Kubernetes 支持 SCTP 作為 NetworkPolicy 定義中的協議值作為 alpha 功能提供。要啟用此功能，集群管理員需要在 apiserver 上啟用 SCTPSupport 功能門，例如 「--feature-gates=SCTPSupport=true,...」。啟用功能門後，用戶可以將 NetworkPolicy 的 protocol 欄位設置為 SCTP。 Kubernetes 相應地為 SCTP 關聯設置網路，就像為 TCP 連接一樣。
CNI插件必須在 NetworkPolicy 中將 SCTP 作為 protocol 值支持。
首先需要有一個支持網路策略的 Kubernetes 集群。已經有許多支持 NetworkPolicy 的網路提供商，包括：
Calico
Romana
Weave 網路
注意：以上列表是根據產品名稱按字母順序排序，而不是按推薦或偏好排序。下面示例對於使用了上面任何提供商的 Kubernetes 集群都是有效的
創建一個nginx deployment並且通過服務將其暴露
為了查看 Kubernetes 網路策略是怎樣工作的，可以從創建一個nginx deployment 並且通過服務將其暴露開始
在 default 命名空間下運行了兩個 nginx pod，而且通過一個名字為 nginx 的服務進行了暴露
測試服務能夠被其它的pod訪問
從其它的 pod 訪問這個新的 nginx 服務。為了驗證它，從 default 命名空間下的其它 pod 來訪問該服務。請您確保在該命名空間下沒有執行孤立動作。
啟動一個 busybox 容器，然後在容器中使用 wget 命令去訪問 nginx 服務：
限制訪問nginx服務
想限制 nginx 服務，只讓那些擁有標簽 access: true 的 pod 訪問它，那麼您可以創建一個只允許從那些 pod 連接的 NetworkPolicy：
為服務指定策略
使用 kubectl 工具根據上面的 nginx-policy.yaml 文件創建一個 NetworkPolicy：
當訪問標簽沒有定義時測試訪問服務
如果您嘗試從沒有設定正確標簽的 pod 中去訪問 nginx 服務，請求將會超時：
定義訪問標簽後再次測試
創建一個擁有正確標簽的 pod，您將看到請求是被允許的：
⑦ 負載均衡：F5，Haproxy，lvs, nginx
閱讀本文前，需熟悉OSI七層參考模型。
常見的負載均衡設備，有F5，Haproxy，lvs, nginx等。
F5是商用硬體負載均衡，性能很好，但是價格昂貴，除了負載均衡，還有應用交換、會話交換、狀態監控等眾多功能。
F5一般做四層負載均衡，但也支持七層負載均衡。
Haproxy(以下簡稱ha)是軟嘩唯歲件負載均衡，開源，一般做七層負載均衡，但也支持四層負載均衡。
Linux Virtual Server(以下簡稱lvs)是軟體負載均衡，開源，二層或四層負載均衡，已集成到linux內核，自身有完備的熱備方案（keepalived+lvs），穩定性極強。
nginx也是軟體負載均衡，開源，通過反向代理實現負載均衡，是七層負載均衡，性能不如上面的幾個。
tips1
有些公司，測試環境用ha/lvs/nginx，生產環境用F5。
tips2
nginx做web伺服器時，一般做靜態資源伺服器和php的web伺服器，所以很多公司，會採用F5+nginx或者ha+nginx的架構
tips3
微服務中的ribbon屬於客戶端負載均衡，上面的幾種都是服務端負載均衡
二層負載均衡
在數據鏈路層通過修改mac地址實現，如lvs的DR模式（直接路由模式）
三層負載均衡
在網路層通過DNAT協議修改目標地址實現
四層負載均衡
用ip+埠實現請求轉發
備註：tcp報文里並沒有ip，但是四層負載均衡可以用ip+埠，是因為server可以拿到ip
七層負載均衡
通過重新發起http請求實現，即client把請求發給lb，lb把請求代發給server，再把server的響應返回給client，因此七層負載均衡也經常被稱為代理，七層負載均衡設備也被稱為代理設備。
七層負載均衡常用於內網與外網的通信，比如內網無法直接訪問外網，需要通過代理設備代發http請求，這種情況下，代理設備需要配置雙網卡，以同時與內外網路通信。
由於山寬需要重發http請求，七層負載均衡性能較差，但是更智能和安全，因為應用層可以獲取甚至修改請求的真實內容（即應用數據），比如cookie、url等，可以做一些智能的操作，比如根據cookie/url轉發請求，也可以做一些安全操作，比如過濾特定報文、防止SYN Flood攻擊等。
使用七層負載均衡時，服務的性能受限於代理設備的網卡帶寬。
常見的負載均衡策略，有輪詢、加權輪詢、ip_hash、cookie、url_hash，根據伺服器響應時間轉發、根據最少連接轉發等等。
備註：nginx可以安裝第三方插件，使用第三方實現的策略
輪詢：按伺服器列表順序轉發請求，輪詢是nginx默認的策略，本策略適合伺服器配置相當、請求無狀態（即不依賴session）的場景
加權輪詢：如果不同伺服器配置不同，可以為配亂睜置高的伺服器增加權重
ip_hash：根據ip哈希結果轉發，可以實現同一用戶持續請求同一伺服器（即會話保持），適合有狀態（即依賴session）的場景，對png、jpg、js、css等靜態資源的請求，不適合使用本策略
cookie：根據特定cookie轉發請求，一般也是用於實現會話保持，比如為伺服器A、B分別增加service-flag=a、service-flag=b的cookie，後續請求根據cookie轉發
可以參考 haproxy實現會話保持
url_hash：根據url哈希結果轉發，同一個介面始終請求同一台伺服器，一般配合緩存使用，緩存介面返回結果
根據伺服器響應時間轉發：優先轉發到響應時間較快的伺服器
根據最少連接轉發：優先轉發到連接數較少的伺服器
F5有一些特有的負載均衡策略：利用從應用程序和伺服器收集到的各項性能指標，分析並轉發
負載均衡有兩個步驟：
1.根據什麼演算法選擇真實服務端，即負載均衡策略，如輪詢、加權輪詢、ip_hash、cookie、url_hash等；
2.把請求轉發到真實伺服器，轉發方式有二層到七層負載均衡
keepalived軟體一開始是專為lvs設計的，後來加入了可以實現高可用的VRRP (Virtual Router Rendancy Protocol ,虛擬路由器冗餘協議）功能，因此，keepalived還可以作為nginx、haproxy、mysql等服務的高可用解決方案。
以nginx為例，為了防止nginx本身由於宕機等原因導致網站不可用，一般會搭兩套nginx反向代理，用keepalived提供一個VIP。
一般情況下，VIP只在nginx主節點上工作，如果nginx主節點不可用了，VIP會自動漂移到從節點，自動漂移的原理即VRRP協議。
VIP漂移到從節點後，如果主節點恢復正常了，VIP是否漂移回主節點，取決於當前模式是搶占模式還是非搶占模式。
下圖是一張簡單的架構圖，解釋如下：
以上觀點純屬個人意見，如果錯誤，歡迎指出，有些地方寫的很簡單，是因為我也不懂~
⑧ Nginx相關知識點
Nginx是lgor Sysoev為俄羅斯訪問量第二的rambler.ru站點設計開發的。從2004年發布至今，憑借開源的力量，已經接近成熟與完善。
Nginx功能豐富，可作為HTTP伺服器，也可作為反向代理伺服器，郵件伺服器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。並且支持很多第三方的模塊擴展。
Nginx的穩定性、功能集、示例配置文件和低系統資源的消耗讓他後來居上，在全球活躍的網站中有12.18%的使用比率，大約為2220萬個網站。
自行安裝
正向代理: 代理伺服器站在客戶端那邊就是正向代理;
反向代理: 代理伺服器站在原始伺服器那邊就是反向代理;
詳解參考點擊 Nginx正向代理與反向代理
Nginx在做反向代理時，提供性能穩定，並且能夠提供配置靈活的轉發功能。
Nginx可以根據不同的正則匹配，採取不同的轉發策略，比如圖片文件結尾的走文件伺服器，動態頁面走web伺服器，只要你正則寫的沒問題，又有相對應的伺服器解決方案，你就可以隨心所欲的玩。
並且Nginx對返回結果進行錯誤頁跳轉，異常判斷等。如果被分發的伺服器存在異常，他可以將請求重新轉發給另外一台伺服器，然後自動去除異常伺服器。
如果你的nginx伺服器給2台web伺服器做代理，負載均衡演算法採用輪詢，那麼當你的一台機器web程序iis關閉，也就是說web不能訪問，那麼nginx伺服器分發請求還是會給這台不能訪問的web伺服器，如果這里的響應連接時間過長，就會導致客戶端的頁面一直在等待響應，對用戶來說體驗就打打折扣，這里我們怎麼避免這樣的情況發生呢。這里我配張圖來說明下問題。
如果負載均衡中其中web2發生這樣的情況，nginx首先會去web1請求，但是nginx在配置不當的情況下會繼續分發請求道web2，然後等待web2響應，直到我們的響應時間超時，才會把請求重新分發給web1，這里的響應時間如果過長，用戶等待的時間就會越長。
下面的配置是解決方案之一:
如果使用upstream指令配置了一組伺服器作為被代理伺服器，伺服器中的訪問演算法遵循配置的負載均衡規則，同時可以使用該指令配置在發生哪些異常情況時，將請求順次交由下一組伺服器處理。
狀態值可以是：error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off
Nginx提供的負載均衡策略有2種：內置策略和擴展策略。
內置策略: 1.輪詢;2.加權輪詢;3.Ip hash;
擴展策略: 就天馬行空，只有你想不到的沒有他做不到的啦，你可以參照所有的負載均衡演算法，給他一一找出來做下實現。
Ip hash演算法，對客戶端請求的ip進行hash操作，然後根據hash結果將同一個客戶端ip的請求分發給同一台伺服器進行處理，可以解決session不共享的問題。
eg:
開啟簡單的緩存配置，只需要兩個指令：proxy_cache_path和proxy_cache。
proxy_cache_path: 配置緩存的存放地址和其他的一些常用配置;
proxy_cache:指令是為了啟動緩存;
相關配置說明:
該指令用於定義滿足條件的響應不會被保存到緩存中。在條件字元串中至少有一個條件不為空或者0，符合這樣條件的響應才不會被緩存。
舉例如下
其中，cookie_nocache、arg_nocache...皆為變數，可以根據你訪問的匹配策略來設置，其值只有2類，0和非0;
訪問匹配策略例如：
如果在此鏈式配置中，只要有一個值不為0，則不會cache；例如：
則不會被cache.
註：一般會配合proxy_cache_bypass共同使用；
該指令用於定義哪些情況不從cache讀取，直接從backend獲取資源；配置方式同proxy_no_cache。
給緩存數據定義一個鍵，例如
該指令用於設置緩存哪些HTTP方法,默認緩存HTTP GET/HEAD方法,不緩存HTTP POST 方法.。
設置不同響應碼的緩存時間，當不指定響應碼的時候，例如
只對響應碼為200，301，302的訪問請求資源設置緩存時間，此外可以個性化定製，例如：
此外，還可以在相應header里設置優先順序更高的緩存有效時間：
不緩存包含在field的響應header，可以設置的值有：「X-Accel-Redirect」, 「X-Accel-Expires」, 「X-Accel-Limit-Rate」，「X-Accel-Buffering」, 「X-Accel-Charset」, 「Expires」, 「Cache-Control」, 「Set-Cookie」 (0.8.44), and 「Vary」。
如果上述的header field沒有設置為忽略，則header filed中有「X-Accel-Expires」, 「Expires」, 「Cache-Control」, 「Set-Cookie」, and 「Vary」的話，響應會被緩存。
該指令用於設置緩存的最小使用次數,默認值為1
源站有問題時，nginx可以通過proxy_cache_use_stale指令開啟容錯能力，即使用緩存內容來響應客戶端的請求。舉例如下：
如上配置表示，當作為cache的NGINX收到源站返回error、timeout或者其他指定的5XX錯誤，並且在其緩存中有請求文件的陳舊版本，則會將這些陳舊版本的文件而不是錯誤信息發送給客戶端。
使用NGINX，不需要建立一個RAID（磁碟陣列）。如果有多個硬碟，NGINX可以用來在多個硬碟之間分割緩存。舉例如下：
在這份配置中，使用了3個獨立的緩存，每個緩存專用一塊硬碟，另外，3個獨立的線程池也各自專用一塊硬碟。
緩存之間（其結果就是磁碟之間）的負載均衡使用split_clients模塊，split_clients非常適用於這個任務。
在 proxy_cache_path指令中設置 use_temp_path=off ，表示NGINX會將臨時文件保存在緩存數據的同一目錄中。這是為了避免在更新緩存時，磁碟之間互相復制響應數據。
通過訪問日誌，你可以得到用戶地域來源、跳轉來源、使用終端、某個URL訪問量等相關信息；
通過錯誤日誌，你可以得到系統某個服務或server的性能瓶頸等。
因此，將日誌好好利用，你可以得到很多有價值的信息。
打開nginx.conf配置文件：vim /usr/local/nginx/conf/nginx.conf
日誌部分內容：
#access_log logs/access.log main;
日誌生成的到Nginx根目錄logs/access.log文件，默認使用「main」日誌格式，也可以自定義格式。
默認「main」日誌格式：
參數明細表：
查看日誌命令tail -f /usr/local/nginx/logs/access.log
打開nginx.conf配置文件去掉#注釋見下圖：
自定義某一個server配置的日誌，使用「main」日誌格式。
日誌生成的到Nginx根目錄logs/access.log文件，默認使用「main」日誌格式，也可以自定義格式。
重新讀取載入Nginx配置文件：
執行命令：nginx-s reload
網上一位老師寫的log文件分解的腳本
此腳本執行時間根據自己公司情況來定,可以設置默認一天執行一次;
創建crontab設置作業
設置日誌文件存放目錄crontab -e
*/1 * * * * sh /usr/local/software/nginx/nginx_log.sh
此設置的為一分鍾,如果設置一天自行修改;
默認的 nginx 配置文件 nginx.conf 內容如下
示例
幾個常見配置項：
注意:
驚群現象：一個網路連接到來，多個睡眠的進程被同事叫醒，但只有一個進程能獲得鏈接，這樣會影響系統性能
每個指令必須有分號結束。
進入安裝目錄下的sbin
⑨ Nginx負載均衡和節點檢查
a.使用語法:
check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port]
b.默認值:
如果沒有配置參數，默認值是：interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp
c.上飢察櫻下文: upstream模塊
upstream mogo {
server mogo:8080 weight=4;
server mogo2:8080 weight=4;
check interval=3000 fall=5 rise=2 timeout=1000;
ip_hash;
}
對mogo負載均衡條目中的所有節點，每個3秒檢測一次，請求 2 次正常則標記realserver狀態為up，如果檢測 5 次都失敗，則標記 realserver的狀態為down，超時時間為1秒.
nginx負載均衡策略：
a.RR(Round Robin-默認) - 每個爛叢請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，會自動剔除。
b.ip_hash - 客戶端ip綁定，每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端的伺服器，可以解決session問題沒核。
c.least_conn - 最少連接，下一個請求將被分配到活動連接數量最少的伺服器。
⑩ 13《Nginx 入門教程》Nginx負載均衡(下)
這一小節中，我們將實戰 Nginx 的四層和七層負載均衡功能。條件有限，使用一台公網主機，在上面搭建好 Nginx 服務。公網 IP 為 180.76.152.113。
首先會進行簡單的四層負載均衡實驗，不會涉及多種負載均衡演算法，只使用默認的 Round-Robin演算法。在後續的七層負載均衡實驗中，會重點測試不同的負載均衡策略，完成相關實驗。
首先在 nginx.conf 中添加如下 stream 指令塊配置:
上述配置用埠3000和3001模擬兩個上游伺服器，然後在 upstream 指令塊中指定這兩個上游伺服器的地址，同時給第一個設置權重為2。由於默認採用的是加權的 Round-Robin 演算法，默認伺服器的權重為1。設置為2，表明3次請求中，2次會轉發到3000埠，一次會轉發到3001埠，下面的測試也驗證了這一點。
和四層的配置其實差不多，在七層中除了告畝測試最基本的，我們還將測試前面提到的幾種負載均衡策略，進一步熟悉 Nginx 中的負載均衡配置。
在 nginx.conf 中添加如下的 http 指令塊:
上述配置中，我們用8000，8001和8002三個埠模擬了3個上游伺服器，默認使用輪詢負載均衡演算法，而且三個的權重均為1。進行如下的 http 請求操作，可以看到 Nginx 轉發 http 請求會均勻地分配到3個伺服器上。
我們打開 ip_hash 指令的注釋，這個時候默認是使用客戶端的 ip 地址作為 hash 的 key，然後重啟 Nginx 服務並進行如下的命令行操作：
接下來，注釋 ip_hash 指令，我們打開 hash user_$arg_username 這行配置的注釋， hash 指令可以讓我們根據我們設置的 key 進行 hash，然後根據 hash 值選擇上游的伺服器。具體測試參看下面的 Linux 命令：
這里我們可以看到，在請求中帶上 username 參數，Nginx 中配置敬友畝的 hash 演算法會根據請求中帶的 username 參數作為 key 去進行 hash，然後在根據 hash 結果映射上游伺服器。username 相同時，選擇的上游亮森伺服器肯定是一樣的，只有在 username 的值發生變化時，返回的響應才可能有變化。
今天我們完成了幾個測試實驗，主要是針對 Nginx 的四層和七層的負載均衡功能進行了測試。這個功能在微服務部署中會有較多的應用。因為高流量企業為保證服務的高可用性，往往會水平擴展多個相同功能的服務，部署在多台主機上，這個時候負載均衡技術就能派上用場了，而 Nginx 提供了完善的負載均衡功能以及多種負載均衡演算法，能滿足大部分企業的需求，如果還不夠，可以通過編寫內部開發模塊並集成到 Nginx，實現相應的需求。所以說 Nginx 是非常值得學習和深入研究的。