本文背景：
xxx系統(tǒng)投產前夕，由于代碼中富文本內容都存到了數據庫中，在查詢資訊信息詳情的時候加載需要幾秒鐘-十幾秒的時間（根據返回體的大小不同而不同），所以計劃先縮減咨詢的圖片大小，然后我們立即修改圖片存儲的方式（圖片上傳到文件服務器，db只存路徑）。但是在做生產網絡巡查以及流程驗證時發(fā)現，《資訊詳情》偶現網絡異常的錯誤。
-
表現層錯誤：
image.png
2.服務端錯誤：
image.png
3.看到這里從網上了解到服務端錯誤并不是代碼問題，于是查了nginx日志。
[crit] 225644#0: *50493152 open() “/data/nginx/nginx/temp/proxy_temp/4/24/0000000244”
failed (13: Permission denied) while reading upstream, client: xxx.xxx.xxx.xx,
server: localhost, request: “GET /api/wx/health/info/3 HTTP/1.1”,
upstream: “http://ip:9000/wx/health/info/3”, host: “域名”, referrer: “域名/nc-WeChatAccount/"
image.png
看到這些錯有點疑惑nginx為啥報權限不足的錯誤，百度搜索之后發(fā)現是nginx的機制導致的。
百度查詢的錯誤原因：
當前用戶是nginx，proxy_temp文件屬主是nobody。
注意： 此文件有個坑： 若nginx服務啟動用戶是nginx，而執(zhí)行nginx -t 操作時用的是root用戶，就會強行改變proxy_temp臨時目錄的權限（會變成nobody），注意注意?。。?！
難怪匯報permission denied。
此時修改的文件夾的屬主之后當前問題解決，但是疑惑加深了，為什么網絡異常是偶現。
看到這里那么恭喜你了，經過架構師的幫助，究其原因還是nginx的機制導致。
nginx的特點如何體現在代理服務器上
先說一下nginx的特點：
- 靜態(tài)代理
- 負載均衡
- 限流
- 黑白名單
- ...
此處我們重點關注代理的機制
其實就是生產者消費者模式
image.png
響應結果時：client可以看做消費者，backend server可以看做是生產者，此時就存在2種可能。 - 消費者速度 > 生產者
- 生產者速度 > 消費者 （重點）
nginx為了解決消費者速度慢導致的nginx與服務端的鏈接問題，使用了buffer來解決這一問題。下圖完整表達了nginx此時的處理邏輯。也就是用buffer解決生產者速度快，消費者速度慢的問題。但是buffer畢竟空間少，當buffer滿了的時候，nginx會將服務端的響應存到硬盤，所以就出現了前文的permission denied。下文詳細資料參考博文：https://www.digitalocean.com/community/tutorials/understanding-nginx-http-proxying-load-balancing-buffering-and-caching。
image.png
以上。
