請求為f.chinasoft.com/file
f.chinasoft.com 網域名稱指向slb(3.3.3.3)
業務方式：
ios-->slb(3.3.3.3)-->ecs集群(每一台ecs都有乙個nginxweb伺服器)-->mysql
從mysql中獲取的資料為資料庫的ip位址，再次通過該ip(假設為1.1.1.1)去請求對應的資料 ip(1.1.1.1)被黑客ddos已經讓阿里雲黑洞了43200分鐘(阿里雲這個配合打的不錯，輕鬆讓黑客把伺服器停機乙個月)，解決辦法是在1.1.1.1這台ecs前端加乙個slb，再把需要的服務埠通過slb(2.2.2.2)對映出去
ecs被黑洞後，在前面加slb是可以和ecs進行通訊的
那麼問題來了，當我們把終端使用者需要的1.1.1.1(被黑洞的ecs)替換為slb(2.2.2.2)後，發現通過訪問f.chinasoft.com/file這個請求還是1.1.1.1，直接通過3.3.3.3/file來訪問就可以返回正確的替換後的ip(2.2.2.2)即我們需要的slb的ip位址
分析：1.資料庫確認已經被修改
2.那這個有問題的資料可能被快取在某個地方
cdn 排除
dns 排除
slb 沒有這樣的功能
檢視後面ecs的nginx時發現每個servername 都配置成了f.chinasoft.com，裡面有配置快取
nginx.conf如下:
proxy_temp_path /data/proxy_cache/temp;
proxy_cache_path /data/proxy_cache levels=1:2 keys_zone=cache_one:10m inactive=1d max_size=30g;
於是在每一台ecs上停用nginx，並刪除快取，重新啟動nginx，問題解決
#停止nginx服務
/usr/local/nginx/sbin/nginx -s stop
#刪除快取
cd /data/proxy_cache/
rm -rf *
#重新啟動nginx
/usr/local/nginx/sbin/nginx
Nginx快取問題
nginx在後續版本中加入了proxy cache實現對後端伺服器請求的快取，並賦予了很多強大的配置，在官方文件及各類技術支援文件中都能找到，本文不再贅述環境搭配及相關問題。主要討論配置成功後為何nginx伺服器沒有生成快取檔案，及無法命中快取的問題。產生這個問題的原因簡單點來說是因為後端伺服器的e...
nginx配置引發的403問題
一 問題 在curl nginx配置的本地網域名稱時出現403 nginx error.log日誌如下 二 疑問 1 www.requesturi.com配置如下 發現root目錄與error日誌中的禁止訪問的檔案不一致，理論上訪問www.requesturi.com應該到 usr local ng...
Redis Redis 快取熱點引發的思考
快取熱點 對於特別熱的資料，如果大部分甚至所有的業務都命中同乙份快取資料，則這份資料所在快取伺服器壓力就很大，例如，某明星微博發布 我們 來宣告戀愛了，則短時間內有成千上萬的使用者都來圍觀。快取熱點解決方案 解決思路是沒有問題的，是通過備份相同的資料到多台快取伺服器中，緩解分散單台伺服器的壓力，我的...